Map pk3 layout and information about .mapinfo

[[-z-]]

Sounds fantastic

[TVR]

Basically, the reasons why I want to get rid of mapcfg are the following two:

• it got abused, and people changed game cvars in a mapcfg, like gravity, running speed, etc. - WITHOUT CHANGING THEM BACK AT THE END OF THE MAP USING AN exit_cfg. This is a big annoyance on servers that run more than one map. I want to completely kill the "feature" of changing game parameters by a map. It's not the mapper whose decision it is how "maxplayers" or the jump height is set, but the one of the server admin.

Oh god Div0, please do not implement this! We mappers do occasionally NEED to control the CVars used on maps, for example, the Assault City will penalize any sort of height boosting by increasing the selfdamage to ~200% because an objective to reach a certain height by the use of methods other than boosting jumpheight. A far better method is would be to automatically re-execute the reset.cfg, then followed by the server.cfg, after each map change.

[divVerent]

There will be a way to do some cvar modifications in the worldspawn entity. All these changes will be guaranteed to reset after the end of the match.

Still, maps should never do that. You are the MAPPER. Not the SERVER ADMIN. For example, people may want to run a server without any self damage at all. As mapper, you only can RECOMMEND how someone should set up his server. You should not be able to ENFORCE such things.

My idea would be: such settings go in a worldspawn key on a map. The server admin can set a cvar that overrides it for each map, like

set sv_mapsettings_for_farewell "g_start_weapon_laser 0 sv_gravity 400"

so when that is set, the game will ignore whatever was set on worldspawn and instead use that.

set sv_mapsettings 0

will completely turn off reading specific map settings from worldspawn.

So there will still be a way to do such things... unless it gets abused again, which would then result in changing the default of sv_mapsettings to zero. We'll see.

[torus]

Can we have this stickied, at least when 2.4 comes out?

[TK471]

I'm doing this now for my 'angryred' map, which at the moment is DM and KH (well, I'd like to see if it's any good as a KH).

[TVR]

Switching CVar control to the worldspawn entity would only be an obstruction compared to using a text file; simply because a .mapconfig can be replaced by repacking a map, while a modifying the worldspawn would result in a recompile, and/or the use of a comparatively more sophisticated .ENT file.

With this change, if an admin does not happen to like the map settings, he can disable, and possibly override the settings [using your mapsettings CVar], while anyone can still change the suggested settings for redistribution, without requiring a recompile.

[divVerent]

Yes, I changed it a little. I made "settemp" a line in the mapinfo format, as in:

settemp ctf sv_gravity 500

Will change the text above soon..

[Spaceman]

• maps/mapname.bsp - well, as usual. You may add a version number to this. If you do it, follow the convention maps/mapname_v2r3.bsp ("version 2, release 3") or just maps/mapname_v2.bsp. Each incompatible change requires a new bsp name change, or it won't redownload. Note that this convention leads to the correct sorting order: mapname, mapname_v2, mapname_v2r1, mapname_v2r2, mapname_v3, etc. If you follow this rule, vcall and suggestmap will find the map without the version number too (by looking for the pattern specified_v*). The very first release of a map does not need a version number.
• name the pk3 just like the bsp file, possibly with a prepended "map-" (actually, this naming does not matter at all, other than the pk3 name should be different for each new release). If you release a compatible update to a map that does not require a redownload (maybe just repositioned entities), keep the bsp name mapname_v2r3.bsp, but make the pk3 mapname_v2r3a.pk3. This will also behave nicely with the sorting order.
• name the mapcfg files always dm_mapname.mapcfg, ctf_mapname.mapcfg (with the version number left out).
• the map screenshot is to be called maps/mapname.jpg (or mapname_v2r3.jpg, etc.). There won't be a file any more to specify its location! Most mappers already follow this convention anyway.
• you have to specify a key "message" in the worldspawn entity that contains the title of the map (it is where the title already belongs, just stating it again)
• you should specify a new "author" key in the worldspawn entity to enter your own name
• you should also specify a new "license" key in the worldspawn entity, although the game will ignore it

What about the mapname.cfg file? It usually only contains cd loop "4", some have other lines fog 0.2 1 1 1 0.5 1024. Could these lines be added to the mapinfo?

If the game is going to test each map for certain entities, is ctf_mapname.mapcfg still needed? If the map is suitable for CTF then it will be detected and probably written to mapinfo.

[divVerent]

mapcfg are no longer used at all, and CTF is reliably autodetected.

fog does NOT belong into the mapname.cfg file, but just happens to work there - it actually is supposed to be a key in the worldspawn entity. CD track will eventually get moved there too, I guess, which will make the mapname.cfg files obsolete. But this hasn't been done yet.

[Dokujisan]

What is the best resource for learning about settings available through mapinfo files? I've seen some people refer to some settings that I've never heard of before. I was wondering where they got those.