You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current system has an advantage over this one: You can change the name of a planet without killing the whole savegame. Additionally, this approach has two rather big flaws:
It would destroy every savegame that was ever created.
GetHashCode() can return negative values, but an array index (and by extension the FGI) cannot be negative. That means we would need our own hashing algorithm.
The current system has been there for too long, so I would vote for keeping it. Installing planet packs into existing savegames isn't recommended anyways.
I agree that the switch to a new system would create a lot of issues for savegames
but I always thought that a better code should be implemented even if that means having some issues at the time of implementation
I agree that this is not a big priority right now, so I guess we could wait a big KSP patch to reduce these issues to the minimum.
adding planet packs to old installs is not recommended, but this would also be an issue for planet packs that want to add a new planet to their lineup
In any case, I think it's worth keeping this idea around in case some day an update will break completely compatibility with old saves (in which case the biggest downside for this would be solved)
right now flightGlobalsIndexs are assigned sequentially with a few exceptions
this can cause weirdness when installing a new planet pack that adds planets in between the existing planets
I propose to change the approach by using:
transform.name.GetHashCode()
this way the flightGlobalsIndexes should be more consistent and it could diminish the amount of problems that could arise from fgi changes
The text was updated successfully, but these errors were encountered: