Capture Compiler Signatures

[snake-biscuits]

Would be nice to see the Compiler Signatures left behind by some compilers This can provide us with useful information about a .bsp's specific quirks Being able to sign our own edits would also be useful

All the signatures I have seen are placed immediately after lump headers Implementation would have to be per BspClass._preload method Capturing other hidden information placed between lumps would be nice

Ties into #15, since we capture more of the raw bytes to save back into the new copy Might also be relevant to XBSP extensions to QuakeBsp which include extra lumps on the tail of the .bsp

BspClasses with signature capture:

• [x] id_software.QuakeBsp
• [ ] id_software.ReMakeQuakeBsp
• [x] id_software.IdTechBsp
• [ ] id_software.D3DBsp
• [ ] ritual.RitualBsp
• [ ] valve.ValveBsp
• [x] respawn.RespawnBsp

[snake-biscuits]

We will need test maps w/ signatures for each BspClass The only compilers I know of which leave signatures are Radiant & it's forks

BspClass	Editor	Compiler
id_software.IdTechBsp	GtkRadiant	q3map2
respawn.RespawnBsp	MRVN-Radiant	remap

[snake-biscuits]

The only compilers I know of which leave signatures are Radiant & it's forks

Could check MegaTest bsps for signatures & do something with those generated statistics

[snake-biscuits]

Capturing IdTechBsp signatures revealed a header for LUMP_ADVERTISMENTS[^ads] This appears to be a Quake Live (IBSP v47) feature[^struct], but appears in tests/maps/Quake 3 Arena/mp_lobby.bsp (v46)

[^ads]: TTimo/GtkRadiant on GitHub: q3map2/bspfile_ibsp.c [^struct]: TTimo/GtkRadiant on GitHub: q3map2/q3map2.h