0.8.5 Bugs

[Gig]

Found a bug:

Players can successfully vote for a  ridiculously  high timelimit. This ends the running game like voting a timelimt shorter than the game is running.
But after that it ends every game before it starts and thus changes map over and over and no play is possible.

AFAIK, server admins can set maximum allowed timelimit and fraglimit values (for some unknown reason, idSoftware did not allow to vote for capturelimit at all!), as well as allowing to vote for map_restart, thus making previously voted changes effective.

See also: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Servers

UPDATE: Sorry, I misread your post (my answer is partly out of context). Now I get the point. I will test it when I can.
I imagine a server admin setting g_voteMaxTimelimit, however, should be enough to prevent this from happening to his server.

[Gig]

The highest timelimit value that seems to work is 107374. If you set it to 107375 or higher, the match immediately ends.
The match immediately ends also if you enter a number between -1 and -107374. If you enter a number like -107375, the match does not end immediately. I imagine Sago may do something for this, if he wants. Of course, after 0.8.8 release.

Absurdely high fraglimit instead, does not seem to cause the match end (at least with my quick test, with noone to frag!), even if very high numbers, like 100000000, will write a different goal value on the screen; it is even possible to set the fraglimit to negative values, e.g. -1.

[grey matter]

Excuse me hijacking this thread; will you be maintaining a separate server-side-only branch for fixes like this? This'd allow server admins to apply fixes from the development version without requiring updates/downloads on the client.

[sago007]

Excuse me hijacking this thread; will you be maintaining a separate server-side-only branch for fixes like this? This'd allow server admins to apply fixes from the development version without requiring updates/downloads on the client.

Not for fixes like this that can be fixed by setting a cvar but if problems cannot be fixed that way and the problem resides serverside then it can be fixed.

[grey matter]

You'll obviously still need to announce such cvar default changes to the admins, since they won't be magically applied otherwise.

P.S.: What Virus and Gig mentioned sounds more like a bug which should be fixed, regardless of cvar settings for vote limits.

[Gig]

I suppose what Sago meant is that this particular bug does not justify to do an unscheduled release, or a specific server fix, considering that server admins can simply use a cvar to prevent the problem. In practice he said that he may make some serverside patches in case of major problems, but in this case... that's not the case. Hotfixes cause fragmentation, let's use them only if really needed. I suppose.

This does not mean that the bug will not be fixed. It will probably be fixed for the release after 0.8.8.... it will be OA 0.9.0/OA3, probably. Anyway it's better if I do not talk in the place of Sago.

How to fix this partcular bug?
1) Hard coding any "timelimit" value higher than 107374 automatically revert to 107374? Or to a "round" number, like 100000? And any value lower than 0 automatically revert to 0? This way, one may keep g_voteMaxTimelimit and g_voteMinTimelimit untouched, and change "timelimit" variable only. It would not require to change any "default" value from what quake3 had, and should work with existing configs.
2) Hard coding some g_voteMinTimelimit and g_voteMaxTimelimit limits? (What should happen in case of 0? Servers should be able to have no time limit somehow...)
3) Changing g_voteMaxTimelimit "default" value from 0 to something like 1000? The server admin may change it and allow the game to crash anyway. And it would not be applied automatically to existing configurations.

Which one do you suggest? Or a combination of them?
NOTE: Gamecode (game logic) fixes will not affect old mods, AFAIK. But I don't know if it would be possible (or advisable!) some fix at engine level (maybe changing default values? That still sounds a partial solution anyway.).

PS: We can "suggest" to use a different g_voteMaxTimelimit value in standard server configuration example DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here right now, if you wish...

[GrosBedo]

I think that this bug ought to be solved in a way or another for the next OA release, else most admins will end up with a serious problem (remember that they are not all crawling the official forums, and they are not expecting that standard variables needs to be fixed in order to avoid their servers being corrupted and unusable). To me, this is clearly an exploit.

The 3rd solution that Gig proposed seems good enough for me, changing the default value of those two cvars should fix the problem. Hard coding could be also nice to permanently fix this problem, but there are a lot of other cvars that can make the game bug if they are set to a bad value, so if one hardcode a security for this cvar, it would be more coherent to also fix those other cvars (or at least plan it in the TODO). For now, I think that just changing the default value should be enough.

I really want to stress this point, because, even if I won't be touched by this exploit, leaving it as is can lead to a lot of havoc in the servers, with automated scripts that would callvote a bad timelimit, and this would bring down a lot of servers.

[sago007]

The solution I came to based on the code:

  * Changed server logic to support all values of timelimit (calculations can no longer overflow and negative ones are ignored).
  * Changed client logic to ignore timelimit > 1000 (no 5/1 minutes remaining messages). Protecting the code against overflow would make the code much harder to read.
  * Changed default g_voteMaxTimelimit to 1000

An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000.

I normally advice against infinity time limits. The engine will boot all clients and restart itself if the game takes to long (several days) to prevent internal variables to overflow.

On the topic of updating gamecode after a release (the -23 server can use alternative gamecode) is a rather demanding operation on the server admin. But it can be quite useful especially for generating extra log.

[GrosBedo]

Thank you Sago, I think you've made great decisions, your fix is perfect.

On the topic of updating gamecode after a release (the -23 server can use alternative gamecode) is a rather demanding operation on the server admin. But it can be quite useful especially for generating extra log.

Updating can be automated if the updates are centralized, the best being a single url to access the latest head branch of the project. I will gladly make a script for that and release it publicly, and implement it on a server as I have posted here:

http://openarena.ws/board/index.php?topic=4420.0

And adding extra logging facilities is a very good idea, I will gladly participate to that if it's implemented!

[Gig]

 * Changed server logic to support all values of timelimit (calculations can no longer overflow and negative ones are ignored).
  * Changed client logic to ignore timelimit > 1000 (no 5/1 minutes remaining messages). Protecting the code against overflow would make the code much harder to read.
  * Changed default g_voteMaxTimelimit to 1000

An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000.

Excuse me, I don't understand a thing: the problem with timelimit 0 is due to g_votemaxtimelimit new behavior (like it seems reading "at the letter" the last sentence above) or about timelimit new behavior (like it seems reading all your post)? Timelimit 0 will not work in any case or only in case of voting?

I know that you do not like exceptions, but I suggest you to allow to set timelimit 0 (with the exception being allowing 0=infinite, that is >1000). Timelimit 0 always worked as "no time limit" since q3 (and will continue working in old mods, right?), thus the change would seem like "removing a feature" (even if I know that a timelimit of 1000 would be very similar to infinite).

I'm not sure I understood your sentence about clients: did you say that timelimits >1000 will continue working, but in that case warning sounds will not be played (they will be played instead with lower timelimits)?

[sago007]

Excuse me, I don't understand a thing: the problem with timelimit 0 is due to g_votemaxtimelimit new behavior (like it seems reading "at the letter" the last sentence above) or about timelimit new behavior (like it seems reading all your post)? Timelimit 0 will not work in any case or only in case of voting?

I know that you do not like exceptions, but I suggest you to allow to set timelimit 0 (with the exception being allowing 0=infinite, that is >1000).

This is not new behavior but is different default behavior. The server admin can allow people to vote for infinite time limit if g_votemaxtimelimit is set to 0 (disabled).

The original point about g_votemaxtimelimit was to stop the cases where a player would go to a server change to a ridiculous map/gametype remove frag/time limit and then hope it took a long time for an admin to discover that the server was unplayable. By forcing a max time limit the server would eventual return to normal within a given time.

I'm not sure I understood your sentence about clients: did you say that timelimits >1000 will continue working, but in that case warning sounds will not be played (they will be played instead with lower timelimits)?

The client will just not play "1 minute remaining", "5 minutes remaining" or "sudden death" if the timelimit is > 1000 and is hit. Otherwise the client would start the match by saying "sudden death" due to an overflow in the client code.

[Gig]

Thank you for answer.

I understand that timelimit knows that 0 means "infinite", but I don't understand why the voting code and g_votemaxtimelimit have to know that 0 means infinite and so is >1000 and thus not allowed. Why can't g_votemaxtimelimit (and the voting procedure itself) just manage 0 as 0 (<1000), letting timelimit decide what do to with that value later?

People will hardly understand why 0, a value correctly between g_voteMINtimelimit (0) and g_voteMAXtimelimit (1000) will not work... and working instead if g_votemaxtimelimit is changed to 0.

Ps: your note about why having g_votemaxtimelimit <> 0 is good (even if the "auto-fix" you mentioned works only in case of a map rotation script detailed enough to set gametype etc. each time), but the new default should be enough for that.
Update: Now that I think about it... if it wasn't for this avoiding-infinite-matches, the first two fixes you did may have been enough to fix the immediat-match-end bug... if now server works correctly even with timelimits like 1000000, default max vote limit hay have been keeped as 0.

Another question: about the 5min/1min/sudDeath sounds not played if timelimit >1000... 1000 is a hardcoded value or it follows g_maxvotetimelimit? I suppose the first one...

[GrosBedo]

if now server works correctly even with timelimits like 1000000, default max vote limit hay have been keeped as 0.

No, I agree with Sago about setting a value (that is anyway much too high to be attained in a normal game anyway). Noone wants an infinite game, this is generally a negligence, while having a server that works and is playable is something everyone wants, and having an infinite timelimit is proved to be a very bad practice as Sago said.

If the game still allows for timelimit 0 (to support some badly coded mods), then there's really no need to support callvote timelimit 0.

[Gig]

Okay.... but read this... I thought about it while sleeping, more or less.

What about changing default setting for g_voteMINtimelimit, too? Setting it to 1.... This way, the ability to vote for 0 or not would be left to it, instead of g_voteMAXtimelimit... and it would be much more logical/intuitive for users, IMHO.

Examples:
g_votemintimelimit 1 (new default) + g_votemaxtimelimit 1000 (new default) = not possible to vote for 0.
g_votemintimelimit 1 (new default) + g_votemaxtimelimit 200 (example, changed by admin) = not possible to vote for 0.
g_votemintimelimit 0 (changed by admin) + g_votemaxtimelimit 1000 (new default) = possible to vote for 0.
g_votemintimelimit 0 (changed by admin) + g_votemaxtimelimit 0 (changed by admin) = possible to vote for 0.

What do you think about this solution?

PS: I don't know what the engine does now if an admin erroneously sets g_voteMINtimelimit HIGHER than g_voteMAXtimelimit...

[sago007]

It does not sound more logical to me.
If I wanted to ensure limit the voteable timelimit to 15 minutes+
I would set:
g_votemintimelimit 15
g_votemaxtimelimit 0 (disabled)
And the timelimit would be limited to [15;Inf[

g_vote(min/max)fraglimit follows the same principle.

[Gig]

Well, I said that I was not sure about what the game does in case of min>max!

Anyway, this is not necessarily against what I wrote above. We can add one more case to the examples list above:

g_votemintimelimit 1 (new default) + g_votemaxtimelimit 0 (changed by admin) = possible to vote for 0.

In other words: if at least one of the two variables would be forced by the admin to 0 (while the game would provide defaults different from 0 for each variable, instead), then it would be possible to callvote for 0.
In other words: new defaults would discourage infinite matches in two different ways... and if the admin would like to allow 0 anyway, he may just change one of the two variables to 0, according to what other limit (upper/lower) he wants to keep.

Do you like it?

[Gig]

Wait, I've just made some tests with OpenArena 0.8.8 RC4 (thus, before your changes).

I've seen what the game does:
if g_votemintimelimit=0 and g_votemaxtimelimit >0, you cannot vote for 0.
if g_votemintimelimit > 0 and g_votemaxtimelimit =0, you can vote for 0.
If g_votemintimelimit>g_votemaxtimelimit, you cannot vote at all.

Maxlimit already considers 0 as infinite (and is >1, >100, >1000, etc.), while minlimit simply totally ignores 0. Setting g_votemintimelimit to 0 or to 1 seem to not make any difference at all.

Sorry Sago, it seems I missed the point previously. I started from the wrong understanding that when you said

An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000.

was due to some changes in the code (and you tried to explain to me before that is was not a new behavior, but I hadn't catched anyway). I didn't know that g_votemintimelimit 0 was the same than setting it to 1 (and that any mintimelimit value does not prevent you from setting an infinite limit).... and thought that you changed something.
Then, right... your fix is good. I just gave you a cake for that. Sorry for having made you waste some time.

The only question remaining is about the limit of 1000 over that "x minute warning" is not played by the client... is that an hardcoded limit (as I imagine) or it follows some cvar?

PS: Off topic a lot, but just a reminder for the future: I hope OA 0.9.0/OA3 will introduce capturelimit voting (unlike original Q3, now there are more gametypes that use capturelimit than those that use fraglimit -and if you switch from CTF to Domination, you really need to change the capturelimit!-) without the need of using custom votes.

[GrosBedo]

PS: Off topic a lot, but just a reminder for the future: I hope OA 0.9.0/OA3 will introduce capturelimit voting (unlike original Q3, now there are more gametypes that use capturelimit than those that use fraglimit -and if you switch from CTF to Domination, you really need to change the capturelimit!-) without the need of using custom votes.

I support this idea. Or even better: add a simple system of variable substitution in custom callvote file. This way, we could simply make a custom callvote like "seta capturelimit $1; map_restart", and we could also do a lot of other things.

[Gig]

Also that custom voting improvement sounds nice (but I don't know how to limit user's range of allowed values, in that case... maybe two more variables that work as boundary for $1? Okay for numeric variables, but for alphanumeric?). It may need some thinking... what about an apposite thread in the "idea pit" section?

But the support for capturelimit voting (possibly creating g_votemincapturelimit and g_votemaxcapturelimit cvars) should be done before it (IMHO it's more urgent), and, if possible, should be available in stock game without the need of admin tweaks and without consuming precious custom votes slots (how many are they? 8?).

[GrosBedo]

But the support for capturelimit voting (possibly creating g_votemincapturelimit and g_votemaxcapturelimit cvars) should be done before it (IMHO it's more urgent), and, if possible, should be available in stock game without the need of admin tweaks and without consuming precious custom votes slots (how many are they? 8?).

The first 12 ones are shown in the menu if I remember well (there's not yet a support for a scrollbar in this menu), but the voteconf.txt file is limited to 170 lines exactly, any more lines are not read at all. This limit should also be removed if possible.

[Virus]

saw this:
) ps37ctf being played / jumping walls is possible as normal on the server
) shuffle voting successful
) ps37ctf restarts / no one can jump on the walls now

seems only temporary for the shuffled game

[Peter Silie]

afaik ps37ctf needs some special settings on the physics. so this shouldn´t be a bug - just a config prob.

[GrosBedo]

saw this:
) ps37ctf being played / jumping walls is possible as normal on the server
) shuffle voting successful
) ps37ctf restarts / no one can jump on the walls now

seems only temporary for the shuffled game

Probably the server admin just tweaked manually the gravity and has fixed physics. See if it does the same bug when just doing a map_restart. If that's the case, this is just a normal bug, which should be fixed with g_gravityModifier in the next release.

[Gig]

Maybe it's late for 0.8. but if most admins tweak that map to give a certain gravity to it to allow to get over a wall, why do not edit the map in a next OA release to make that wall a bit lower or to change its default gravity?

[Neon_Knight]

Because it's a setting which affects every map as equal. So the solution must be provided by the server admins themselves.

BTW, that CPMA mapping guide everyone wants us to follow says that framerate dependant jumps is something to be avoided.