global.hasSystem[index] is nil from old version about advanced-logistics-system HOT 2 CLOSED

Before 0.13 when you accessed a certain technology using force.technologies the entire technology table got indexed, which had a huge impact on performance when the check ran on tick events, so some sort of "cache" was needed and also using research events.

This is not really "required" anymore, but i don't see any reason to remove it, as it's still good to cache the value, also i don't think it's related to this issue.

If it's an save from 0.12 that already had the mod installed and tech researched, globla.hasSystem "which uses the force name as a key, not the player index" would be already set, the issue here is the change of style names, it apparently doesn't update the icon gui element to the new style if it already exists, which is why i added a way to force the change in initGui method.

anyway, i think this update 3ff8c16 should fix the issue, and also makes sure the globals are loaded for new installs as well.

Please check and let me know.

from advanced-logistics-system.

On the caching of hasSystem, I noticed that the system can be activated using a remote call, bypassing the research so that makes it required anyway.

Concerning the issue with global.hasSystem[force] not being set, this is partly my fault (I used ALS 0.2.9 naively thinking it was the latest release before 0.3.0) but this particular version really did not set global.hasSystem[force]

Looking at on_configuration_changed I can't help but notice that it's mostly incorrect though.

Doing version checks on newVersion (newVersion == "0.2.10", newVersion == "0.2.12") is basically useless because of course the new version will be >=0.3.0 now.

Seeing that so much code is duplicated, I think you'd be better going with a generic on_configuration_changed, the if oldVersion <= "0.3.0" block seems to be a good starting point that should cover all updates scenarios from any older version. Also note that doing string comparisons on version strings is incorrect, because "0.2" > "0.19" is true for instance.

Another issue I noticed is that loading from a 0.2.9 save with the GUI opened will cause the old GUI to appear completely messed up when loading it in 0.3.0, I think upgrading should destroy any old GUI and create a clean one from scratch. Fortunately the old GUI was closeable so it's not a big deal but if a future release renames the buttons, the user could potentially be left with uncloseable GUI

Anyway, I'm going to send you another pull request addressing those issues soon, so stay tuned!

from advanced-logistics-system.