Starwaster

Minor update: Deadly Reentry 7.4.5.1 Don't delete leaveTemp. (causes errors in latest versions of Module Manager) Changes to vernier thermals. (increased survivability of the Vernor RCS part) I don't usually do updates for changes of this magnitude but I don't think there will be another update going out until KSP 1.1.3 and the leaveTemp config causes problems like no MM cache being written so I'm getting it out of the way now. The DLL has not changed or been recompiled so the version number will not change.

@Antonio432 I think I've managed to repro some of your issue but the issue I encountered wasn't that I wasn't able to edit shapes when I should have been able to or unable to resize to sizes that should have been available. It was that I was able to do those things when I should NOT have been able to. There are both minimum and maximum sizes early on in career mode and only the cylinder shape is supposed to be available. What I think is the cause is Kerbal Construction time. When unlocking nodes it enforces a delay to simulate research time and there's probably a race condition in there where Procedural Parts thinks that tech has been unlocked but then has that taken away so it starts enforcing shape/size. (takes away the shape control and changes the min/max values on length/diameter) Edit: And the errors may or may not be a factor.... the PP error will result in thrust not being updated in the VAB/SPH but it corrects itself if the craft is reloaded or the editor exited/reentered. So I don't *think* it's a problem but....

It's not there because of errors in the DeadlyReentry.cfg file that are preventing the cache from being written. Download this file and copy it into the DeadlyReentry folder, overwriting the existing file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry.cfg Then run KSP once and then you'll be able to get the ModuleManager.ConfigCache

I tried duplicating your issue with Tweak Scale installed but I wasn't successful. Definitely had the same version you have installed (so it's the latest version of TS). I noticed in your log that there was an error in KSPAPIExtensions, apparently when you were editing a procedural SRB? Is that what you were doing when trying to change shape/size? Also, could you provide your ModuleManager.ConfigCache?

Point conceded. If they smashed into the ground then maybe there's a possibility that they were heading downwards I wonder if maybe setting the timer on them might help? (it's in the settings screen for the chutes when you're editing them...)

If the 'must go down' option is enabled then those chutes won't deploy until they have negative vertical velocity. (down) Also, Stage Recovery doesn't require the chutes to have been deployed or (at least last time I checked) to have even been armed. All it requires is that they are on the part(s) you want recovered.

The logs indicated a collider issue rather than an animation issue as being the cause of the crashing, though neither should be able to crash the game, so I'd say there's a serious bug in there somewhere.

Ok I was just sitting down to look things over but a major lightning storm swept through and I had to do an emergency shutdown so maybe later. Can't do much from a mobile phone. One thing though... Did I see tweak scale? Might want to try without that. It's caused problems before. Or update it if it's not the latest version. Even if it's not the culprit here though, be aware that it's causing issues elsewhere.

You will want to redownload the repo, I just made some changes to address some of the exceptions. At some point I renamed a part module and I think Github for Windows ate some of the changes. (specifically some hard coded references to the old part module name) I'm in the process of testing the new changes. The specific changes from KSP 1.0.x to KSP 1.1 are known and well documented and shouldn't present much of a problem Edit: So still seeing exceptions and had a male Kerbal clone himself.... Edit #2: But some things that weren't working are, such as CO2 generation and CO2 scrubbing, so, progress. Edit #3: Cloned Kerbal and other exceptions were caused by a bug in Deadly Reentry that was fixed recently but not for KSP 1.0.5 Edit #4: I think the current build is ok to push out but the rate of O2 consumption bothers me. Or maybe it's just the storage amount in the pods. I have to look at my spreadsheets and see what's up because it should be lasting longer. It's possible I might have done my calculations per second forgetting that consumption rates are per FRAME. If that's the case I'll just compensate for it in the code because all rates should be based on human friendly values (seconds, minutes, hours, etc) Meh, rates are ok I guess. Mk1 pod has enough to last for 2 days without additional supplies so I guess it's ok.

I use this. I think I based it off of Realism Overhaul or something... or maybe I just pulled that number out of thin air. @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]]]:NEEDS[!RealismOverhaul]:FINAL { @MODULE[ModuleDeployableSolarPanel] { @chargeRate *= 0.1523889 } }

@Waxing_Kibbous Ok, I recompiled with those changes and that does fix the cloning issue, but there are still nullref exceptions during EVA that seem linked to resource handling, also recycler issues. (memory coming back; some of that is on this very page in fact) So still needs lots more work

The centrifuge is the only part that does that. Other parts are safe to use.

I don't mind you 'bothering' me. Honestly I'm bothered that I've let this mod languish, though as I've said the reason is updateability . I believe the problem is HERE: https://github.com/Starwaster/Ioncross-Crew-Support/blob/master/Source/IoncrossCrewSupport/IonController.cs#L323-L338 Kerbals on EVA are vessels and they have a part. Inserting modules into them requires special handling because the part does not have a cfg in the database and is instead handled at runtime so we have to handle them at runtime as well. (and, really Google? runtime isn't a word? Get with it!) The part name for a female Kerbal is kerbalEVAfemale and it wasn't being handled in there. You will notice that I just committed a change to that file to process female Kerbals.so download that file or just grab the changes and insert them locally and try recompiling. I'll look into pushing another update out but IIRC there were some other issues with 1.0.5 that were requiring attention. We'll see.

Oh changes were definitely made. Being able to fling yourself directly at the planet at steep angles isn't a realistic mechanic so yeah, you're going to have to be mindful of your trajectory.

I did recompile for 1.0.5 when I was looking into updating it but I don't remember if that stopped the cloning or other issue and I got sidetracked with other things and didn't get to further updates. I think it was an exception that occurred during initialization of the Ioncross EVA part module. Because of where that would have occurred in the spawning process it would have stopped KSP from executing the rest of its code that would have cleaned up the Kerbal from the originating crew part. The KSP/Unity tools are not required or used in compiling a KSP plugin unless you're doing something like asset bundles. Ioncross doesn't require that. What you do need to do is to add in necessary references to KSP. I think Assembly-CSharp.dll and UnityEngine.dll was all that was required but there might have been others. I use Xamarin Studio. If you have the Unity editor/tools installed then you have Monodevelop, which is basically the same thing but it has annoying GUI bugs because it's not updated as frequently as Xamarin. (so I use Xamarin) Visual Studios can also be used; not much to say there, same thing, link to the necessary KSP dlls.

Yes, exactly as I did it in that example. part1, part2 and part3 would all have the same config applied to them. I don't know if there are any real limits as to how many parts you can do at once but there are practical limits in that you might find it inconvenient do cram too many on one line.

... What do you mean it 'sticks out'... you have a component that is not itself designed to withstand reentry heating peeking out past the edges of the heat shield? Is that what you're saying I'm so sorry but that really doesn't sound like tiger's blood winning to me. Look, when you stop doing that it'll stop hurting. Make sure that your shield completely covers whatever it's shielding. Anything poking out past the shield is going to get heating. Not as much as if it were totally unshielded but it would be exposed to reentry heating. Also, the words 'collision course with the planet' are setting off all kinds of alarms for me because if you're saying what I think you are then that means too steep. That IS a problem. One of two things will happen: You'll hit the denser parts of the atmosphere at hypersonic speeds and either the increased heating will burn up your craft or it will be going too fast for chutes to work and smash into the ground. You should be aiming for an altitude of 20-30km (i.e. periapsis of 20-30km) to ensure a safe reentry over stock Kerbin. Too steep = burn up or experience lithobraking. Too shallow = shield burns out due to slow baking.

I don't know if commas work there but I know that | does work: @PART[part1|part2|part3] { ...do stuff... }

+PART[PartName] { // You must rename the new part @name = NewPartName // Delete the Ore resource !RESOURCE[Ore]{} // Add your new resources here }

Well guess what. Other people can use Real Fuels and Procedural Parts and WE don't experience the problem that you are so it looks less like Real Fuels 'bugging' Procedural Parts and more like a problem with your installation. But so far I don't see anyone in a hurry to play guessing games as to what your problem is. And that's basically what you're asking us to do. So either reproduce the problem with logging enabled and provide logs as detailed in the post I referred you to or start doing standard troubleshooting procedures on your own: Start over from the beginning and reinstall everything from scratch, starting with just KSP + Module Manager + Real Fuels + Procedural Parts. Make sure to redownload the latest of everything.

Unfortunately I haven't had a chance to give this the attention it needs for KSP 1.1.x Based on known changes to the KSP code base it almost certainly is not going to work with the current KSP What it really needs is a major rewrite that is less prone to breakage when KSP updates. I've always liked Ioncross because of its massive amount of configurability. Most people don't realize the extent to which the mod can be customized through its config files alone. More than any of the more popular life support mods even. But the code is way too complex for what it needs to do which makes maintaining it difficult

Here's a config with comments as to what each thing does. Note that heatTransfer is technically optional and is only 0.1 by default. Heat Pump works by intercepting conducted heat and providing just enough cooling to neutralize the heat that is in danger of penetrating the tank wall into the tank contents. A non-zero heatTransfer is basically actual refrigeration beyond insulation cooling. This really should not be set very high unless the application is some sort of ISRU making cryogenic fuels. Default is 0.1 So basically the way HP works is that it just intercepts incoming heat and provides just enough cooling to prevent that. For ZBO purposes a cryo tank really should have a lot of MLI installed but no existing tank parts are actually configured this way. Even the RF Cryogenic and BalloonCry tank types don't provide the type of insulation required for long term Earth-Mars voyages. That's what skinInternalConductionMult is for. Basically that needs to be set low enough to reduce heat penetration to watts instead of kilowatts if the objective is actual ZBO. (so in other words passive AND active heat management). In the example below it's set to 0.00005 which should be enough to reduce heating from solar/planetary flux to a few tens of watts down from several kilowatts MODULE { name = ModuleHeatPump // Active tank refrigeration. Set this if you want cooling BEYOND heat penetration removal heatTransfer = 50 // Part's heatConductivity. Only gets set if provided value is lower than the part's current values during HP initialization heatConductivity = 0.12 // Part's skin-internal conduction factor. Only gets set if provided value is lower than the part's current values during HP initialization // This is meant to represent any multi layered insulation present skinInternalConductionMult = 0.00005 // Percentage of max temp (skin and internal) at which throttling occurs radiatorMaxTempCap = 0.8 // One RESOURCE node for each resource you want consumed (or gained!) for each watt of heat removed. // NASA documents state that 114 We are required for each Wt removed RESOURCE { name = ElectricCharge rate = 0.114 } // Need one of these for each attach node that you want heat to be removed through // name is either attach or the name of the stack node (i.e. top, bottom or other stack name) HEATPUMP_NODE { name = attach } }

The rotation will happen when over a menu that isn't properly locking controls. You won't see it in the stock menus but you will see it for mod menus. Whichever menu you're mousing over when rotation occurs is the mod responsible. MechJeb is known to cause it but it is fixed in the current dev releases so if MechJeb menus cause it then download the latest dev menu. If it happens in the menus of other mods then report it in that mod's thread and refer them to these sections of code in Deadly Reentry: https://github.com/Starwaster/DeadlyReentry/blob/master/Source/DRToolBar.cs#L108-L122 and also: https://github.com/Starwaster/DeadlyReentry/blob/master/Source/DRToolBar.cs#L146-L175 That's how to lock controls without camera rotation in the map screen.

Post logs please. Consult the following thread if you don't know where your logs are. (and yes you have logs even if you're not experiencing crashes unless you disabled logging)

Regardless of whether KSP has crashed or not, there are always logs created unless logging has been explicitly disabled. You should post those logs whenever submitting a bug report as it helps a modder in debugging a mod. (output_log.txt from either KSP_Data or KSP_x64_Data depending on whether or not it's 32/64 bit. player.log if on Linux or Mac)