Gamestate set to GS_CUTSCENE during intermission and finale

[Player701]

It appears that GZDoom 4.8.0 sets the gamestate value to 9 (the value of constant GS_CUTSCENE, introduced in GZDoom 4.8.0) on intermission and text screens, instead of 1 (GS_INTERMISSION) on intermissions and 2 (GS_FINALE) on text screens. This is a breaking change for mods that rely on gamestate == GS_INTERMISSION or gamestate == GS_FINALE to check if the game is currently displaying an intermission or text screen.

[Graf Zahl]

Talk about things you shouldn't be checking for...
The problems with such approaches is that they prevent any kind of refactoring at all.

The thing is, the intermission handling in 4.8 is totally different than in older versions and any mod depending on the intricacies of these old screens is doomed to break.

[Player701]

Talk about things you shouldn't be checking for...

OK then, how should I be checking for intermission instead? This was mostly necessary for some menu code to make some items non-selectable (or render differently) during intermissions and finales. It's not something I can't live without, and I can also add GS_CUTSCENE to the list of values that trigger the change, but it would be nice to know if there is an "official" way now that won't require alterations to user code in the future.

[Graf Zahl]

The problem with such an approach is that you inevitably run into undefined behavior. The internal game state is not a stable set - if stuff gets refactored it may no longer show the values you expect, or new values get added that do the reverse. Yes, if you have special treatment for these screens, you absolutely *must* add GS_CUTSCENE as well, because even if those other values were added back, this one is very much the same stuff.

Out of interest, what precisely are you doing here?

[Player701]

Out of interest, what precisely are you doing here?

I have some mod options that cannot be changed normally without having to start a new game, for different reasons (mostly depending on the concrete option). Note that these are not the same as "latch" CVARs, since they lack some functionality on ZScript side, namely the ability to retrieve the pending value. However, in multiplayer, starting a new game appears to be impossible without restarting GZDoom itself, so I've introduced a special menu command that applies the changes and restarts the current level (NB: also not possible with "latch" CVARs) and also resets the inventory/health of all players. Obviously, the level can only be restarted when the game is in a level (gamestate == GS_LEVEL), so otheriwse the menu item should not be selectable. I've also disabled this feature for hub levels because restarting an arbitrary level in a hub from scratch is usually not a good idea.

The check for GS_INTERMISSION is used to determine whether to display the persistent option toggles normally (like all other options, e.g. "Some option: Yes" - when not in a game), or with additional indicators for pending values (e.g. if the current value is "Yes" and the new value is "No", it will be displayed as "Some option: Yes -> No" until the change has been applied by starting a new game). The original set of gamestate values for this condition was GS_LEVEL, GS_INTERMISSION, and GS_FINALE. Perhaps it would be better to invert the check, but then there seem to be more values to compare for.