Per-map and per-gametype automatic .cfg execution system

[deathsythe47]

We discussed this before (actually, you proposed this idea sil), but it would be great to have auto-executed .cfg files for certain maps and gametypes.

Could be done like /mapcfgs/ and /gametypecfgs/ so if you load mp/siege_hoth.bsp it automatically would load /mapcfgs/mp/siege_hoth.cfg if it exists. Or if you switch to CTF it automatically would load /gametypecfgs/ctf.cfg

Example usage: enable g_floating_items for korriban only

This would help with server administration, but it would also allow mapmakers more possibilities by making maps geared toward specific server settings.

[TheSil]

I just thought about it more, it will be a bit tricky. For example if you load the korriban .cfg only for korriban, you expect that after changing to another map, that it will also revert the changes back (disabling the floating items stuff), so you would need additional config file for the map or something like that. This will need to be thought through more.

[deathsythe47]

Say if you change from korri to hoth, then it loads hoth.cfg. But if there does not exist a hoth.cfg, then it could load /mapcfgs/siege_generic.cfg which would be a generic cfg for any siege map that does not have its own mapcfg.

Could optionally toggle this with g_loadGenericMapcfg or something I guess.

This is different from the gametypecfg, which only runs once -- when the gametype is changed.

[entdark]

Too complicated path. Just put directly into root with mapname.cfg. For mp/ffa2 map it will be just /ffa2.cfg. mapname is parsed out on server-side fine.

[TheSil]

The point is that if for ffa2 you need to set some cvar, but that cvar should not be set for other maps then ffa2. You either need to create .cfg for all other maps and disable it in it, or you need to create something like ffa2_load.cfg/ffa2_unload.cfg, or to have something generic.

Maybe solution would be to just execute gametype cfg always, + each map's cfg. You could then add the generic stuff into the gametype cfg (e.g. disabled floating items). Only problem with this approach is that you shouldnt put map changing into the same config.

Actually that would be general problem, if these cfgs would contain map changing, you can get into infinite loop, lets say mp/ffa2.cfg contains

map mp/ffa2

Then by changing map to mp/ffa2 you will stuck server in infinite loop :).

[deathsythe47]

Yeah just execute generic + map specific stuff.

You wouldn't put a /map command into the mapcfg. All the mapcfg is is a cfg that is automatically executed whenever server changes maps.

Important: should make sure that anything that "will be changed on restart" should work on map change.

[deathsythe47]

Also maybe check for conflicts and only execute the command written in mapname.cfg

For example if gametypecfg says seta g_something 0 and mapcfg says seta g_something 1, it should only execute 1

[TheSil]

Technically nothing would prevent you to do so, but then it is kind of admin stupidity. Also how about having "/map" in gametype config? That might be useful but it is in conflict with idea of running generic then map specific config (since already during generic config you would change the map again).

About the conflicts, that should not be necessary, gametype would be executed before map specific.

[deathsythe47]

Have /map in gametypecfg, but ignore it if you are already in that game type.

[TheSil]

What do you mean by ignore it, you mean the whole cfg? You cant ignore individual commands (those are executed by engine).

[deathsythe47]

Oh then don't have /map in gametype config

Or have a cvar to specify a map for new gametype.

[deathsythe47]

Implemented this in https://github.com/deathsythe47/base_entranced/commit/26720560b4bd429a05d4ffbe8f53e855bb6cc6e0, however, I wrote it in g_saga.c so that it wouldn't conflict with some other siege things I already have.

You could implement something similar; just don't do it in g_saga.c, obviously.

You just need to put this before the code:

vmCvar_t        mapname;
trap_Cvar_Register( &mapname, "mapname", "", CVAR_SERVERINFO | CVAR_ROM );