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
Refactor game state specific things into new GameState structure. #21193
Comments
#21193: Move gCash to GameState_t, refactor uses
#21193: Move gInitialCash to GameState_t, refactor uses
I’d like to “reserve” these:
|
I could do all of the climate ones to help out.
|
Also changed a few instances where GetGameState was called inside the same function. The change in Peep.cpp is needed because of a function conflict. FormatStringID exists both in the global and in the OpenRCT2 namespace.
Also changed a few instances where GetGameState was called inside the same function. The change in Peep.cpp is needed because of a function conflict. FormatStringID exists both in the global and in the OpenRCT2 namespace.
Also changed a few instances where GetGameState was called inside the same function. The change in Peep.cpp is needed because of a function conflict. FormatStringID exists both in the global and in the OpenRCT2 namespace.
I’d like to reserve:
|
I'd like to reserve the remaining
|
#21193: Move gParkRating to GameState_t
I’d like to reserve the gScenario* globals. |
I would like to reserve the following guest related globals...
|
I'll do
|
I can do:
|
@ZehMatt Shouldn’t the following variables be in here as well? gEntityLists |
No, they are not saved in the file and are typically rebuilt upon loading it. |
Done the |
I know they’re not saved in the file, but they are still gamestate-specific. That is to say, they are specific to the currently loaded game and using the list/index of one park on the other will cause severe problems. |
Yeah, we need to refactor that part a bit better but they don't really belong in the game state, that is more a system specific state. I would like to split those things apart so that the entity spatial index is its own thing and not part of the entity registry, the tiles mapping should be also separated. The best way would be to have system based events, example: Entity registry notifies the Spatial mapping that an entity is removed, moving an entity also notifies the spatial system and so on, we need to better separate responsibilities in general. |
I can do the following:
|
I can do:
awards |
@Harry-Hopkinson there is already a PR for that #21554 |
Sorry about that, did not realise. |
@Harry-Hopkinson You can also do |
Is that it, have we finished moving them All? |
Hm, maybe. There is a similarly needed structure called |
Yea, all of the data it currently holds should be moved into GameState_t, minor oversight due to how those classes hide the data. |
Was |
Yes, that seems appropriate. I updated the initial post. |
Starting with #21122 I created a new struct called GameState_t which should carry all game state related variables. Following variables should be put in GameState_t:
gSavedAge(removed in Remove unused gSavedAge #21410)I might have missed a few, but that should give one a good idea what needs to be moved.
The text was updated successfully, but these errors were encountered: