Starwaster

I'm trying to understand the significance of the thread and post you quoted from as to how it relates to any of your specific question to Sarbian your own post. Otherwise it's non sequitur. And try WHAT? What are you even talking about?

Why did you quote that post? It has nothing to do with Module Manager....?

Thanks, maybe some day I'll get back to actually playing the game myself

For MechJeb2, you have to get the latest Dev version from here: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/

That's still nearly Mach 4. You need to slow down much more than that.

Terminal velocity is irrelevant. And you apparently didn't read or didn't fully comprehend what I said. The Falcon 9 WOULD burn up if it did not use retropropulsion to slow itself to safe speeds. That is a fact borne out by early Falcon 9 stages that DID burn up before they started employing retropropulsion to slow the stage down to safe speeds. That's why the first stage survives reentry. Not because its engines are heat resistant. They do not make good heat shields. The heavier components would probably survive but the engine itself would be trashed

Ok, only just now looking at this, sorry. Have been busy trying to fix Ioncross life support mod which has been kicking me in the nuts all week. Looks like it's choking on one of the OPT internals. Unmodified OPT cockpits aren't behaving like that and the only thing in your log that even touches the internals is RPM [ModuleManager] Applying node JSI/RPMPodPatches/0.16-0.17-upgrade-patch/@INTERNAL[*]:Final to OPT/Spaces/JSLIVA/internal/jslCockpit [ModuleManager] Applying node JSI/RPMPodPatches/0.16-0.17-upgrade-patch/@INTERNAL[*]:Final to OPT/Spaces/JSLIVA/internal/jslCockpit This is where that ModuleManager.ConfigCache would come in handy so we can see what changes got made there. Maybe try temporarily removing 0.16-0.17-upgrade-patch.cfg and see if it loads up without it. If it does, something it's doing in that patch is responsible. There's also errors with several of your plugins not loading at all; presumably because you updated to 1.1.3 and those plugins haven't been updated yet? I'm treating that as unrelated to your OPT problem; those errors don't cause any problem other than the assembly not loading. So it's just an FYI. I'm going to have a look at RPM and see what it's doing in that patch. (if I can find it; forum is choking when I try to search for RPM. Probably because there's too many search results coming back)

Real life rocket engines are not designed to withstand reentry. They must be shielded or situated so as to not be exposed. They do not make good heat shields which is why Deadly Reentry brings rocket max temps to within sane values And just in case someone feels like mentioning Space X first stage reentry, it uses its engines to slow itself enough to be able to survive reentry. Otherwise it would burn up. Engines don't really make good heat shields. Another thing that helps is that it's not having to deal with reentry from full orbital velocity. Falcon 9 only has 20% of the velocity that something would have coming in from LEO.

Well good for you. The rest of us still think it's a little tame in stock and needs to be made a little harsher.

Ioncross Life Support 1.22.0 Converters and Collectors working properly again (affects recyclers and intakes) EVA life support improvements. All LS functions using FixedUpdate() instead of Update() now. Kerbals on EVA and sitting in command seats or otherwise connected to vehicles will try to use external supplies first. (i.e., Kerbal sitting in rover will use the rover's bottles instead of his suit bottles) EVA LS may have been disabled some time in the recent past. It is definitely active again so be careful! Recyclers functionality has changed. O2 to CO2 ratio is much higher. CO2 is only a fraction, basically being a sort of sump tank. Last plugin update for 1.0.5 barring catastrophic bug discovery. (config updates will be backwards compatible) Download from one of these locations: http://mods.curse.com/ksp-mods/kerbal/221054-ioncross-crew-support-sw https://github.com/Starwaster/Ioncross-Crew-Support/releases/tag/v1.22.0 I actually might do one further update for 1.0.5. after reevaluating the tech tree for Ioncross parts. Later today will come the update for KSP 1.1.3 Front page will be edited later; going to go catch some zzz's

Well I know not everyone has updated and the fixes are the same either way Edit: Update: Doing some last minute adjustments to recycler O2/CO2 rates. Also have to double check career mode trees

More news: Starting sometime tonight I'll begin pushing several updates. First for KSP 1.0.5 then for 1.1.3 included will be fixes for converters and EVA issues. Kerbals on EVA will try to draw from attached external O2 before their internal supply. So if they are driving rovers with O2 tanks they will use those first.

The problem I'm having with Ioncross deals with how it initializes from its config nodes and probably stems from changes to the KSP API introduced back in KSP 1.0. I should have recognized it before but I'd forgot about those changes to which my own code was immune. (Ioncross isn't my project originally, I'm just keeping it alive) I don't know what issues TAC might be having or whether or not they're related.

Ioncross News So, I've been trying to figure out the recycler issue without much luck. It's very bizarre because the module in question is used all over the place and it works elsewhere. Specifically, the modules in question work if configured as part of the 'pod' configurations. They don't work if added directly to a part as a PartModule (those MODULE entries that have name = IonModuleGenerator or IonModuleCollector). At first I thought maybe it was some change I made that had broken things but after a lot of testing and comparison of code it's pretty obvious now that some change in KSP or Unity is responsible. Essentially what happens is that somewhere between the Main Menu and Flight mode the part of the config node that defines a generator or collector's inputs and outputs is getting nuked. It just stops existing. Everything 'works' except that the recycler no longer has inputs or outputs for CO2, O2 or electricity. I'd hoped to have that part fixed before the 1.1.3 update came out but it's out now and looks like even more Ioncross stuff is broken so looks like I'm going to have my hands full on this one. Eh, looks like it's working fine in 1.1.3 except for the recyclers and collectors. So I only have to figure that part out.

Kopernicus is necessary for Real Solar System to function. If you're going to use RSS then you have to have Kopernicus. It's what makes custom star systems possible.

Someone get to this person's job, STAT! And administer an emergency coffee drip!

Leave it on.

I'll take a look at it when I get back up. (I'm not really awake right now)

The log has to be from a time that you tried loading the game and experienced trouble with it. If you've run the game since removing OPT then the log won't provide useful information. Something else that might be useful in troubleshooting (esp. since it involves part loading) is your ModuleManager.ConfigCache And that *should* always be there but certain errors in MM patches will result in the cache not being written.

It does not matter that it did not crash. Unless you've explicitly disabled logging then you always have output_log.txt. I wouldn't tell you go to looking for something that didn't exist. (for any of you Linux or Mac users following along, it's player.log) Please consult the following thread for instructions on locating your logs.

Again, not ksp.log output_log.txt and the whole thing, not just an excerpt. It's in either your KSP_Data or KSP_x64_Data folder depending on whether you're running in 32 or 64 bit. (x64 is 64 bit)

Pretty sure the restrictor would work for any animatable object My layered animator plugin is obsolete. Just add layer = # to the stock animator module with each animation getting its own layer. (prevents animations from cancelling each other out)

That log has a lot of exceptions in it but it doesn't indicate that you're locking up when loading. It even logs you loading up a craft in flight mode. Maybe it's a log from an earlier gaming session than the one you're referring to. (also, output_log.txt is better than ksp.log)

Having to use a second upside down base has never been a requirement for the interstage. In fact it was created so that player didn't have to use upside down bases anymore. If he's losing the nosecone then he can probably prevent that by raising the height of the floating node that the upper half is attached to. There's not much clearance and there's probably some clipping going on with the colliders.

Look at PARAM PartRequestParameter, partNames = cupola. That's the only way it knows if the part meets the criteria. It doesn't really know that it is or is not a cupola. Just that the part is named cupola. (that's a unique part identifier and there should only ever be one part with a given name)