.map-structure

(MuffinMan) #1

got a question on the .map structure - i am trying to develope an online tool (PHP) for collaborative mapping projects, which has to de- and reassemble map-files. i know how a .map is structured - just wanna be sure here:

// entity 0
{
“classname” “worldspawn”
// brush 0
{}
// brush 1
{}
}
// entity 1
{
“angle” “90”
“origin” “2496 -7608 24”
“classname” “team_CTF_blueplayer”
}
// entity 2
{
“classname” “func_group”
// brush 0
{}
// brush 1
{}
}
// entity 3
{
“type” “patchCapped”
“classname” “func_group”
// brush 0
{
patchDef2
{}
}
// brush 1
{
patchDef2
{}
}
}

is this really everything a map can consist of, and if not - what more could be in (as far as structure is concerned, the data in it is not important…) this is taken from rtcw, i guess ET is the same or are there any differences?

is there any other patchDef than patchDef2? what about the ‘2’ at the end?

thanks for helping!

(SCDS_reyalP) #2

One trouble with doing any kind of diff/revision control on .map files is that radiant re-orders stuff with each load and save, even if it hasn’t changed. Simply loading and saving a map will change the order of the planes in the brushes.

Oh you might want to check out the new xmap format avialable in 1.3.x radiants, that way you can use a standard XML lib instead of writing your own loader/parser etc. I don’t know what stage of development it is in. ET Radiant doesn’t seem to have any trouble loading/saving it but when I tried compiling an xmap q3map2.5.7 seemed very confused.

(MuffinMan) #3

the reordering is no problem for my attempt to it, what i am doing is to give the people an overview of the map and then let them select the area (by dragging) to work on, which then is put together in an own smaller map and all the brushes are locked in the master until it’s uploaded again, all the parsing works on coordinates, not brush/entity-numbers

the xml format though sounds interesting, as it might be sure to have it compatible for a long time