To already prepare your maps for that menu system, please follow the following map pk3 layout:
- 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
By following these conventions, it will be easiest for your maps to work with the new menu system and after the death of the mapcfg system. The menu will then autogenerate the required .mapinfo file from the data you specified, and you shouldn't need to fine tune it any more.
The possible game modes, BTW, will be autodetected by the types of entities you place - for example, item_flag_team2 causes the map to get CTF support, dom_controlpoint causes the map to get DOM support, LMS, DM will be always active, Arena if the map is below a certain size, TDM and KH if it is above a certain size and #spawnpoints, etc. You'll then be able to fine tune this in the .mapinfo file, though, as well as the default time/fraglimit for these modes.
No idea when this new system will come out, but if you in the future follow these simple rules (which also make sense with the current system), the transition will be smooth.
In the unlikely event that you will reach _v9r9... no idea, you may be screwed then
Maybe _vv10r1, ..., _vv10r9, _vv10rr10, _vv10rr11, ... is how the sequence could go on (also works with the sorting order).
As you see, the primary goal is to make maps work even without a mapcfg file at all - everything the game really needs will be autodetected. However, parsing a BSP file takes about two seconds, so mapinfo will cache it and also allow modification of the dumb guesses the code will do (like possible game modes).
Example worldspawn entity:
- Code: Select all
{
"classname" "worldspawn"
"message" "Foo! Just a stupid example map."
"author" "/dev/urandom"
"license" "GPL"
Note: took out "playercount" as mappers never get this right anyway
maybe I will make some visible indication of map size - but it won't be fixed player count values.
