Kerbal Space Program

Could be related to the fix for Bug #24855. Unlike that bug, this one appears to have no workaround...

jj wrote:

I don't see how this is low priority, since it
1. Practically breaks the feature and all contracts related to moving asteroids, since it makes moving them exponentially harder than it already is.
2. Breaks a feature that has worked before.

Good grief. I gave up playing this game many months ago because of the previous asteroid bug (#24855).
Having seen that it had been fixed, I have just resumed playing and tried to finish some missions. After mucking about and editing my save files to (I thought!) fix the initial discrepancy, I found that the mass keeps leaping back up and that indeed the system mass INCREASES when you start harvesting.

So yes, I'd echo jj's comment - how on earth can this be low priority? It completely knackers the asteroid feature of the game.

tjandreas wrote:

Additional info: apparently the game is resetting all asteroids to their original mass values when you fly them. Even on asteroids I mined out years ago. The PotatoRoid "mass" property in the save file is no longer consistent with the "currentMass" property of the ModuleAsteroidInfo module.

I'm very keen to understand how it's deciding what the original mass of the asteroid was (I'm seeing something like this happening too).
If we can understand what it's using for that calculation, we perhaps stand a chance of editing the save file so as to mitigate the bug - e.g. put the mass down to a reasonable (or even the correct!) level again before each burn...

I've looked in the save file and tried a few things but have not yet found a way to do it. (If this issue is already under discussion on the forum I'd welcome a link, because my searches have turned up nothing.)

OK, no idea if/where I should post this on the forum - have seen no sign of a discussion about it there, just a few vague references (and maybe one to this bug page) - so here's my recipe for working around the bug, which I found accidentally while attempting to understand it.
It's a faff but it appears to work very reliably (not yet had one I couldn't fix but some took a few attempts).

• capture one or more asteroids, because you can't "fix" them until after capture
• release the asteroids to be fixed, and back off a wee bit because the shape will change (then cancel velocity to make recapture easier later!) - if you don't release first you can still fix it but will regret it later when you try to release it :-D
• make a note of the asteroid names
• save the game, make a copy of the SFS file, and edit the copy
• for each asteroid to be fixed: search for the asteroid name until you find its VESSEL entry, and then find the seed value in the ModuleAsteroid section
• search and replace all instances of that seed with a new value (one instance in ModuleAsteroid, one for each contract for which the asteroid is a match, maybe others)
• how to choose "a new value"? bizarrely almost anything seems to work - this could mean changing it by a single digit or going for something totally different; I've tried various things and more than 90% of my changes were successful, but of course I have no clue why
  (class C example: I replaced 5ish instances of 35983897 with 35983898; class D: replaced 4 instances of -58758673 with -58758672; class E: I replaced -28602474 with -28602462 when -28602473 and -28602472 didn't work)
• load the edited file and recapture each asteroid (shape change means some repositioning may be necessary for a clean capture)
• verify if the system mass is now correct (i.e. matches sum of pre-capture ship mass & asteroid mass shown when you right-click) and that the system mass stays constant when mining; if not, re-edit file and choose another seed (even 0 worked for me during testing(!!), but would clearly have bad implications for asteroid-related contracts and I didn't test having two asteroids with the same seed)
• ponder why in heck changing the seed should influence the buggy behaviour (I really really want to see that bit of source code!)

Update: the workaround can "expire". I've observed that with a particular class E (the same one that had required several attempts), the system mass was suddenly way too high and increasing, after I had taken its true mass down from 1950ish tons to 1650 ish. Need more testing to understand what happened and at what mass, but its definitely reproducible. (This may be an insight into what madness is going on in the source code :-))
Happily I was still able to "fix" it again by re-changing the seed, so at worst the workaround seems to do what I originally wanted and permit maneuvering, even if it needs to be recharged now and then. (NB: only one asteroid seems to have exhibited this so far, with several others behaving OK.)

Edited 5 days later to add:
Sadly, the fix now seems likely to be temporary on all asteroids, and stops working entirely at some point (i.e. I stop being able to find a new seed which "works").
The combination of seed and class appears to create a non-zero minimum mass for each roid. So I can't land my 112 t mined-out class E on Kerbin because KSP thinks it's more like 800 t. I tried a bunch of seeds for that one (literally a couple of dozen), and the effective asteroid mass ranged from roughly 800 t to almost 3600 t. (Again, I'd love to see the code because just maybe there's a seed which gives an effective mass closer to the real thing.)
No more asteroid contracts for me for the time being; back to waiting for the bug to be fixed.

Edited again to add:
Well heck, seriously red face here. I have no idea how it took so long for the penny to drop, but I've belatedly realised that all I was ever doing by tweaking the seed was "choosing" a lighter "birth" mass for the roid. As long as this was lighter than the current mass, the bug didn't bite because (as tjandreas pretty much says above), the bug simply means that the roids can never be lighter than their nominal birth mass. If you start with a roid that's relatively heavy for its class, you will easily find a new seed which corresponds to a much lighter birth mass, allowing you to mine it and move it without pain. If you start with a light roid, or mine most of the mass away, you're stuffed unless you change the class, but that change would I imagine break any contracts you might want to complete. (PS: I no longer feel like I need to see the source code because the behaviour is no longer a mystery, LOL.)

This affects console edition too.

I can confirm this bug is still happening as of KSP 1.11.2 (windows-10 64bits)

vinix38 wrote:

I can confirm this bug is still happening as of KSP 1.11.2 (windows-10 64bits)

Vinix38. We made some changes in 1.11.2, but are very interested in learning more about what you are seeing after the update. Could you give us more details? A save file would help us a lot.

victorr wrote:

vinix38 wrote:

I can confirm this bug is still happening as of KSP 1.11.2 (windows-10 64bits)

Vinix38. We made some changes in 1.11.2, but are very interested in learning more about what you are seeing after the update. Could you give us more details? A save file would help us a lot.

As described many times above : mining an asteroid decreases the mass shown in the PAW, but not the physical one. A completely mined out asteroid has the exact same weight as when it was fresh. This is a stock behavior, but the addition of informative mods shows clearly the ship's mass increasing when it should be in equilibrium.
It is most game-breaking when trying to land with parachutes or calculating delta-V.

We have made some changes in this last 1.12.0 release and would like some feedback on this issue. Thanks.

I can confirm, the bug is fixed (also on an old save)