Starwaster

By making a Module Manager patch. Better than editing mod files directly. Keep all your personal patches in a special folder that you create in GameData folder. Read the Module Manager thread to learn how write such patches. Also look at this mods files to see how it patches engines. I’ll write a second half to this with more specific examples when I’m at my computer instead of typing on my phone.

The inability to separate resource thermodynamics from part thermodynamics.

Post your logs. Don't paste them directly here, upload them somewhere they can be downloaded from. Preferably Google Drive or Dropbox. Post the link to the logs here. Without the information in those logs I can only guess, but you're probably having exceptions thrown at the wrong time in the VAB. If you're not sure where to find your logs:

I refuse to push a button

Are you sure it's not a feature?

Looks like an optional download, so no.

Boiloff is done by Cryo Tanks. (There's maybe two other mods that also do that like Real Fuels but it doesnt look like you have that installed. Don't remember what the other one is)

I made a pull request with the fix for the node scaling issue. https://github.com/shadowmage45/KSPWheel/pull/78

Looks beautiful! As far as an official update, that's up to @Shadowmage. I can do a pull request with the fix, it's just a single line if he's still around. I'm not actually involved with this mod except as a user.

Here's the dll to test with. I tried it out, looks good, nodes are behaving themselves between loads https://www.dropbox.com/s/kqnicwc26m4ba98/KSPWheel.dll?dl=1

Ok so, the damage is actually being done when the craft (with rescaled wheel) is loaded. I think I see where the problem is and it's been staring me in the face the whole time. I just didn't want to see it because it means that this problem (with the nodes specifically) has always existed. And that we just never noticed it. From UpdateAttachNode(Part part, AttachNode node, float prevScale, float newScale, bool userInput) Vector3 basePosition = node.position / prevScale; Vector3 newPosition = basePosition * newScale; Vector3 diff = newPosition - node.position; node.position = node.originalPosition = newPosition; I think the problem there is because prevScale defaults to 1 and I don't think it's being changed when the craft is loaded (and the PartModule initialized) But newScale comes from the persistent field scale which is saved with the craft file. So let's say I set the scale to 10 (this will give you immediate feedback with the first iteration) Save and reload craft. basePosition = position divided by prevScale (1) newPosition = basePosition times newScale (10) Aaaaaaand we just multiplied our attach position by 10. Every time the craft file is loaded. Should be pretty easy to fix, just set prevScale to scale in initializeScaling(). I'm getting ready to test that now, but that only fixes the node issue. I haven't been able to repro the instability. If anyone wants to throw an unstable rover my way (using just KF + stock + any DLC; I have them all) then I'll try testing with it. Or I can provide dll with the fix for someone else to try. (it would not fix already affected craft, those will need their wheels replaced)

I just realized, whether or not it has a stack node is irrelevant. The stack node just happens to coincide with the surface attach node. It's a good visual indication of what's happening but its presence or absence won't affect anything. They're both being rescaled the same way.

This is where rescaling is happening. https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/Utils.cs#L461-L488 Problem is, that file has not changed in three years. And the function in question hasn't changed in five years. So this is being caused by KSP changes. Probably because of changing the value of originalPosition. Maybe related to the KSP changes that cause robotic parts drifting. I have an idea for fixing this if I can find some time to work with the code and compile and test. Or at least see if I'm barking up the wrong tree.

There’s a section of the code that caught my attention but I haven’t been able to investigate too closely.

@dok_377 This is easily reproducible using the steps you provided. The log doesn't have any errors and I don't think it's going to show anything useful in tracking this down. Regarding your repro steps, this actually starts happening with the first iteration of saving/reloading. The very first time you do that, the wheel is irreversibly corrupted. Subsequent saves of the vehicle make it worse. The attach node moves further and further away every time. I don't get that instability when the vehicle is launched. Maybe because I stopped after 3 iterations. It might be that the wheel gets increasingly unstable the further it is from its attach node. Or maybe my vehicle is just too light, I don't know. I'm going to look at the craft file next and see how it changes between saves. It's probably not writing out the correct position. Or maybe it's rescaling the position twice? Once when you rescale and then rescaling that when it saves. (and actually it is reversible... sort of... you can set the scale below 1 and then save/reload and the attach node position will move closer instead of further)

Interstellar (KSPIE) is further down the rabbit hole than I can go. I have no idea what changes to heating and cooling are going on in that mod so I can't say what compatibility issues might exist between it and Real Fuels or between it and Real Active Radiators. All I can say for sure is that if an RF cryogenic tank is able to detect heat being removed during analytic speeds then it will be able to calculate a proper temperature for the tank in analytic mode.

Stock radiators or some other radiator mod? If you're not already using it, try this: (I'm not sure about compatibility with any other cooling system like Nertea's. I would expect it to be incompatible) (warning: Unlock stock, cryogenic cooling has an added electrical cost and it can get expensive especially if your tank doesn't have MLI insulation)

At what time warp speed? Are you over 100x like I said?

Radiators will do it, yes. Anything that removes heat from the tank part will do. The actual 'analytic cooling' is done by Real Fuels itself. It's just looking for a net removal of heat. (you should only see that message during time warp greater than 100x, when analytic heat takes effect. It's not meaningful at time warp of 100x or less)

There's only one official download source for RealChutes and that is from its GitHub repository. It's linked to from the RealChutes forum thread and also linked to on this mod's first post. If you found a link for it on SpaceDock Edit: Apparently StupidChris did have this on SpaceDock a long time ago (2016) for some releases. Not sure how you got there.... Below is the link to the official RealChutes release page: https://github.com/ChrisViral/RealChute/releases

Then uninstall it and reinstall it, verifying that you are using the correct RealChute files to install from. I don't get that error because RealChutes *is* up to date.

Your suspicion about the problem resulting from being away for an extended time period is probably valid. Real Fuels used to have a similar problem in its boiloff code if the ship were unloaded for a long period. KSP treats heat differently when time warp is greater than 100x (by default) or if the vessel has been unloaded for a period of time greater than a value that I forget the exact value of. Instead of calculating heat for every part, it does a calculation of temperature for the entire vessel. It also records the total amount of heat that each part has absorbed while unloaded, and that might be the part that is making the reactors overheat. IF they're actually accessing that analytic data and trying to do something meaningful with it.

RealChute is up to date. Has been for months.

@TheUntitledGoose let me also add in that even in real life, with the best predictive software that you would have to be doing course corrections. In fact, if you were NASA you would have several course corrections at key points planned for before you ever launched. You might not end up using them but it would planned for. (fun fact: Mars Climate Orbiter, which was lost due to metric/imperial issues? They knew it was off course. Discussed the matter and decided that it would be dealt with at the next planned course correction. Then they kind of forgot to do it)

Lately it's been the ending songs for both Portal 1 and Portal 2. And the Badgers song (badgers badgers badgers badgers A SNAAAAAKE A SNAAAAAAKE OOOOooooo a snaaaake)