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

Persist panel visibility/position within save #7

Open
kendallroth opened this issue Jul 18, 2024 · 5 comments
Open

Persist panel visibility/position within save #7

kendallroth opened this issue Jul 18, 2024 · 5 comments
Labels
enhancement Update to existing functionality question Further information is requested

Comments

@kendallroth
Copy link
Owner

kendallroth commented Jul 18, 2024

Inspired by #2, the panel visibility and position should be persisted within a save game. This will require storing the values in a serializable entity (or component?) in ECS, that could then be automatically persisted to the game save. However, this depends on whether there is actually value to this, as compared to other options...

  • Add a setting to toggle whether panel is open or not when loading any save game ✔️ (implemented)
    • Definitely easiest, might also offer enough value to skip the other options?
    • Probably not necessary if choosing either of the other options, although could be then treated as a default for new saves
  • Persist panel visibility/position "globally" (ie. across saves) via writing to ModSettings/
    • Most people will probably keep the panel in the same location across their saves
    • Potential (minor) downside would be forcing the same visibility state across saves
  • Persist panel visibility/position within individual saves via entity serialization ⚠️ (likely unnecessary)
    • Definitely most complex (due to limited knowledge of ECS), but also most flexible
    • Not sure whether it would provide enough "benefit" to justify the development though???

System docs

krzychu124: for panel position, I suggest storing it on C# side, value binding to read, calling a trigger from UI with new value when position has changed. Serialize in UI system entity component, when deserializing, validate with current screen resolution, reset if out of bounds.
reset will be trivial since it will just overwrite value of the binding that UI is reading
panel visibility can be done similar way

PoliteCanadian: To modify data in a save game, would I simply persist it within a registered entity component ("simply" is probably an oversimplification, but it does make sense that the game entities would be persisted somewhere in each save game 🤦‍♂️ )

krzychu124: when a component or system implements ISerializable interface (sometimes needs a few more) it will be automatically picked up by serialization system and processed as any other savegame data
here example from Traffic mod, the system, besides running a job you can ignore, is saving and restoring a version number when the game is serializing or deserializing the savegame data. It's fairly straightforward.
https://github.com/krzychu124/Traffic/blob/main/Code/Systems/DataMigration/TrafficDataMigrationSystem.cs
so you just need IDefaultSerializable, ISerializable three methods from the bottom of the file and a field or fields to store the data which should be serialize

@kendallroth kendallroth changed the title Persist panel visibility/position within save game Persist panel visibility/position within save Jul 18, 2024
@kendallroth kendallroth added feature New functionality or workflow enhancement Update to existing functionality help wanted Extra attention is needed and removed feature New functionality or workflow labels Jul 19, 2024
@kendallroth
Copy link
Owner Author

kendallroth commented Jul 19, 2024

Persisting panel visibility/position within individual save files is likely unnecessary, as players probably wouldn't have different visibility/position per save. Per-save data may be more useful for configuring which stats are available, but even that could be done as global settings or a ModsData file (both might make more sense) 🤷.

@kendallroth kendallroth added question Further information is requested and removed help wanted Extra attention is needed labels Jul 19, 2024
@skst
Copy link

skst commented Aug 29, 2024

FWIW, I'd actually prefer the position and stat selection to persist globally, so I do not have to set (or update) them for every city.

@kendallroth
Copy link
Owner Author

Yeah, I'm honestly not sure which approach to take...which is why I've kinda put this on the back-burner for the time being... I do agree there is probably more value in persisting the setting globally than per-save, as I doubt that would really ever occur.

  • Do not persist panel visibility/position anywhere (current)
  • Persist panel visibility/position globally in settings
  • Persist panel visibility/position locally in save game

@skst
Copy link

skst commented Aug 30, 2024

Well, not that you're asking me 🙂, but (again, FWIW), perhaps implement the global method first. That sounds like the easiest. Then, if you feel like it or people beg for a per-city setting, you can add the ability to override the global setting for a given city.

(I assure you, it's purely a coincidence that I prefer the global method.)

@kendallroth
Copy link
Owner Author

Yeah, I could definitely see storing the panel position globally (via settings or ModsData/), and this would probably be what I try before per-save (at this point).

I'm not entirely certain about storing the panel visibility globally, as there is already the setting to open upon load or not, which seems sufficient... I think the next related change I would make would be to remove that setting in favour of storing the panel visibility per-save 🤷.

However, I'm probably not planning to store the stat selection globally (missed this in first request), as that is persisted within each save, and may change over the lifetime of the save as city services become available or concerns change, etc 🤷.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Update to existing functionality question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants