MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001361Zandronum[All Projects] Suggestionpublic2013-06-08 15:312018-09-30 21:35
ReporterWatermelon 
Assigned ToTorr Samaho 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.1-beta 
Target Version1.3Fixed in Version1.3 
Summary0001361: Access to gamemode states
DescriptionMod developers cannot access the states of certain mods, where they do/do not want certain things to happen. For example, there are scripts that run during the countdown that should not be run and cause a mess of problems -- right now there is not any convenient or known way around it without insane hackery.


This exposes these through a new ACS function.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
parent of 0001331acknowledged  New GAMEMODE flag: COUNTDOWN 
Not all the children of this issue are yet resolved or closed.
Attached Files? IsCountdownTest.pk3 (1,518) 2013-06-08 15:32
/tracker/file_download.php?file_id=976&type=bug
Issue History
Date ModifiedUsernameFieldChange
2013-06-08 15:31WatermelonNew Issue
2013-06-08 15:31WatermelonStatusnew => assigned
2013-06-08 15:31WatermelonAssigned To => Watermelon
2013-06-08 15:31WatermelonRelationship addedrelated to 0001331
2013-06-08 15:31WatermelonRelationship deletedrelated to 0001331
2013-06-08 15:31WatermelonRelationship addedparent of 0001331
2013-06-08 15:32WatermelonFile Added: IsCountdownTest.pk3
2013-06-08 15:33WatermelonNote Added: 0006395
2013-06-08 15:34WatermelonNote Edited: 0006395bug_revision_view_page.php?bugnote_id=6395#r3508
2013-06-08 15:35WatermelonNote Edited: 0006395bug_revision_view_page.php?bugnote_id=6395#r3509
2013-06-08 15:36WatermelonNote Edited: 0006395bug_revision_view_page.php?bugnote_id=6395#r3510
2013-06-08 15:36WatermelonStatusassigned => needs review
2013-06-08 15:41WatermelonNote Edited: 0006395bug_revision_view_page.php?bugnote_id=6395#r3511
2013-06-08 15:52WatermelonNote Edited: 0006395bug_revision_view_page.php?bugnote_id=6395#r3512
2013-06-08 19:28Blzut3Note Added: 0006400
2013-06-08 19:30Blzut3Note Edited: 0006400bug_revision_view_page.php?bugnote_id=6400#r3518
2013-06-09 05:46bluewizardNote Added: 0006403
2013-06-09 13:44DuskNote Added: 0006406
2013-06-09 15:23WatermelonNote Added: 0006407
2013-06-09 15:28WatermelonNote Edited: 0006407bug_revision_view_page.php?bugnote_id=6407#r3524
2013-06-09 17:09DuskNote Added: 0006409
2013-06-10 09:20Blzut3Note Added: 0006411
2013-06-10 09:25Blzut3Note Edited: 0006411bug_revision_view_page.php?bugnote_id=6411#r3529
2013-06-11 03:31Blzut3Target Version1.1-beta =>
2013-06-16 08:47Torr SamahoNote Added: 0006447
2013-06-16 10:28Torr SamahoNote Edited: 0006447bug_revision_view_page.php?bugnote_id=6447#r3550
2013-06-18 05:17bluewizardNote Added: 0006461
2013-06-18 05:19bluewizardNote Edited: 0006461bug_revision_view_page.php?bugnote_id=6461#r3552
2013-06-18 05:21bluewizardNote Edited: 0006461bug_revision_view_page.php?bugnote_id=6461#r3553
2013-06-18 05:23bluewizardNote Edited: 0006461bug_revision_view_page.php?bugnote_id=6461#r3554
2013-06-18 05:23bluewizardNote Edited: 0006461bug_revision_view_page.php?bugnote_id=6461#r3555
2013-06-18 08:53Konar6Note Added: 0006463
2013-09-19 17:26WatermelonStatusneeds review => assigned
2013-09-20 20:14WatermelonAssigned ToWatermelon => Dusk
2014-02-11 13:23CutmanNote Added: 0008189
2014-02-15 13:55Torr SamahoNote Added: 0008211
2014-02-15 17:43DuskNote Added: 0008213
2014-03-16 11:25Torr SamahoNote Added: 0008412
2014-03-16 11:26Torr SamahoAssigned ToDusk => Torr Samaho
2014-03-16 11:26Torr SamahoStatusassigned => needs testing
2014-04-29 20:01Torr SamahoNote Added: 0008653
2014-04-29 20:05Torr SamahoTarget Version => 1.3
2014-09-05 00:15HypnotoadNote Added: 0010248
2014-09-05 00:16HypnotoadNote Deleted: 0010248
2014-10-05 22:20DuskFixed in Version => 1.3
2014-10-05 22:22DuskNote Added: 0010348
2014-10-05 22:22DuskStatusneeds testing => resolved
2014-10-05 22:22DuskResolutionopen => fixed
2018-09-30 21:35Blzut3Statusresolved => closed

Notes
(0006395)
Watermelon   
2013-06-08 15:33   
(edited on: 2013-06-08 15:52)
Tested with IsCountdownTest.pk3 (safe to use online without destroying bandwidth)
I tested all of them, all work online.
'https://bitbucket.org/Water_Melon/wbuild/commits/529e689279511737ec1df3b93d044091f0eb7265 [^]'



Added to zdefs.acs:

// Zandronum defines
//-------------------------------------------------------------------
#define GAMESTATE_POS_WAITFORPLAYERS 0
#define GAMESTATE_POS_COUNTDOWN 1
#define GAMESTATE_POS_INPROGRESS 2
#define GAMESTATE_POS_ARTIFACTHELD 3
#define GAMESTATE_POS_PRENEXTCOUNTDOWN 4
#define GAMESTATE_POS_NEXTCOUNTDOWN 5
#define GAMESTATE_POS_HOLDERSCORED 6

#define GAMESTATE_INV_WAITFORPLAYERS 7
#define GAMESTATE_INV_COUNTDOWN 8
#define GAMESTATE_INV_INPROGRESS 9
#define GAMESTATE_INV_BOSSFIGHT 10
#define GAMESTATE_INV_WAVECOMPLETE 11
#define GAMESTATE_INV_BETWEENWAVES 12
#define GAMESTATE_INV_MISSIONFAILED 13

#define GAMESTATE_DUEL_WAITFORPLAYERS 14
#define GAMESTATE_DUEL_COUNTDOWN 15
#define GAMESTATE_DUEL_INPROGRESS 16
#define GAMESTATE_DUEL_WINSEQUENCE 17

// TLMS is bundled into LMS
#define GAMESTATE_LMS_WAITFORPLAYERS 18
#define GAMESTATE_LMS_COUNTDOWN 19
#define GAMESTATE_LMS_INPROGRESS 20
#define GAMESTATE_LMS_WINSEQUENCE 21

#define GAMESTATE_SURV_WAITFORPLAYERS 22
#define GAMESTATE_SURV_COUNTDOWN 23
#define GAMESTATE_SURV_INPROGRESS 24
#define GAMESTATE_SURV_MISSIONFAILED 25






added to zspecial.acs:

-107:GetGameState(1), // [CK] Zandronum



The argument is using the constant you want to check for (boolean, 0/1 integer in reality) to see if that mode is active.
I chose to use that instead of returning flags because our user-base seems to struggle with reading bitmasks. This way it's easier for them to understand... ideally bitmasks would be the best but this works well for right now.


EDIT:
This can be expanded to encompass such things as CALLVOTE states...etc
(0006400)
Blzut3   
2013-06-08 19:28   
(edited on: 2013-06-08 19:30)
I don't really think exposing the mess that is the game mode system is the correct way to do things here. The function should just return the game state for the current game mode (GAMESTATE_WAITFORPLAYERS, GAMESTATE_COUNTDOWN, GAMESTATE_INPROGRESS, etc). Implementing as is will cause needless maintenance should the code ever get untangled.

Also, use bit masks where they make sense (although I don't really think that's the case here since the game can only be in one state). They aren't that hard to get the hang of, and it's not worth crippling interfaces because a handful of users have a little trouble. Besides, other parts of ACS are going to use them, so it doesn't make sense to be different.

Edit: While I could see going either way, it might also be feasible to extend and rename GetInvasionState. As long as the ABI is compatible of course.
(0006403)
bluewizard   
2013-06-09 05:46   
Hey if someone can implement it better, be my guest. But in the mean time, this works very well against that countdown timer bug that essentially breaks mods completely.
(0006406)
Dusk   
2013-06-09 13:44   
And when it's re-implemented your mods will break completely as the old method is removed. The gamestate stuff is a mess that should be unified first before any exposing would be considered to be honest.
(0006407)
Watermelon   
2013-06-09 15:23   
(edited on: 2013-06-09 15:28)
Do you mean bringing all the states together?

Like having one INPROGRESS for all of them?






Thoughts on having the state number exposed and letting the mod players handle the constant?

something like:

if (gamemode == lms)
    then return LMS_GetState()
(0006409)
Dusk   
2013-06-09 17:09   
Quote
Do you mean bringing all the states together? Like having one INPROGRESS for all of them?

Yeah that was on my mind.

Quote
Thoughts on having the state number exposed and letting the mod players handle the constant?

something like:

if (gamemode == lms)
    then return LMS_GetState()

That could possibly work but I'd rather resolve the mess and then expose it, that way we allow ourselves possible freer restructuring before we lock it with the ACS commands.
(0006411)
Blzut3   
2013-06-10 09:20   
(edited on: 2013-06-10 09:25)
Quote
Thoughts on having the state number exposed and letting the mod players handle the constant?

No, the constants returned should be defined and consistent for all game modes. This will currently require a translation table. Doing like Dusk suggests and trying your hand at untangling the game mode code first wouldn't be a bad idea though.

On that note, if you go way back into the repository history you could find my branch where I tried doing so. There could be something useful there, I don't recall exactly why I gave up, but it was probably due to some weird problems with the co-op modes. Basically what I had was a standardized game mode interface and then had each game mode register itself to the list at run time. This allowed new modes to be added by just adding a cpp file IIRC. The theory was it could allow modes to be added through dynamic linking if one wanted to.
(0006447)
Torr Samaho   
2013-06-16 08:47   
(edited on: 2013-06-16 10:28)
I internally started adding a layer that unifies the game mode handling. The internal function GAMEMODE_IsGameInProgress() for instance works for all game modes. We could expose this function via ACS now without risking compatibility with future changes of the game mode handling.

Quote from bluewizard
Hey if someone can implement it better, be my guest. But in the mean time, this works very well against that countdown timer bug that essentially breaks mods completely.

Can you elaborate the problem? Would GAMEMODE_IsGameInProgress() be sufficient to resolve this?

EDIT: GAMEMODE_IsGameInResultSequence() is another already existing related function. It should take only little effort to create a GetGamemodeState function. We only need to decide on the necessary states and whether the function should use a bit mask to potentially allow a gamemode to be in two states at once in the future. Regading the states I'd say we need at least GAMESTATE_WAITFORPLAYERS, GAMESTATE_COUNTDOWN, GAMESTATE_INPROGRESS and GAMESTATE_INRESULTSEQUENCE.
(0006461)
bluewizard   
2013-06-18 05:17   
(edited on: 2013-06-18 05:23)
@ Torr

Torr GAMEMODE_IsGameInProgress() would definitely be enough. As for elaboration, basically when you have open/enter clientside scripts, it gets executed twice, once due to the countdown and again when the actual round begins.

Edit: Strange I don't recall there being any indication on the changelog about GAMEMODE_IsGameInResultSequence()'s existence.
(0006463)
Konar6   
2013-06-18 08:53   
GAMEMODE_IsGameInResultSequence() is just an internal function.
(0008189)
Cutman   
2014-02-11 13:23   
We need a way to check whether a game has started or is in the countdown period. For custom game modes using global ACS it is not only a little intuitive before the game *actually* resets, it can mess up certain things such as global values and RESPAWN scripts. A simple "Is in the countdown phase" check would resolve this, and could be used for various game modes such as survival, lms etc
(0008211)
Torr Samaho   
2014-02-15 13:55   
So, let's pick up what I wrote above:
Quote from Torr Samaho
It should take only little effort to create a GetGamemodeState function. We only need to decide on the necessary states and whether the function should use a bit mask to potentially allow a gamemode to be in two states at once in the future. Regading the states I'd say we need at least GAMESTATE_WAITFORPLAYERS, GAMESTATE_COUNTDOWN, GAMESTATE_INPROGRESS and GAMESTATE_INRESULTSEQUENCE.

So, are this all states we need and do we need a bit mask for this?
(0008213)
Dusk   
2014-02-15 17:43   
The game states are mutually exclusive so there's no need for a bitmask. I think those four enumerators should be sufficient..
(0008412)
Torr Samaho   
2014-03-16 11:25   
Here is a very first testing version, completely untested so far.

Add

    -107:GetGamemodeState(0),

to your zspecial.acs to use the new function. The possible return values are

    GAMESTATE_UNSPECIFIED = -1,
    GAMESTATE_WAITFORPLAYERS = 0,
    GAMESTATE_COUNTDOWN = 1,
    GAMESTATE_INPROGRESS = 2,
    GAMESTATE_INRESULTSEQUENCE = 3.

When implementing this I noticed possibly ambiguous cases: Invasion has a countdown after each wave. This state is considered as "in progress". Possession has two extra states (PSNS_PRENEXTROUNDCOUNTDOWN and PSNS_NEXTROUNDCOUNTDOWN) that are not explicitly handled right now. I think PSNS_PRENEXTROUNDCOUNTDOWN should be considered as "in countdown" while PSNS_PRENEXTROUNDCOUNTDOWN is a short lived intermediate state that could stay as "unspecified" for now.
(0008653)
Torr Samaho   
2014-04-29 20:01   
Since there was no feedback on my test build for about 6 weeks, I went ahead, finalized the implementation without feedback and added it to 1.3. Don't blame me if it doesn't work :P.
(0010348)
Dusk   
2014-10-05 22:22   
Marking as resolved as 1.3 is now released.