Starwaster

So do we just have like, two unrelated THS* mods going in one thread? Or three even? Is there a separate thread for Speedy's somewhere?

WOW, what?????? I'm accusing you? You need to calm down and re-read what I posted. I'm not accusing anyone and I'm not asking for logs, I'm saying to you all that are discussing this that YOU need to look at YOUR OWN LOGS. When you do that you won't have to speculate about what's going on with the mod. That's #1 #2: I don't know where that rumor about logs not being generated except for crashes started, but it needs to stop. KSP always generates logs. CONSTANTLY. It generates two different logs, one more detailed than the other. That's output_log.txt if you're on Windows or player.log if on Mac or Linux. And finally, #3, EXCUSE ME for stopping in to offer information. I don't know what the hell possessed me. It won't happen again.

I'd at least set it to match the case mass that you're going to have just on the grounds that I don't remember what part.mass default is, and it needs to have a positive value. Zero is right out (bad things do happen and it is used in drag calculations too) I haven't put together any RC modules since Chris went to the new format so this is speculation. Firstly, the procedural module is optional. Second.... I don't know if you've looked at the source code at all, but everything that happens with case mass actually happens in RealChuteModule (that's actually where it's defined)(well, the important stuff happens there anyway, like adding case mass to chute mass then setting part.mass to the total). So if you also have a ProceduralChute, then case mass is overriding what was defined on the RealChuteModule. If you don't explicitly specify caseMass on RealChuteModule then it defaults to 0.1 (that's what the default is defined as in the source)

I hate to say this, but if this broke on 0.24 then 0.24.1 would have broken it worse. The functions used to retrieve resource information from parts changed. I'm surprised nobody here has started talking about logs. Probably because there's no active developer to ask for logs, but you people need to start looking at your output_log.txt or player.log files when this problem happens. (ksp.log will not do at all so dont bother looking there. At best it will tell you there was an error but no detailed information about where) You're likely looking at a minor re-write and recompiling against 0.24.2 binaries.

Jean, think about it, less air means you need a lot more surface area on your wings. Moar wings basically. And moar control surface. You can't take a plane that works on Kerbin (or Earth) and expect that it will just work on Duna too.

You're overthinking the mass issue. Why are you even worrying yourself about it? Are you planning on making some chutes that use RC? Part mass is always important and it is set automagically by RealChute based on case mass + (mass of all chutes carried in the case) So case mass should be set to something reasonable for that size and part mass should be something reasonable based on the default case size but will change anyway once the ship is 'in the field'

Yeah, you wouldn't believe how many times I botched things trying to figure out how to 'properly' deploy it. I felt like such an.... something or other.

Make sure to have your heat shield with you. Make sure your heat shield is upgraded.

It's been awhile since I landed my space plane, but are you manually trying to deploy or arm the chute? If so, that is your mistake. Drag chutes that are set to deploy on ground contact are considered to always be armed, at least for ground contact. You literally don't have to do anything with the chute, no arming or deploying The hardest part I found about that feature was learning to trust it. Just don't touch the chute and it should be fine. Edit: in fact, set altitude/pressure for whatever you like if you feel you might need to use it while in flight. Then you have a drag chute for landing and for... whatever else you configured it for.

Right, so I haven't loaded in Real Chute into my 0.24.2 install and I'm still on stock chutes. In fact the only mods are Ioncross, Module Manager, Stage Recovery and Mechjeb (no RSS. Important note) I stuck a Mk1 on top of one of the big SRBs (from the NASA pack) so I could perform some... tests. At one point I deployed the stock chute to try to pull myself off of the SRB, which failed and it continued to carry me on up... and up... and up. Can anyone tell me what's wrong with this picture?

So far as I can tell, nothing really changed that will affect Ioncross in this last update, 0.24.2. So I'm going to hold off on another update for now but I'll do a recompiling against the 0.24.2 binaries later. EDIT: New update. Nothing big, just recompiled against 0.24.2. So far not seeing any problems requiring other fixes. In fact, even the one compiled for 0.24.1 probably would run just fine under 0.24.2 but better safe than sorry.

No, there's just some designs, or perhaps more importantly, unrecognized mods like RealChute, that MJ has trouble knowing when to stage. Call it a bug or call it a limitation of logic, there's just some situations that it has trouble with. For things like RealChute, support for those has to be added in by going into the code and 'teaching' MJ what that is and when to stage it. Download MonoDevelop or Visual Studios, make a GitHub account (optional but advisable) fork the code and code it in And then submit your code for inclusion so everyone benefits Was it Career mode and did you have the Translatron upgrade researched? Seriously, this comes up a lot. When you first start playing a Career mode game, MJ is very limited. No fully automated launches, landings, no automated docking..... anyone think Auto Docking is bugged? Play on Career mode and suddenly you will find yourself BEGGING to have your Auto Dock back But yeah, no auto-throttle until its researched. I forget where.... it's on the bottom branch where most of the MJ options are as opposed to the top which is engineering stuff.

Of course it is, I just got done updating for 0.24.1! Well, off I go to download.... if anyone gets a chance before I do, please try this out in 0.24.2 and tell me if it broke again Edit: Ok, it's downloaded, but I have to go slap some hamburgers on the grill.....

Oh, come ON. I just finished updating Ioncross for 0.24.1!!! lol

There's even code (I think) in DREC to watch for high G force during SOI changes and ignores it on the assumption that it's just more of KSP's usual phantom forces. G force has to either be really high and sustained or really REALLY high over a short period to be lethal. I've had Kerbals survive over 10Gs and I thought for sure they were gonna snuff it until I saw the needle start to drift back down. I haven't made a manned munar voyage since downloading 0.24 ....

Update for 0.24.1 pending approval on Curse Temporary alternate download link here: IoncrossCrewSupport-1.16.1.zip Mainly just a compatibility update However, air vents have been tweaked to increase airflow. They also now use electricity to power their fans. If they run out of power they will still provide airflow but at a reduced volume. (still enough to keep the crew alive however)

In no particular order, manually limit autostaging to a stage you know is the safest for it to stage to. It's not smart enough to know when to stop. Are you in career mode? Throttle control has to be researched. It's part of translatron. post logs when referring to errors, and not that ksp.log either because its like watered down rootbeer. post links to a full output_log.txt (or player.log for linux or mac)

I think the way I'll go about it is to basically keep it as it is now but have a weighting variable. So the configuration can stay at 10%, the system will start making kill checks but weighted by a delta of how long it's actually been since since CO2 saturated. It already tracks the information needed. It's not perfect because it resets when the resource is no longer depleted or saturated. I think that's ok though. Also, maybe it would just be best to bump it to 20% unless we actually want to impose some kind of penalty for the area between 10%-20%, but the stock game doesnt currently lend itself to effects like that and It's probably outside of the mod's scope anyway. Also, I'll have the 0.24.1 update up soon. The codings been done for hours. Now I'm trying to tweak air vent performance because sometimes they just dont feed enough air to keep Kerbals from dipping into O2 stores.

The update last night (0.24.1) broke things. Working on it; hopefully update today.

You can probably ignore that. Not enough changed between 0.24 and 0.24.1 to really break RealChute. Probably....

That's not the game saying that. Quite a few modders have adopted a common version tracking scheme that checks KSP's version number against the version they were designated as having been compiled against. When the game starts up, that version checker goes to work comparing numbers. If they dont match up it reports a list of those as being incompatible. Optionally at the discretion of each implementing modder, a mod can disable itself if there is a version mismatch. I dont know if any actually do at this time. But as to the game itself, KSP doesnt know or care.

The first RemoteTech had some antennas that would orient to face their target. Is the code still intact to handle that or is it gone with those antenna?

Curiosity style hypersonic Duna chutes FTW!

Starwaster resists urge to dredge up old Airplane joke....

Are you using the x64 version of ATM? There's two, x86 (32 bit) and x64 (64 bit) https://github.com/rbray89/ActiveTextureManagement/releases/download/3-3-1-aggressive/x64-Release.zip