Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Attached Files? file icon IsCountdownTest.pk3 [^] (1,518 bytes) 2013-06-08 15:32

- Relationships
parent of 0001331acknowledged New GAMEMODE flag: COUNTDOWN 
Not all the children of this issue are yet resolved or closed.

-  Notes
User avatar (0006395)
Watermelon (developer)
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

User avatar (0006400)
Blzut3 (administrator)
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.

User avatar (0006403)
bluewizard (reporter)
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.
User avatar (0006406)
Dusk (developer)
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.
User avatar (0006407)
Watermelon (developer)
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()


User avatar (0006409)
Dusk (developer)
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.
User avatar (0006411)
Blzut3 (administrator)
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.

User avatar (0006447)
Torr Samaho (administrator)
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.

User avatar (0006461)
bluewizard (reporter)
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.

User avatar (0006463)
Konar6 (reporter)
2013-06-18 08:53

GAMEMODE_IsGameInResultSequence() is just an internal function.
User avatar (0008189)
Cutman (reporter)
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
User avatar (0008211)
Torr Samaho (administrator)
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?
User avatar (0008213)
Dusk (developer)
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..
User avatar (0008412)
Torr Samaho (administrator)
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.
User avatar (0008653)
Torr Samaho (administrator)
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.
User avatar (0010348)
Dusk (developer)
2014-10-05 22:22

Marking as resolved as 1.3 is now released.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: Hypnotoad ZzZombo
Opponents: Dusk

- Issue History
Date Modified Username Field Change
2013-06-08 15:31 Watermelon New Issue
2013-06-08 15:31 Watermelon Status new => assigned
2013-06-08 15:31 Watermelon Assigned To => Watermelon
2013-06-08 15:31 Watermelon Relationship added related to 0001331
2013-06-08 15:31 Watermelon Relationship deleted related to 0001331
2013-06-08 15:31 Watermelon Relationship added parent of 0001331
2013-06-08 15:32 Watermelon File Added: IsCountdownTest.pk3
2013-06-08 15:33 Watermelon Note Added: 0006395
2013-06-08 15:34 Watermelon Note Edited: 0006395 View Revisions
2013-06-08 15:35 Watermelon Note Edited: 0006395 View Revisions
2013-06-08 15:36 Watermelon Note Edited: 0006395 View Revisions
2013-06-08 15:36 Watermelon Status assigned => needs review
2013-06-08 15:41 Watermelon Note Edited: 0006395 View Revisions
2013-06-08 15:52 Watermelon Note Edited: 0006395 View Revisions
2013-06-08 19:28 Blzut3 Note Added: 0006400
2013-06-08 19:30 Blzut3 Note Edited: 0006400 View Revisions
2013-06-09 05:46 bluewizard Note Added: 0006403
2013-06-09 13:44 Dusk Note Added: 0006406
2013-06-09 15:23 Watermelon Note Added: 0006407
2013-06-09 15:28 Watermelon Note Edited: 0006407 View Revisions
2013-06-09 17:09 Dusk Note Added: 0006409
2013-06-10 09:20 Blzut3 Note Added: 0006411
2013-06-10 09:25 Blzut3 Note Edited: 0006411 View Revisions
2013-06-11 03:31 Blzut3 Target Version 1.1-beta =>
2013-06-16 08:47 Torr Samaho Note Added: 0006447
2013-06-16 10:28 Torr Samaho Note Edited: 0006447 View Revisions
2013-06-18 05:17 bluewizard Note Added: 0006461
2013-06-18 05:19 bluewizard Note Edited: 0006461 View Revisions
2013-06-18 05:21 bluewizard Note Edited: 0006461 View Revisions
2013-06-18 05:23 bluewizard Note Edited: 0006461 View Revisions
2013-06-18 05:23 bluewizard Note Edited: 0006461 View Revisions
2013-06-18 08:53 Konar6 Note Added: 0006463
2013-09-19 17:26 Watermelon Status needs review => assigned
2013-09-20 20:14 Watermelon Assigned To Watermelon => Dusk
2014-02-11 13:23 Cutman Note Added: 0008189
2014-02-15 13:55 Torr Samaho Note Added: 0008211
2014-02-15 17:43 Dusk Note Added: 0008213
2014-03-16 11:25 Torr Samaho Note Added: 0008412
2014-03-16 11:26 Torr Samaho Assigned To Dusk => Torr Samaho
2014-03-16 11:26 Torr Samaho Status assigned => needs testing
2014-04-29 20:01 Torr Samaho Note Added: 0008653
2014-04-29 20:05 Torr Samaho Target Version => 1.3
2014-09-05 00:15 Hypnotoad Note Added: 0010248
2014-09-05 00:16 Hypnotoad Note Deleted: 0010248
2014-10-05 22:20 Dusk Fixed in Version => 1.3
2014-10-05 22:22 Dusk Note Added: 0010348
2014-10-05 22:22 Dusk Status needs testing => resolved
2014-10-05 22:22 Dusk Resolution open => fixed
2018-09-30 21:35 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker