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

system saving idea #4856

Closed
deltanedas opened this issue Jan 23, 2024 · 4 comments
Closed

system saving idea #4856

deltanedas opened this issue Jan 23, 2024 · 4 comments

Comments

@deltanedas
Copy link
Contributor

deltanedas commented Jan 23, 2024

i think its good idea to make persistence properly work

have a way to save all systems (registered as DataDefinition) in yml

  • MapManager or something has each map -> entity as a datafield (that somehow makes it Serialize instead of just doing mapid -> entity)
  • in content wire system stores the round's wire layouts on it so that is datafield

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

- version: 1
  systems:
    MapManager:
      maps:
        0: <insert persistencesave for nullspace here, which stores station entity>
        1: <insert persistencesave for some map here, which no longer has invalid for station>
    Wires:
      layouts:
        highsecorsomething: <WireLayout data for this round>

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

@ElectroJr
Copy link
Member

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.

@deltanedas
Copy link
Contributor Author

serializing nullspace entities is the proper way, along with round entities

then systems should only store things like cached lookup collections

@deltanedas deltanedas closed this as not planned Won't fix, can't repro, duplicate, stale Dec 27, 2024
@ElectroJr
Copy link
Member

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).

@deltanedas
Copy link
Contributor Author

yes systems wont need serializing with round entities

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