-
Notifications
You must be signed in to change notification settings - Fork 430
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
system saving idea #4856
Comments
IMO, wherever possible systems should store their game related data on entities, and should ideally avoid having global information for things like wire layouts. E.g., wire layouts should probably be station specific, not game/sever specific. Though in cases where that isn't desirable for whatever reason, I guess it probably would be fine to give systems some data-fields? Though personally it still feels kind of icky. I guess we'll see while adding support for full saves how common it is for systems to actually need it. Regarding serializing nullspace entities, #5572 should hopefully address that. |
serializing nullspace entities is the proper way, along with round entities then systems should only store things like cached lookup collections |
Even for cached lookups it'd be easier to just re-create them, seeing as systems are likely already doing that as entities are created (e.g., mapping system populates its map dict as maps are started). |
yes systems wont need serializing with round entities |
i think its good idea to make persistence properly work
have a way to save all systems (registered as DataDefinition) in yml
then it can save entities in nullspace (station entities!!!, original body when polymorphed) and stop breaking a lot of things
would also need to support non-systems like MapManager
example yaml
idk if there is anything in place like this and if there is how much of this usecase is supported but it would allow proper persistence
The text was updated successfully, but these errors were encountered: