Pretty much everywhere in the code, indexes are used and stored instead of keys.
Example in the planManager:
These indexes are stored in an object's planState and will persist across sessions.
This is fine when no mods are enabled but with more and more mods adding skills, actions, plans and whatnot, this system is flawed.
When a mod adds one of those typeMap object, an index is generated at runtime.
However, if a new mod is added to the world and loads earlier than the other mod, the newly generated index doesn't represent the correct object anymore.
This could result in really strange behaviors.
The solution is very simple however. Start using keys instead of indexes. Keys identify objects better.
If I give my plan the key "witchyPlan", it won't matter if a mod that loads earlier added the plan with key "notWitchyPlan".
My own key won't change.
This would break current worlds however (unless you add a tag "usesKey = true") somewhere.
WitchyMods
commented
1 year ago
Pretty much everywhere in the code, indexes are used and stored instead of keys. Example in the planManager:
These indexes are stored in an object's planState and will persist across sessions.
This is fine when no mods are enabled but with more and more mods adding skills, actions, plans and whatnot, this system is flawed. When a mod adds one of those typeMap object, an index is generated at runtime. However, if a new mod is added to the world and loads earlier than the other mod, the newly generated index doesn't represent the correct object anymore.
This could result in really strange behaviors.
The solution is very simple however. Start using keys instead of indexes. Keys identify objects better. If I give my plan the key "witchyPlan", it won't matter if a mod that loads earlier added the plan with key "notWitchyPlan". My own key won't change.
This would break current worlds however (unless you add a tag "usesKey = true") somewhere.
Thanks!