Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flightglobalsindex vol.2 #212

Closed
Sigma88 opened this issue Sep 1, 2017 · 2 comments
Closed

flightglobalsindex vol.2 #212

Sigma88 opened this issue Sep 1, 2017 · 2 comments

Comments

@Sigma88
Copy link
Contributor

Sigma88 commented Sep 1, 2017

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

@StollD
Copy link
Member

StollD commented Sep 1, 2017

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.

@Sigma88
Copy link
Contributor Author

Sigma88 commented Sep 1, 2017

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)

@Sigma88 Sigma88 closed this as completed Sep 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants