Open GoogleCodeExporter opened 8 years ago
Because of config execution order complexity, the conclusion is to NOT use
configs in game rules.
The game rule itself must be compatible with map configs (this means it cannot
be loaded before OnConfigsExecuted). And executing configs after that event is
not acceptible because then the OnConfigsExecuted event won't mean that all
configs are executed.
As a workaround, the user may create custom config files for game rules and add
a exec commmand in map configs that use that game rule.
The main problem is that we're depending on a config, and at the same time
trying to execute another one before the one we're depending on. So far I don't
know any other solutions to this paradox other than letting users make a config
and execute it themself.
Original comment by richard.helgeby@gmail.com
on 16 Sep 2010 at 10:07
Another workaround for configs
Make a console command for setting or changing the game mode (zr_set_gamemode
<mode name>). When that command is executed, it will both update the game mode
cvar and automatically execute <game mode name>.cfg too.
Then there's only one line needed in map configs. It has to be first otherwise
it will override other stuff in the map config file.
Unless there are buffering or delay issues with the "exec" command, this might
work. Because then all configs will be executed before OnConfigsExecuted,
including game mode specific configs.
Original comment by richard.helgeby@gmail.com
on 16 Sep 2010 at 10:52
Conclusions and solutions so far:
* Game rules config is loaded in OnMapStart so modules can be disabled early.
The gamerules module will get priority on this event so modules that should be
disabled will never get this event.
* Globally default game mode is either the first game mode in the file, or the
first game mode with "default" attribute set to "yes" (we haven't decided this
yet).
* Since it's too late for map configs to change game mode, gamerules will need
it's own map config. Currently the idea is to have a single file with maps
listed like this: "<map>:<game mode>". This list is optional, but maps that
should have a different game mode from default must be listed. Eventually it
could support prefixes and wildcards so a group of map can be assigned to a
game mode in one line.
* Admins may override the next game mode by setting it with a console command
(or maybe even from a nice in-game menu). Map must be changed/reloaded for this
to take effect.
* Modules that load non-cvar configs (files) now load them in OnMapStart.
Modules that depend on cvars will still work with existing map configs.
Config execution order:
<gamerules config>
<gamerules map config> - to override game mode on maps
<module file configs> - weapons.txt, classes.txt, etc.
zombiereloaded.cfg
<game mode>.cfg
<map>.cfg
<map>.post.cfg (if we need this)
Original comment by richard.helgeby@gmail.com
on 29 Jun 2011 at 2:51
What about log configuration or other settings that should be loaded before
modules load configs?
Changing log settings (like enabling debug logs) is too late in
zombiereloaded.cfg. Those must be set much earlier (even before gamerules
config is loaded).
We might need a pre-config for this stuff, but I don't know if it's safe to use
cvars this early. Another keyvalue config for such settings would fix it, but
is this a good solution?
Most stuff wouldn't need settings to be loaded this early, but logging is an
exception. Maybe log settings could be in its own file (keyvalues)?
Original comment by richard.helgeby@gmail.com
on 29 Jun 2011 at 2:56
It seems like <game mode>.cfg is executed before zombiereloaded.cfg, while it
should be after. How can this be fixed/delayed?
A dirty workaround is to add a console command in gamerules that will execute
the current game mode's config, and use that command at the end of
zombiereloaded.cfg.
Original comment by richard.helgeby@gmail.com
on 5 Jul 2011 at 7:06
Original issue reported on code.google.com by
richard.helgeby@gmail.com
on 10 Aug 2010 at 11:11