Talk:BSP (Source)

This page could really use some updates. It mainly specifies version 19 with some notes about 17 and 20. Version 21, introduced with Left 4 Dead 2, is completely untreated. I found out some changes in version 20 and I'll put them here, but some parts need to be reorganized. Otherwise, it will be pretty messy here soon with all the different versions. --Barracuda 05:32, 4 December 2009 (UTC)

I have moved HL2Ep1 from v19 to v20 as I've looked in the ep1 bsps and they specify 20 --Omnicoder 07:22, 15 February 2010 (UTC)

That's because they've updated the engine for HDR support and re-compiled the maps. CS:S also has version 20 BSPs now and version 19 before the update. --Barracuda 10:10, 11 March 2010 (UTC)

Correction: Looks like Ep1 never used v19, so you're right. But I updated the table regarding CS:S. --Barracuda 10:26, 11 March 2010 (UTC)

Changing BSP Version

Is there any way to change a BSP Version 21 file to 20? --Adam.gamedev 20:58, 30 November 2010 (UTC)

The engine features aren't compatible so no. The best you can do is decompile and recompile. It would be possible to code something to do it but it would result in loss of information and an imperfect downgrade. --Omnicoder 23:46, 30 November 2010 (UTC)

Displacement Format

The documentation on the displacement lump is frankly awful. It never explains what the CDispNeighbor or CDispCornerNeighbor structures are, or even how large they are, and ALLOWEDVERTS_SIZE is never expanded upon either (though according to the BSPSource source code it turns out to be 10). --MofoMan2000 04:05, 11 September 2012 (UTC)

Linking Brush Sides and Faces

According to the article, "Note there is no direct way of linking brushes and brushsides and the corresponding face array entries which are used to render that brush." Does this mean there is an indirect way? Does BSPSource use an indirect way of linking them? It must do something close because it processes overlays properly, right? --MofoMan2000 17:58, 6 April 2013 (PDT)

BSPSource compares the geometry, plane index and texinfo index of the original faces with these of the brush faces and creates an indirect mapping based on that. It's really not perfect, but it works for like 80-90% of the faces. --Barracuda 10:20, 7 April 2013 (PDT)

Tactical Intervention XOR Encryption

The XOR encryption for Tactical Intervention is a 256-bit repeating pattern. I have successfully decrypted it (after only an hour of research), and it is fairly trivial. Do we want the encryption key posted in this article? --MofoMan2000 10:34, 2 May 2013 (PDT)

I suspect the key is different for every account, the maps that I have use the key "C43C43A8541F102CE8F69083167C7756". My current developer version of jbsplib tries to read the key directly from the BSP file by simply reading 32 bytes at offset 384 that are always nulled in the unencrypted file (source code). --Barracuda 04:01, 3 May 2013 (PDT)

Hmm, it seems you're right. Mine is 0x4334334334334138353431463130324345384636393038333136374337373536. And I found it using the exact same method... --MofoMan2000 11:44, 3 May 2013 (PDT)

Actually, stupid me, I was reading your key as hex when you pasted ASCII. They're identical. --MofoMan2000 12:43, 3 May 2013 (PDT)

Hm, interesting... still, the key may change between versions. It was "76A26FB0F46542DEA4876634F9396E28" in older maps using version 20. But since it's so trivial to read the key, there's no reason to hard-code them. :D --Barracuda 15:52, 3 May 2013 (PDT)

Contagion

I haven't found any differences between v27 found in Contagion and v21. Anybody know what's different here? --MofoMan2000 13:32, 9 December 2013 (PST)

StaticPropDictLump_t content mistake?

In this extract, I do not understand where a series of character strings can be stored, as dictEntries is the number of model name entries.

struct StaticPropDictLump_t
{
	int	dictEntries;
	char	name[dictEntries];	// model name
};

I believe that name should be declared as char name[128][dictEntries].

I am not confident enough to confirm this, so please can anybody confirm this and fix the wiki? Thanks! Mohamed RACHID (talk) 11:17, 28 December 2019 (UTC)

fourCCode is no longer used an identifier.

Been checking through the Source Engine code lately and found this out by the code section in source-sdk-2013/src/public/bspfile.h:

struct lump_t

{ DECLARE_BYTESWAP_DATADESC(); int fileofs, filelen; int version; // default to zero // this field was char fourCC[4] previously, but was unused, favoring the LUMP IDs above instead. It has been // repurposed for compression. 0 implies the lump is not compressed. int uncompressedSize; // default to zero

};

So, the binary format needs to be updated. - Amicdict (talk) 19:05, 31 May 2023 (PDT)

Texinfo flags bit-field seems to have been reduced to 16-bits; also texdata is an index not a pointer.

The texinfo section states that the flags field is 32-bit; however it's stated in the Source 2013 SDK (mp/src/public/bspfile.h) that the engine uses 16-bits. This should be noted.

Also, texdata is not a pointer; if it was it would be commonly pointing to the header or nowhere close to the texdata lump. - Amicdict (talk) 18:03, 5 June 2023 (PDT)