Bug #296

Strange behaviour of cg_spawnTimer_period & cg_spawnTimer_set

Added by Harlekin about 6 years ago. Updated almost 6 years ago.

Status:Fixed% Done:

100%

Priority:NormalSpent time:-
Assignee:Spyhawk
Category:Mod CGAME
Target version:2.71rc2
OS: Arch:

Description

i have set cg_spawnTimer_period "20" & cg_spawnTimer_set = "0" (also tried 1,2,3,4 all the same).
This results in having a red counter counting from 39 down to 20. Imho it should be counting from 20 to 0.

See screenshots.

spawn-timer.jpg - Spawn timer (11.7 KB) Harlekin, 28.04.2013 15:02

173

Associated revisions

Revision 49895cd1
Added by IR4T4 about 6 years ago

cgame: spawn timer adjustments refs #296

Revision 753d6edd
Added by Jacker almost 6 years ago

cgame: reset the spawn timer when the game is not on, refs #296

History

#1 Updated by Spyhawk about 6 years ago

Confirmed. No idea why this doesn’t work the same way as etpub. This is totally buggy. Timer can be easily corrected, but it seems that there is no way to "reset" the timer (set the counter to any point of time).

The actual code also uses 2 cvars, there should be a way to use only one:

cg_spawnTimer 0 → disabled
cg_spawnTimer int → set spwantimer to an 'int’ period, and reset the counter at the same time.

#2 Updated by Spyhawk about 6 years ago

This is actually working, but you have to use the "resetTimer" command to reset it, and stop the weird counting.
Might be a way to clean this up. I also don’t really understand why the current code need 2 cvar (+ an additional client command) for this.

Note that this weird behavior is similar on etpub/2.60b. Might interest pheno.

#3 Updated by Spyhawk about 6 years ago

  • Category set to Mod CGAME
  • Target version set to 2.71rc2

#4 Updated by IR4T4 about 6 years ago

Use the /timerSet and /resetTimer commands to control the spawn timer. This isn’t a bug - you just can’t set the CVAR values to make the timer work manually. See CG_TimerSet_f and CG_ResetTimer_f. In other words: these CVARs are just data holder for the command functionality.

#5 Updated by Spyhawk about 6 years ago

IR4T4 wrote:

Use the /timerSet and /resetTimer commands to control the spawn timer. This isn’t a bug - you just can’t set the CVAR values to make the timer work manually. See CG_TimerSet_f and CG_ResetTimer_f. In other words: these CVARs are just data holder for the command functionality.

Right, I was about to write when you updated the issue:

The user isn’t supposed to modify the cvars manually, but to use the commands:
- TimerSet XX, that set the period and the initial point
- ResetTimer, that set the initial point to a new one.

Would it make sense to remove one of the command and use only TimerSet?
- TimerSet 20 = set initial period point, and set period
- TimerSet 0 = disable
- TimerSet <no int> = reset initial period point, keep same period (if defined)

I also think I’ve found the issue with the weird counting. The timer should also made invisible in spec mode, and in warmup time (both occur when you play with the 2 cvars that you aren’t supposed to change manually).

#6 Updated by Saukko about 6 years ago

Yeah I always found it annoying that you couldn’t disable it or it doesn’t disable itself after a new map or so. Its functionality would be nice to be fixed.

-*S

#7 Updated by IR4T4 about 6 years ago

  • % Done changed from 0 to 90

Spyhawk wrote:

Would it make sense to remove one of the command and use only TimerSet?
- TimerSet <no int> = reset initial period point, keep same period (if defined)

I’m not sure if we should change this. The way it works now is just known by many ETPro players.

I also think I’ve found the issue with the weird counting. The timer should also made invisible in spec mode, and in warmup time (both occur when you play with the 2 cvars that you aren’t supposed to change manually).

It’s disabled in warmup and I didn’t disable it for spectators so the result is immediatley shown when you set the timer in spec mode before you are joining a team. Some specs may also be interested in spawn times while watching a game.

To disable the spawn timer just enter /timerset (no argument) or /timerset 0 (new).

#8 Updated by Spyhawk about 6 years ago

The weird counting bug still occurs if the timerset command has been used in the previous map.

This can be prevented by using this simple patch:

// spawntimer
seconds = msec / 1000;

if (cgs.gamestate != GS_PLAYING && cg_spawnTimer_set.integer != -1 && cg_spawnTimer_set.integer < seconds) {
trap_Cvar_Set("cg_spawnTimer_set", va("%d", seconds));
}
...

On a 30min map, cg_spawnTimer_set gets reinitialized to 1799 seconds (no idea where the missing second goes to), so adding an extra second might be useful here.

IR4T4 wrote:

Spyhawk wrote:

Would it make sense to remove one of the command and use only TimerSet?
- TimerSet <no int> = reset initial period point, keep same period (if defined)

I’m not sure if we should change this. The way it works now is just known by many ETPro players.

Maybe it is a good opportunity to do some cleanup. I mean, the resetTimer and timerSet command names aren’t even consistent... Looking at the existing commands, "spawntimer" would be a more straightforward name choice.

It’s disabled in warmup and I didn’t disable it for spectators so the result is immediatley shown when you set the timer in spec mode before you are joining a team. Some specs may also be interested in spawn times while watching a game.

Not sure if that is a good idea. Afaik, the whole idea behind the timer is that it could be set manually (by looking at the enemy spawn while playing), but a spectator could 'cheat’ by setting the spawntimer before joining his team. I’m even wondering if it wouldn’t be better to totally disable the timer (reset cg_spawnTimer_set and period) while a player goes spec, or, at least, reinitialize cg_spawnTimer_set.

#9 Updated by Harlekin about 6 years ago

If someone uses spectator to get enemy spawn time he might be able to keep it in mind and set timer after joining his team. It does not matter if the timerset works as spec or not.

#10 Updated by Spyhawk about 6 years ago

Harlekin wrote:

If someone uses spectator to get enemy spawn time he might be able to keep it in mind and set timer after joining his team. It does not matter if the timerset works as spec or not.

Sure, but this is still harder to get it right. And beside this, I don’t see the need to have the timer in spec mode, as there is only one timer for two teams. Imho, this is also purely a 'team’ feature and shouldn’t be visible otherwise.

#11 Updated by IR4T4 about 6 years ago

  • Status changed from New to Fixed
  • % Done changed from 90 to 100

I don’t see a good reason to change the current code for above reasons. Spectators should see the timer because they can set it. It’s just the same as a clock next to your monitor.

Spyhawk, force the client cvars if you don’t like it

#12 Updated by Spyhawk about 6 years ago

IR4T4 wrote:

Spyhawk, force the client cvars if you don’t like it

Thanks for your answer, although I still believe having a single timer for spec doesn’t make sense
The above patch is still useful as it fixes an existing issue.

#13 Updated by IR4T4 about 6 years ago

Spyhawk wrote:

The above patch is still useful as it fixes an existing issue.

I can’t reproduce this 'reinitialized to 1799 seconds’ bug.

#14 Updated by Spyhawk about 6 years ago

Na, the reinitialized to 1799 is the fix.

Steps to reproduce:
- launch a map
- midgame, use /timerset 20. cg_spawntimer_set is set to some value (ie, 900 if used at 15min before end of map)
- finish map
- start next map. cg_spawntimer_set is set to a lower value than current time. Same issue as described by Harle above. It goes back to normal when you reach the time you initially set the timer at the previous level (ie, buggy from 1800 to 900 second, then normal from 900 to 0).

The fix above simply ensure that cg_spawtimer is set to the map timelimit during warmup, so the value (diff between cg_spawntimer_set and current time) is never negative. It shouldn’t have any drawback since you can’t use /timerset or /resettimer in warmup.

The following fix work on my machine (except that I changed the disabled value from -1 to zero, as the timer is useless when the map is finished).

By the way, it would be great to have at least coherent commands. /settimer drives me crazy

#15 Updated by Spyhawk about 6 years ago

  • % Done changed from 100 to 90

Could anyone else reproduce this issue with the steps described above?

#16 Updated by Radegast about 6 years ago

  • Status changed from Fixed to Feedback
  • Assignee set to Spyhawk

#17 Updated by IR4T4 about 6 years ago

cg_spawntimer_set value is out of interest on the next map: new map → different spawn time interval and different point of time → player has to use timerset cmd again.

#18 Updated by Spyhawk about 6 years ago

IR4T4 wrote:

cg_spawntimer_set value is out of interest on the next map: new map → different spawn time interval and different point of time → player has to use timerset cmd again.

Absolutely. But the above patch avoid that ugly buggy display. Really, is there any reason not to modify the code?

#19 Updated by Spyhawk almost 6 years ago

Here a simpler (and probably cleaner) way to deal with it:

  • It is no possible to use the timer commands in warmup, and those can be used only when the match has started.
  • Showing the timer by default when the values have been already set in the previous map makes the timer buggy.
  • To solve this issue, simply turns off the timer in warmup. It doesn’t make sense to show the timer with those previous values anyway.

Would the above make sense?

#20 Updated by Jacker almost 6 years ago

Modified it so that the timer will get reset & hidden when the game is not in "playing" state anymore.

Can this be closed now?

#21 Updated by Spyhawk almost 6 years ago

  • Status changed from Feedback to Fixed
  • % Done changed from 90 to 100

Thanks Jacker, the change looks good. I’m closing this issue, as the bug is fixed. I might open a new issue later for cleaning up those inconsistent timerset/resettimer commands, if there is an interest in doing so(?).

Also available in: Atom PDF