Anonymous | Login | Signup for a new account | 2024-03-29 06:37 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001361 | Zandronum | [All Projects] Suggestion | public | 2013-06-08 15:31 | 2018-09-30 21:35 | ||||
Reporter | Watermelon | ||||||||
Assigned To | Torr Samaho | ||||||||
Priority | normal | Severity | feature | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 1.1-beta | ||||||||
Target Version | 1.3 | Fixed in Version | 1.3 | ||||||
Summary | 0001361: Access to gamemode states | ||||||||
Description | Mod 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 | IsCountdownTest.pk3 [^] (1,518 bytes) 2013-06-08 15:32 | ||||||||
Relationships | |||||||||||
|
Notes | |
(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 |
(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. |
(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. |
(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. |
(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:
|
(0006409) Dusk (developer) 2013-06-09 17:09 |
Quote Yeah that was on my mind. Quote 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 (administrator) 2013-06-10 09:20 edited on: 2013-06-10 09:25 |
Quote 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 (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 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 (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. |
(0006463) Konar6 (reporter) 2013-06-18 08:53 |
GAMEMODE_IsGameInResultSequence() is just an internal function. |
(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 |
(0008211) Torr Samaho (administrator) 2014-02-15 13:55 |
So, let's pick up what I wrote above:Quote from Torr Samaho So, are this all states we need and do we need a bit mask for this? |
(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.. |
(0008412) Torr Samaho (administrator) 2014-03-16 11:25 |
Here is a very first testing version, completely untested so far. Add
to your zspecial.acs to use the new function. The possible return values are
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 (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. |
(0010348) Dusk (developer) 2014-10-05 22:22 |
Marking as resolved as 1.3 is now released. |
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 |
Copyright © 2000 - 2024 MantisBT Team |