Light colour

[frag.machine]

/me suggests adding support to embedding the .lit file contents into an extra, optional lump as a desirable feature in BSP2...

[mh]

Always expanding light to 3-component was considered but rejected because it would create a dependency on having coloured light support in an engine before BSP2 could be implemented. An extra optional lump is a possibility (we didn't reserve space in the header for marking this kind of thing though ) but I'm not seeing how it's much different from just having a LIT file too.

LIT files are nice. You can delete them, move them around, recompile your lighting without affecting the source BSP, keep multiple copies for experimenting with, etc. All advantages. I can see that including it in the BSP can make distribution easier, but in this case I think the case for not including outweighs.

[Spike]

there's one strong case for internal lit files, and that's with automatic downloads in various engines (quakeworld for instance) - most clients won't autodownload lit files. which means you're either attempting to download a lit file from the server every single time (probably even for vanilla maps...), or you expect to never have the lit file for custom maps.

some sort of optional lump would be quite nice...
/me points at http://www.quakeworld.nu/forum/topic/47 ... esignsucks

[ajay]

[mh]

[Spike]

its really just internalised lit files in ezquake.
the bspx lump trails is located at a position after the standard lumps, so you will likely need to rewrite the entire bsp to add an extra lump (assuming it already has a bspx lump in there - if it doesn't then you can probably just append, so long as the offsets in the part you append are correct).
dface_t offsets are the same as they always were, giving backwards compatibility - like I say, its just an internalised lit.

[frag.machine]