Gamestate set to GS_CUTSCENE during intermission and finale

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Gamestate set to GS_CUTSCENE during intermission and finale

Postby Player701 » Wed Jun 08, 2022 12:47 pm

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.
User avatar
Player701
 
 
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Gamestate set to GS_CUTSCENE during intermission and fin

Postby Graf Zahl » Wed Jun 08, 2022 1:34 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Gamestate set to GS_CUTSCENE during intermission and fin

Postby Player701 » Wed Jun 08, 2022 1:41 pm

Graf Zahl wrote: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.
User avatar
Player701
 
 
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Gamestate set to GS_CUTSCENE during intermission and fin

Postby Graf Zahl » Wed Jun 08, 2022 1:56 pm

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?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Gamestate set to GS_CUTSCENE during intermission and fin

Postby Player701 » Wed Jun 08, 2022 2:19 pm

Graf Zahl wrote: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.
User avatar
Player701
 
 
 
Joined: 13 May 2009
Location: Russia
Discord: Player701#8214
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support


Return to Bugs

Who is online

Users browsing this forum: No registered users and 0 guests