1..3.1 Asteroid procedural generation reset?

[paddywroks]

After updating my game today my ship that was clawed onto an asteroid was partially submerged into the asteroid, leaving me unable to undock without RUD. The asteroid also happened to be a different colour(still magic).

Something in the update must have changed the procedural generation and given me a newly shaped asteroid that ate my ship.

Reverting to 1.3.0 and loading a previous quicksave gave me back my original asteroid thankfully.

Can anyone else confirm?

[OHara]

Yes.   

Asteroids from older (1.2-ish) save-games change shape in KSP 1.3.1,  but these asteroids did not change shape in the 1.3.1 preview.  

Spoiler

KSP 1.3.1 is using scientific notation to write seeds longer than 7 digits into 'persistent.sfs'.   Asteroids from older saves tend to have longer seeds.

sometimes it is a simple rounding: seed = 18535762  =>  seed = 3.816028E+07
sometimes something less obvious: seed = 86682893  =>  seed = 8.66829E+07 => seed = -7.02231E+07 after next save

https://bugs.kerbalspaceprogram.com/issues/16087

Edited November 15, 2017 by OHara
link to bug tracker

[paddywroks]

Thanks for confirming this and writing up the bug report.

[Squelch]

This change was an unfortunate necessity, and has caused some asteroids to change shape when they have been saved in a previous version, and now loaded in 1.3.1. I have updated the issue with a workaround of undocking the asteroid in 1.3.0, saving, and then updating to 1.3.1 where the asteroid can be captured again.

[OHara]

On 10/11/2017 at 3:10 AM, Squelch said:

This change was an unfortunate necessity, and has caused some asteroids to change shape when they have been saved in a previous version, and now loaded in 1.3.1

I was wrong to imply that only older save-files show the issue.   Newly-created games also spawn asteroids with shapes that change.  After a few saves/loads the asteroid settles into a stable shape.  I put a pure-1.3.1 quicksave.sfs on the bug-tracker that gives a differently-shaped asteroid on every F9.

Strangely, Squelch was not able to reproduce the issue using the steps I gave.  Maybe something specific to Windows 10 or my localization settings ?   It would give me peace of mind if someone else can confirm the bug using the safe-file on the tracker, or these steps :

To reproduce:
Scenario "Asteroid Redirect Mission 2: ready to capture" 
Screenshot asteroid
Quicksave / Reload
Note asteroid shape has changed

[Rune]

More info I guess, because I found this only after  posting myown issue under modded installs:

 

1 hour ago, Rune said:

I am posting this here, because I do run a modded install. But I seriously doubt it is a question of mods! Anyhow, a description of the issue:

Asteroids keep changing seed, basically, like the title says. After being perfectly stable for a long time, and having placed a ton of stuff on them with KAS, suddenly the other day I went to one of them rocks, and found that the asteroid had swallowed the ships docked to it. Fortunately, the game now does backups, so I could backtrace the issue to before it happened, and replicate it, taking pictures this time. I think the important bit is the last error, the rest is just a very old save with a lot of mods removed (I think, but would gladly be informed otherwise):

With a bit of savegame editing I found that the thing that was happening was that the asteroid kept changing seed when I made a new save, but it would load old or new savegames with the old seeds with no issues. So yeah, I could short of undo the damage. But it would keep changing the seed if I saved after loading that vessel. Well, I left that one alone, changed the seed back manually without it loaded, and proceeded to load another asteroid station, just in case. And then this happened:

That is not cool. That base in particular is one of my oldest ones. It has survived four game versions, and still has 600mT of unextracted ore inside. The thing has not exploded, incidentally. It is just an empty globe of stuff (You can see I even wrote stuff with solar panels on the surface) attached to a rock that suddenly is much, much smaller. I actually use it a lot, and building such a thing is complicated. Again, it keeps switching seeds whenever I save with it loaded, but is very happy to load with the old seed from an old backup save, and won't change it unless I save with it loaded (but persistance.sfs autosaves whenever you switch vessels, so loading it means the seed changes immediately). No idea why, it doesn't throw out an error until I load the new save with the wonky seed either! The new seed is something very similar to the old one, but '-2.251617E+07' instead of '-22516169', for example, if that helps in any way.

Could somebody help here? I don't want to fiddle around with KAS for one hour only for it to happen again immediately afterwards! And I strongly suspect KAS is not to blame here, because the first time it happened, it was with a ship towing a new rock, docked to it with a Klaw and without stuff surface-attached to it yet.

...

I am short of glad I was not crazy, and this is a thing that happens. Going by @Squelch's comment, and after more tinkering, apparently it's only seeds with >8 characters that get converted to scientific notation... which ends up with a 8 digit number converted into an seven-digit number, with a rounding error ensuring they are not the same. I've tried manually converting the old seed to scientific notation... but since it has eight characters (I assume it's because of that), the game just assigns a new completely different seven-digit one without scientific notation.

 

Rune. Was that really neccessary, and the old seed completely irreproducible? Because it has seriously bummed my day, I have like ten of these asteroid bases in my save.

Edited November 14, 2017 by Rune

[OHara]

16 hours ago, Rune said:

Was that really neccessary, and the old seed completely irreproducible?

No.  AllisTa (who adopted the TCA mod and maybe others) investigated and found out that KSP now tries to put the seed in localized number format, which uses scientific notation for numbers larger than 7 digits. (Generally we do not want numbers in save-files to be localized, written 3.1416 or 3,1416 depending on user location, because they are primarily computer-read and we want to be able to exchange them.)  

@allista included a work-around mod in his utility package; see the bug-tracker entry for details (making yourself a login if needed) or his github.  That work-around will preserve asteroids so long as you have a save un-corrupted by 1.3.1, or at least the seed.

Note that I was wrong initially to imply that only old saves were affected. @Squelch's work-around above will not work in general -- save/load cycles in 1.3.1 continue to generate fresh asteroid shapes, until the random number generator happens to generate a 7-digit or shorter seed.

Edited November 15, 2017 by OHara

[Rune]

11 hours ago, OHara said:

No.  AllisTa (who adopted the TCA mod and maybe others) investigated and found out that KSP now tries to put the seed in localized number format, which uses scientific notation for numbers larger than 7 digits. (Generally we do not want numbers in save-files to be localized, written 3.1416 or 3,1416 depending on user location, because they are primarily computer-read and we want to be able to exchange them.)  

@allista included a work-around mod in his utility package; see the bug-tracker entry for details (making yourself a login if needed) or his github.  That work-around will preserve asteroids so long as you have a save un-corrupted by 1.3.1, or at least the seed.

Note that I was wrong initially to imply that only old saves were affected. @Squelch's work-around above will not work in general -- save/load cycles in 1.3.1 continue to generate fresh asteroid shapes, until the random number generator happens to generate a 7-digit or shorter seed.

That is really helpful, thanks! I still have all the old seeds in various savegames, so I imagine if I can get that to work, it will pretty much solve all my issues.

 

Rune. Good thing I make backups of the backups.

[Tyko]

I'm in the early stages of a new 1.3.1 game is there anything I can do to prevent new asteroids from suffering this problem? i'm wondering if I could go into the save file and edit the seed for asteroids I'm planning on capturing so it only has a 7 digit seed. Would something like this work?

 

EDIT: It looks like the seed number isn't generated when the asteroid first appears. At least I couldn't find it in the code related to the asteroid in the Persistent file. When does the seed actually get generated? When I first get into physics range? 

Edited December 30, 2017 by Tyko

[Tyko]

I found a workaround for this that works consistently - 

An asteroid doesn't get a seed value until the first time you get within physics range of it. Once you're in physics range the game generates a seed that shows up like this in the Persistent File:

MODULE
                {
                    name = ModuleAsteroid
                    isEnabled = True
                    seed = 5109506E+07
                    AsteroidName = Class A Test 1
                    prefabBaseURL = Procedural/PA_A
                    currentState = 1
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }

If you do nothing, that Seed number will randomly change when you reload the asteroid. Here's the workaround...

1. In the tracking center - note the name of the asteroid. It'll be ast-XXX - You can change the name now if you want to.
2. Complete your rendezvous with the asteroid, but don't actually attach to it. Just get within physics range.
3. Slow down your approach so you're within a few hundred meters, but not about to collide with it.
4. save and exit the game
5. Go into the Persistent.sfs - Always a good idea to make a copy
6. In your fav text editor do a Find on the name of the asteroid and scroll down to the Module listed above.
7. Change the seed to any 7 digit number you choose. - I've just been lopping off the "E+07" portion and leaving the rest of the number as generated. So my new seed # will be 5109506
8. Save your Persistent file and reload the game
9. Finish your Clawing maneuver on the asteroid.
10. PROFIT!

 

Edited December 31, 2017 by Tyko

[Rocket In My Pocket]

50 minutes ago, Tyko said:

I found a workaround for this that works consistently - 

Many thanks!

This will be most helpful, I've been putting off an Asteroid mission for fear of this bug.

[cfds]

I just stumbled across this thread and I am wondering: What change would make it necessary to save completely fine unsigned integers in scientific notation (disregarding that stuff like 5109506E+07 is not even scientific notation..)? Sounds more like someone mixed up his arguments for printf....

[OHara]

19 hours ago, cfds said:

What change would make it necessary to save completely fine unsigned integers in scientific notation

It turned out that saving seeds in scientific notation was not, in fact, necessary.  AlistTa posted on the bug-tracker some debug output that showed that the cause was inappropriate use of an output formatter (link) that is much less general than printf, and which KSP shouldn't be using for save-files.  

This finding made it obvious the bug was fixable, got the report tagged "being worked on", and I would expect it to be fixed in 1.4.