question about q3 .map handling

(VolumetricSteve) #1

I’ve been googling for a solid two hours now, and I’ve managed to track down the .map specifications for quake 1, but I can’t find anything for quake 3. I did find about 4 versions of the Q3map and Q3map2 shader manual, but that doesn’t help me today. I just want to know where I could find the reference document that outlines how the quake 3 .map format is structured.

I’m mirroring id software’s FTP for everything quake 3 related and I’ll be sifting through all of that in a while. I’d think it has to be written down somewhere so that the people making the level editing tools know how to make the .map files save correctly. It also crossed my mind that Q3map2 would have had to make use of a such a reference as its primary purpose is to read in .map files and output the bsp counterpart.

Thanks for any links/suggestions!

the cause behind my quest for knowledge:

A friend of mine has recently been getting into quake 3 mapping (better late than never) and he ran into a very strange issue, one I’d never even seen/heard of. His map would fully compile with no errors, but when quake 3 would load it, he’d get an error saying “recursive error after: SV_SetBrushModel: NULL” - this error actually causes ioquake3 to panic and close instantly.

After a lot of tinkering, we eventually found that the problem seemed to stem from NetRadiant handling triggers and events weird. It occurred to me that since the error mentioned “NULL”, the issue was probably that some element of the map, say, a trigger, that isn’t really looked at in-depth during compile, was being written incorrectly into the .map file. My guess is that the .map was supposed to have a line in it that said something like “this trigger causes event X in conjunction with brush Y” but all that made it into the .map file was “this trigger”

He eventually “fixed” it by selecting his entire map, copying it, and dumping that into a new map file in NetRadiant. As nice as it was that doing so resolved the issue, it doesn’t really stand to reason that making a duplicate of bad code somehow produces good code. I endeavor to find out more about the cause and solution of this issue.

(merlin1991) #2

information about .map format, have fun here: http://qeradiant.com/cgi-bin/trac.cgi/browser/GtkRadiant/trunk

about the sv_setbrushmodel : null error

it is thrown when you have some entity that should have some brush but hasn’t

rotating door without origin, …

one problematic cause of this is, that if you create some entity and delete all it’s brushes the entity is still in the .map file and gets compiled into the bsp, you see it in the editor because you have the entity name written at 0 : 0 in the 2d view.
You have to delete the entity, you can search for it in the entity list window (L opens it I think) and remove it, or search the mapfile for sections like

// entity 227 
{
"classname" "someclass"
}

be aware not to remove entitys that would work without brushes and are perfectly fine in that form though (those normally have an origin value)

Selecting everything and dumping it fixes that, because radiant doesn’t select empty entities that should have a brush :cool:

(VolumetricSteve) #3

thanks for that, I’m surprised there isn’t just a document somewhere describing the ins and outs of the .map format, but if I have to read through a mountain of code, so be it.

That’s kinda what I figured about the error, just wanted to make sure. It’s strange that it doesn’t come up as a compile-time error though.

(kamikazee) #4

Actually, IIRC the .map format has remained mostly the same as the original Quake map files over the years. After all, the idea is still the same: you start with the void in which you’re adding brushes and entities.

The only real changes have happened in the brush definition format: these have changed from planes bounded by 3 points to normal vectors from the origin - likewise for the texture info.

(VolumetricSteve) #5

I did run across that page in my searching, I wondered if it was too new…as that info pertains to doom3’s .map format. and I agree, that is most likely the biggest difference, and probably the only substantial one, I’m just surprised Id didn’t release a .map spec when quake 3 came out. Did they just expect people to dig through Radiant’s source to find all of the ins and outs? Thanks for the replies.