Implement Cvar Overrides
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
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.
no progress, reassigning to myself
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.
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?
ok, so somehow restrict mapscript to only allow cvar changes (disallow commands until the script completes)
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?
err, map03 would be played once (not map2 three times than twice), you get the point...
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
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.
(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.. ?)
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.
endmapscript/startmapscript will have to be able to run a limited subset of commands such as "if", methinks... currently they only set cvars directly
(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
> B) there is no cvar tracking current number of players (maybe there should be..
Yes to point B.
regarding point B, clientcount introduced in r1822
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"
but you should use curmap, naturally, because you want to override stuff for current map :) my bad in comment 14
r1825, only issue remaining is whether/how endmapscript should choose the next map