Map pk3 layout and information about .mapinfo

[divVerent]

As I am currently making a new menu system, I will change the way the game finds maps and gets information about them. That means: no more mapcfg. Instead, the game will make ".mapinfo" files (of a layout that is yet to specified) that the mappers are supposed to edit. Most of its data (like possible game modes) will be autodetected from the .bsp file (which takes some seconds on the first run). In the future, mappers will be supposed to load up the menu once to make mapinfo files for their maps.

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:

{
"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.

Woah Woah Woah Woah Woah.
_ANOTHER_ change in the map layout process.
We allready had a change a year ago. Now ANOTHER one.
You really don't have a big enough community to keep making these changes and expect not to lose mappers.
What do we with all the existing nexuiz maps. Do we have to redo them because they don't have the keys and your new menu system doesn't recognize the mapcfgs

Why are you doing all this busy work and forcing it upon the community. Will this new thing real mapcfgs too for backward compatability or are you throwing that out too for your amusement. What about custom server map cfgs? Those exist. Man you're going backwards if you get rid of mapcfg totally.

We don't really like the fischer price menu system. You don't care and plug forward with this change anyway.

Don't you know how LONG it takes to recompile a map vs how easy it is to change a mapcfg. I guess not. Yea screw the little guy that doesn't have m3g4 rig.

Thanks DiV, you're a real great fellow.
Keep driving both players (unattractive menu) and developers (less flexible, not backwards compatable packaging system, frequent changes in it) away.

What about setting timelimits and all that. Diffrent timelimits are good for diffrent maps.
What about having large arena maps, what if some servers want that?

Nope, it's all going to be forced upon us by DiV, no backwards compatability because he needs to force us to comply.

Maybe he just want's to get rid of old maps for some reason. This is almost like a propritary game where Div decideds all.

I could attack you with arguments Mikee but you would just start screaming at me again how muslims are going to kill me so I don't think I will bother.

[tZork]

Nice! Not having to maintain seventyelevel .mapcfg's & txt's for each map if a very good thing, specialy for sloppy typers like me.. xD Good work divVerent.

Yes, obviously a system that cuts down on extraneous, slightly awkward file conventions is going to kill the community. Obviously!

Can't entities be changed within the map without recompiling, anyways?

[divVerent]

Just to make one point clear:

Any old map will RUN after the change, it just won't show author and title right in the menu (in case of title, maps where this stops working already WERE made wrong). So compatibility does not get broken. I'll even supply pre-made cache files for all maps I have so it doesn't take you guys longer to start up Nexuiz for the first time.

And if you complain about the menu graphics - these are the easiest thing to change in the end. I currently am moving graphics that Morphed made for me. So don't insult me, insult him or just make a better menu skin.

Different timelimits and fraglimits will of course still be possible, they just need to be rewritten by hand by editing the mapinfo file.

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.
• naming of the mapcfg files often had no relation to the BSP name or to the pk3 name, so it's hard to guess how to load a map.

[divVerent]

Yes, obviously a system that cuts down on extraneous, slightly awkward file conventions is going to kill the community. Obviously!

Can't entities be changed within the map without recompiling, anyways?

Yes (q3map2 -onlyents), but as I said - you do not NEED to for the new system. All that "breaks" when not following the conventions is that the map title isn't shown, and that the recommended player count is taken from the map as a wild guess, instead from the mapper. But it can be easily changed by hand. Fixing what goes wrong takes less time than writing a single mapcfg and txt file.

I still promise that ANY old map will RUN with this without any changes. But following the conventions I presented will ensure least extra work to make the map show up nicely - with picture, recommended player count, etc.

[divVerent]

Oh, and speaking of custom mapcfgs on servers - I'll think of a way to keeping these features. Maybe cvars that specify special settings for each map. That way, only server admins can specify them, but mappers can't abuse it.

[[-z-]]

Sounds pretty convenient to me... not sure what all the fuss in the beginning was about .

Without straying too far off topic... perhaps a new system for browsing maps is in order? maybe a way to list all maps and then check off which game types you want to filter by... Something about the current UI just doesn't keep me.

[divVerent]

Of course, I am completely redesigning the create-game dialog too. It will be a scrollable list of maps with screenshots, that can be doubleclicked to add/remove from g_maplist. I don't think I'll make g_maplist orderable, it needlessly makes the UI more complex. Use the voting to achieve a "predefined" order of maps, or a dedicated server.

[[-z-]]

Sounds fantastic

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.

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

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).

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..

• 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.

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.

[[-z-]]

Have you checked out 'Docs/mapping.txt'?

Ahh...

http://svn.icculus.org/nexuiz/trunk/Doc ... ortby=date

ok, so I see under the Advanced mapinfo section that you can do something like

  Code:

settemp_for_type ctf g_balance_laser_primary_force 200


Is there a limit on which cvars can be set through that? I assume it's only server-based settings, but other than that? In the meantime, I'll do some of my own testing to figure it out.

[divVerent]

currently any cvar, but only on server side

Some of the maps in the Multiplayer / Create menu don't display an image, yet when you open the maps PK3 you will usually find a suitable jpeg or tga inside it somewhere. Usually this image has the wrong name or is in an odd location. Could this location be added to the mapinfo?

  Code:

map_image = /map/foo/bar.jpeg

The following are the maps that I have without an image

arboriabeta2
aurora
brokenworld_r2_s3over2
ctctf6
darkzone_nanlbeta2
darkzoneNANLtest1
dm_docs_deep_drill
docs_deep_drill_insta
facing_worlds_nex
Figure8
gasolinepowered_v1r1
hightide
mmkitch
obscure
test16
thedojo
thedojo_v1r2
thedojo_v1r6
thedojo_v1r7
turret-0-rama

[esteel]

It worked similar like this in the old map system, but i think its better to not do things too complicated and as its only a few maps, those pk3 files should be fixed by renaming the images..Also even with the change you propose it would be necessary to change the pk3 files.

nice one divv, I look forward to seeing it in the next release

[divVerent]

mapinfo intentionally does not contain a path to the jpg, or anything else referring to the map's internal name (file names), so it is easy to rename a map (which was a LOT of work with the mapcfg system because of all the names everywhere... change the jpg names in all txt files, change the changelevel line in all mapcfg files... rename all files properly... ugh).

Also, most maps DO follow the convention jpg name = map name, so I simply decided to force this convention for all maps. It's not hard to rename a single jpg after all.

[...] CTF is reliably autodetected.[...]

no...
I made a CTF map, and I can not get it to do CTF...
tried:

  Code:

g_jetpack 1 #my map needs it
g_ctf 1
restart


but it did not work...
am I suppose to put that info in to the worldspawn?

the flag is /item/item_flag_team1 and .._team2?

how do i set so that the map starts with g_jetpack 1?

[morfar]

no...
I made a CTF map, and I can not get it to do CTF...

Not if you tested your map in Nexuiz BEFORE you added CTF entities (flags)!
Because the game auto-generated a .mapinfo in your data/data/maps/ folder without CTF support.

thanx... that worked...