Starwaster

The radiator in your picture isn't using my heat pump plugin. Those are stock radiator debugging numbers. Do you have USI tools installed? If so then that's a problem as it interferes with Heat Pumps which uses the name ModuleHeatPump for the PartModule. I've asked @RoverDude to please not use the same name as mine but I never got a response back. His module is based off of the stock ModuleActiveRadiator so it would have the same debugging information in the context menu. Edit: scratch that. You're not even using ModuleHeatPump, just ModuleActiveRadiator. I just noticed your MM cache excerpt there.

New ProceduralParts.dll file: https://www.dropbox.com/s/8385vooo95i6c5m/ProceduralParts.dll?dl=1 What's changed: Added exception handling for part.Modules.Contains() in ProceduralPart.GetModuleCost() Also updated the version checker to check against KSP 1.2.2 so that the annoying compatibility window stops popping up when you run KSP Some caveats about this fix: I cannot test it since I am currently unable to reproduce it. I'd need to know exactly which mod it's tripping up on. But it should fix the problem of the parts list vanishing or other editor issues that this was affecting. If Modular Fuels or Real Fuels is installed then the cost of those parts might be wrong! That would happen under a very specific set of circumstances where a ProceduralPart contains the PartModule 'ModuleFuelTanks' and also contains as yet unknown PartModules which cause errors when part.Modules.Contains() is called. (i.e. if the error was happening to someone and they download this fix then their PP MFT/RF parts may have the wrong cost - but that's better than the alternative of not having a parts list) Regarding item #2, I'll look into a better way to do that check instead of just containing the error, if possible. And I'm not even 100% sure that the cost would be affected. Again though, it only affects someone who was having this error AND has MFT or RF installed too. @baldamundo including you in on this since you were also having a problem with your parts list getting nuked Here are the changes that were made to the source code: https://github.com/Starwaster/ProceduralParts/commit/0cfe78ffa7b655b6a4cc16ae810440c74360b0a0

I think someone reported a similar issue when using PP and DRE though I don't recall the entire parts list getting smashed. At the time I released a workaround fix for DRE but I remember thinking at the time that it was something that could easily affect other mods and sure enough, it is. Pretty sure I know where it's happening. Same error as before but the timing of it seems to be such that it stops the parts list from being initialized. I'll throw in some sanity checking and put up a new file for download replacing the one in my dropbox. Look for that sometime later today; not sure when I can get to it. I'll probably end up doing a fork and doing a release on Github unless either of the maintainers show up before then but they don't seem to have been around since October or November

To my knowledge there are about 4 reported cases of this (including yours above) so I'm going to have to say no. It doesn't seem to be a common issue. If you post your output_log.txt file I'll try comparing it to @baldamundo's log from earlier on this page and see if I can find a common denominator. (most likely some other mod interacting badly with PP) You should run the game to the point that you go into the editor and find your parts list empty. (does that happen immediately upon loading a game save and going straight to the editor?) And is it all parts? Or just some or most of them? Also: If your game is downloaded through Steam, try verifying the cache files for KSP.

No, not at all.

Can't do anything without logs. See the following post if you need to know how to find them: http://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/ (BTW, I have 140 mods in Fallout 4 and it's pretty stable )

Crap somehow I pasted the wrong link. THIS is the prerelease for KSP 1.2.2 https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.5.0 @Crazy-Engineer @Calvin_Maclure @Benti @New Horizons

Behaviorally it would be too much of a departure from stock; these engine configs are 'stockalike'. While it technically isn't a monopropellant engine anymore, it's not unrealistic that there would be a hypergolic engine that serves the same application. Just like most RCS engines are monopropellant, there are also hypergolic RCS especially where you need a higher powered RCS for heavier craft.

Go by what the KSP log says over what CKAN says. I'll fix the readme The current build hasn't been tested with 1.2.1 but it looks like it is the case that it is not compatible.

You said KSP 1.2.2. That's what the prerelease version I linked to is for. If you're seeing 1.2.1.1604 anywhere in your game or log files then you don't have KSP 1.2.2 The DRE menu doesn't use keybinds anymore. If you're seeing references to Alt+D+R then that's something I'll need to remove.

This is what you should use with KSP 1.2.2: https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.5.0 The menu works with the stock toolbar system. There has never been support for Blizzy's toolbar

Yes. The Convection Factor that you see in the thermal physics menu is the same as machConvectionFactor in the PhysicsGlobals. Put that code that I showed you in a file ending in .cfg anywhere in your GameData folder. Edit: Taking a closer look at your physics menu and conduction factor is also wrong if you have RO installed. So something has gone wrong and that patch I gave you only fixes one value. You need to find out what's wrong with your RO installation. Why don't you post your log file and let me take a look at it. Also post your ModuleManager.ConfigCache file which can be found in the GameData folder. Put both of them where I can download them (Dropbox preferably. If you don't have a Dropbox account you should get one) If you're not sure where your log files are:

@eberkain Yeah, it does increase mass flow as well. So, just like in real life, thrust increases can be assumed to be due to other factors besides Isp. Not sure about mass changes. I think I was wrong about TL changes not actually comparing TWR / Mass. It's been awhile since I looked at that part of the code, which was written by someone else. (I did have to familiarize myself with it at one time because those changes were affecting my NTR configurations back when engine configs were still part of Real Fuels) If you have any familiarity with C# coding, most of the relevant code is in the TechLevel class and the mass specific code is here: https://github.com/NathanKell/ModularFuelSystem/blob/8900deb603346da678ed154e15724ee89580a112/Source/TechLevels/TechLevel.cs#L244-L253

MJ has to be able to send control inputs. Those get locked out if there's no signal. I don't know how that could be worked around programatically.

Assuming here that you're referring to the displayed thrust in the editor. The reason it's different is because it's actually displaying sea level thrust and not maximum thrust. That probably should be considered a bug, especially since the editor says "Max. Thrust: 60.065" I don't know if that was a conscious design decision or if someone just accidentally used the ASL Isp instead of vacuum Isp. But your actual maximum thrust is what it says when you hover the mouse over the fuel configuration for the engine, for each fuel mixture button. (meaning that you can't see it if you selected Kerosene+Lox. If you change it to MMO+NTO for instance and then hover over Kero+LOX button then you'll see a different max thrust in the pop-up) I'll open up an issue on the repository site and get some discussion going to see why that was done that way and maybe get it changed so that the displays are more consistent. Or maybe display it as a range of thrust (i.e. 60.065 - 100)

@eberkain IIRC, the TWR entries never actually compare any actual thrust or mass of the engine. Instead, they are compared to each other in the tech level entries to determine how much the thrust has changed between tech levels. It comes into play when you change tech levels using the +/- buttons. That's all. (unless an engine's config explicitly assigns specific thrust on a per-TL basis in its ModuleEngineConfig entries) He didn't say a thing about restarting. Read what he actually said. He launches. His first stage is spent. His second stage is unstable. Answer: Use solid fueled rockets. Easy peasy.

Huh? A ullage motor is just a small solid fueled rocket. Use sepratrons or any small solid fueled rocket that you might have added through mods.

Make a config file with the code found below: You should be aware though that in Realism Overhaul machConvectionFactor is actually set to 1.72 So if it's 7.0 in your game then either you don't have Realism Overhaul installed properly or another mod or Module Manager patch is overriding it. @PHYSICSGLOBALS:FINAL { @machConvectionFactor = 3.5 // Realism Overhaul value = 1.72!!! Set this to whatever you like. //@machTemperatureScalar = 7.5 // Set to 7.5 down from 21 in stock KSP so be careful that this one isn't changed as well. }

AFAIK, Ven's revamp mod actually replaces the models of stock parts. The SDHI ParaDock ClampoTron actually uses the stock model. And Ven's revamp modifies it to add a 'bumper' of some sort, yes? Using the animation module to extend and retract it. That bumper could be interfering with docking, especially if it has animated parts that the SDHI paradock part doesn't handle. A picture of what the Paradock looks like in your game right now might be helpful. (the suggestion that the port is not aligned properly is definitely wrong; the SDHI ClampoTron functions as the stock Clampotron and does not rely on alignment)

Can't replicate that. The only way I can see that happening is if the chutes are attached in a manner that the stock code itself does not see those chutes as being symmetrically attached. What I did to test it was attach a tank to one of four radial decouplers in single, non symmetrical mode then attach a chute to that tank symmetrically (x2) then reattached the tank to the decoupler in symmetrical mode. Then I edited one of the chutes to change its opening altitude to a particular number, then clicked Apply Settings. Then clicked Apply to all symmetry counterparts. You MUST click apply settings before trying to apply to all counterparts BTW. So make sure you do that and also make sure that the game actually sees all those 72 parts as being symmetrically attached. (to verify that, go to the Action Group menu then click one of the RC parts. All its counterparts will be highlighted in blue)

What is your target altitude? I've seen that behavior but suspect that it's more to do with hitting the final stage of its ascent. I submitted some tweaking of the ascent mode quite awhile back and IIRC, what it's supposed to stay basically neutral with regards to attitude, either staying oriented to its last desired target heading or zeroing its AoA. (I forget which) But I think a few months back some pull requests might have changed behavior in the final part of ascent.

There is a fault in the AE-35 Communications Array...

No, there's no such 'feature' in MJ2. You mean if you're in orbit and decouple something it starts doing that? Then it's time for you to post logs as per the first post.

@stali79@rozwell What it looks like to me is that the stock resources have been nuked. All of them. Either because some configs have deleted those resources or because the Squad folder itself has been tampered with. Or deleted. Might be more useful to see the ModuleManager.ConfigCache file than ksp.log at this point. Edit: Unrelated but you also have improperly installed Mk2Expansion parts. (they're installed in Mk2Expansion-1.7.26/GameData instead of the root GameData folder) Edit 2: Yeah, your Squad folder is gone man. There should be 318 lines where it says it's compiling various squad parts (318 of them, natch) and they're just not there. No Squad folder, no Squad RESOURCE_DEFINITIONS and there are engines and RCS parts that are trying to compile but they're choking because ModuleRCSFX or ModuleEngines* is trying to set up the module with nonexistent propellant resources)

The Boost Protective Cover (a fairing covering the Mark1-2 capsule) has a crew hatch on it. The LES sits on top of the BPC.