Bug Tracker – Bug 112

Implement Cvar Overrides

Last modified: 2014-03-20 00:23:58 CDT
Bug 112 - (ARRAY(0x5f7b550)) Implement Cvar Overrides
(ARRAY(0x5f7b550))
Implement Cvar Overrides
Status: ASSIGNED
Product: Odamex
Classification: Unclassified
Component: Server
(old) 0.0.1
Other All
: P2 enhancement
Depends on: ARRAY(0x6288e50)
Blocks:
  Show dependency tree
 
Reported: 2006-02-14 19:33:41 CST by Chris Laverdure
Modified: 2014-03-20 00:23 CDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Laverdure 2006-02-14 19:33:41 CST
Cvar Overrides allow you to override certain cvars for certain maps, preventing
you from having to make one config criteria for your server.

I already wrote an implementation for ZDaemon, but would need to rewrite most of
it to make it snap into Odamex

For example... ( ZDaemon example, works with 1.07 and up )

add_cvaroverride map07 sv_infiniteammo true
add_cvaroverride map11 sv_respawnitems true

Whenever the server lands on map07, it'll temporarily override the
sv_infiniteammo cvar to true, and reset it to the server default when the map is
left.

add_cvaroverride map11 hostname "Classic Map11 Deathmatch"

It allows for a lot of flexibity with minimal intrusion and thus should be
implemented for Odamex 1.0. Since I wrote the original implementation I will
take charge in writing this one.
Comment 1 Denis Lukianov 2006-10-19 05:33:37 CDT
no progress, reassigning to myself
Comment 2 Denis Lukianov 2006-10-19 05:41:54 CDT
This sounds like an overcomplicated way to execute a script on a given map load. I think there's a much cleaner way to solve this problem.

Create a cvar that will contain the path of a script to be run at every map load. Lets call it "mapscript". Create a read-only cvar called "map" to indicate current map. Thanks to bug 48, we already have an "if" command. So now the script pointed to by mapscript can simply change settings or run commands depending on the current map.
Comment 3 Denis Lukianov 2006-10-19 07:21:49 CDT
Problems with comment 2:

1) map is a command, so call the cvar curmap (solved)
2) what happens when a mapscript decides to change map, recursively?
Comment 4 Denis Lukianov 2006-10-19 07:24:37 CDT
ok, so somehow restrict mapscript to only allow cvar changes (disallow commands until the script completes)
Comment 5 Denis Lukianov 2006-10-19 07:55:32 CDT
alternatively, this could replace the difficult-to-manipulate mapcycles:

if map eq map01 if playcount eq 2 map map02
if map eq map02 if playcount eq 3 map map03
if map eq map03 if playcount eq 1 map map01

would play map01 twice, map02 three times, map02 twice... make sense?
Comment 6 Denis Lukianov 2006-10-19 07:57:16 CDT
err, map03 would be played once (not map2 three times than twice), you get the point...
Comment 7 Denis Lukianov 2006-10-19 07:59:39 CDT
maybe:

if curmap eq map01 if playcount eq 2 nextmap map02
if curmap eq map02 if playcount eq 3 nextmap map03
if curmap eq map03 if playcount eq 1 nextmap map01
Comment 8 Mike Lightner 2006-10-19 08:58:08 CDT
As a general question, specifcally regarding the checking of player count, does the script wait until all previous players are in before it executes?  It could be checking player count before all have joined and change the map again, etc.  This is probably better for a bug 18 comment but since it was mentioned here I'll comment here.
Comment 9 Denis Lukianov 2006-10-19 09:18:52 CDT
(In reply to comment #8)
> As a general question, specifcally regarding the checking of player count, does
> the script wait until all previous players are in before it executes?  It could
> be checking player count before all have joined and change the map again, etc. 
> This is probably better for a bug 18 comment but since it was mentioned here
> I'll comment here.

By playcount, I meant to indicate the number of times that particular map has been consecutively played, not number of players.

Regarding number of players, the point is moot for two reasons:
A) players do not disconnect during map changes, therefore the count won't change
B) there is no cvar tracking current number of players (maybe there should be.. ?)

Comment 10 Denis Lukianov 2006-10-19 09:19:37 CDT
The following cvar functionality incorporated into r1820:

endmapscript - specifies commands to run after a map ends (natural progression only), can be set to exec a script file.

startmapscript - specifies commands to run after a new map is loaded (both natural and forced progression), can be set to exec a script file.

curmap - can be used by commands in endmapscript to work out what to do next (e.g. what next map to specify, though that is not yet implemented).

nextmap - can be used by commands in startmapscript to work out what cvars to override.
Comment 11 Denis Lukianov 2006-10-19 09:21:48 CDT
endmapscript/startmapscript will have to be able to run a limited subset of commands such as "if", methinks... currently they only set cvars directly
Comment 12 Mike Lightner 2006-10-19 09:28:44 CDT
(In reply to comment #9)
> By playcount, I meant to indicate the number of times that particular map has
> been consecutively played, not number of players.
> 
> Regarding number of players, the point is moot for two reasons:
> A) players do not disconnect during map changes, therefore the count won't
> change
> B) there is no cvar tracking current number of players (maybe there should be..
> ?)
> 
Yes to point B.  
Comment 13 Denis Lukianov 2006-10-19 09:39:33 CDT
regarding point B, clientcount introduced in r1822
Comment 14 Denis Lukianov 2006-10-19 09:41:30 CDT
As of r1823, odamex can deal with a startmapscript like this:

hostname "Some map"
if nextmap eq MAP05 hostname "Map five"
if nextmap eq MAP01 hostname "Map one"

You'd need to get the server to run it, naturally:
startmapscript "exec myscript"


Comment 15 Denis Lukianov 2006-10-19 09:44:24 CDT
but you should use curmap, naturally, because you want to override stuff for current map :) my bad in comment 14
Comment 16 Denis Lukianov 2006-10-19 09:58:24 CDT
r1825, only issue remaining is whether/how endmapscript should choose the next map