Quake3World

I was looking at the Call of Duty BSP format (Version 59) and noticed that of the 31 lumps (as opposed to Quake 3's 12) only a few of them have any data in them.

I've compiled bsps with varying numbers of lights, brushes, textures, etc and these "null" lumps always have a length of 0 and their offset changes.

Are these null lumps used for making BSP Version 59 a unique version or do they likely have an actual game-related purpose that I just havent discovered yet?

The latter. Changing the BSP version requires nothing more than changing a few bytes in the header.

hm ok thank you misantropia. Once again you come with a quick and helpful reply

I'm assuming the null lumps are probably related to the single-player maps. I've been working with the multiplayer.

The whole reason for this is Im trying to add full-fledged support for Call of Duty 1 to q3map2. I'm hoping to add in support for the game to GTKRadiant 1.5 as well.

I'm assuming the null lumps are probably related to the single-player maps.

My thoughts exactly. They most likely contain data for (for instance) the SP AI, scripted events, and all that jazz that doesn't apply to MP. On a side note: baking such things into q3map2 might not be trivial.

Though, when I come to think of it, q3map2 has support for RtCW and that game has all the features I just mentioned (but in external files, I don't know how COD1 handles that).

Ill compile some SP maps adding in one sp element at a time to see which "null lumps" change to see what their purpose is.

Since Im mostly interested in adding support for the game to make my life easier when making maps for CoD, I suppose I could completely ignore these empty lumps during compile and then at the end have q3map2 add those lumps in to complete the bsp so it would be two separate stages.

But its not fair to half-ass it and leave the SP out

So far I've determined the following:
/edit: Turns out the SP lumps are actually not SP lumps. They're used in MP too as looking at a stock MP map showed. Interesting.
Lump Total: 30-31.

Lump 0: Shader Information
Lump 1: Unknown.
Lump 2: Possible Number of Planes
Lump 3: Number of Faces (6 6-faced brushes = 36. Adding one more 6-sided brush increased this data by an equal number)
Lump 4: Unknown. //length remains the same on map change.
Lump 5: Unknown
Lump 6: Unknown.
Lump 7: Unknown
Lump 8: Number of Brushes
Lump 9: Unknown.
Lump 10: Unknown.
Lump 11: Unknown.
Lump 12: Unknown.
Lump 13: Unknown.
Lump 14: Unknown.
Lump 15: Unknown.
Lump 16: Unknown.
Lump 17: Unknown.
Lump 18: Unknown.
Lump 19: Unknown.
Lump 20: Unknown.
Lump 21: Unknown.
Lump 22: Unknown.
Lump 23: Unknown.
Lump 24: Unknown.
Lump 25: Unknown.
Lump 26: Unknown.
Lump 27: Unknown.
Lump 28: Possible Number of Portal Clusters
Lump 29: All Map Entities

Started on this once more and have been focusing on Call of Duty 4's .d3dbsp. It's a .bsp with a shifting number of lumps (null lumps aren't compiled into the .d3dbsp)

The decompiler/compiler I'm writing is based off of the q3map2 source without the gtkradiant dependency.

Right now it supports CoD 4 and CoD 5. I'm also going to add in CoD 1 support.

Here's a lightmap I yanked from a CoD 1 .bsp:

Neat work. Well done.