fbsp comes from qfusion, and is really just rbsp (from raven's q3-based games) with bigger internal lightmaps (which is quite minor in the grand scheme of things).to implement it, you first need q3bsp and all of its capabilities. you then need to implement multiple lightmaps per surface, and blend them together, probably while also trying to deal with q3 shaders...which is probably why dp doesn't support it despite already having q3bsp support.so yeah, fte is the only q1 engine that supports it, and dp can only be described as inactive, so I doubt that's going to change any time soon.

when GB was messing around with rbsp, he found q3map2's support for it to be somewhat dodgy, resulting in various lighting bugs. So watch out for those. Maybe they've been fixed since.

mh was messing around in rmqe with a lighting system like that imposed by rbsp (there are performance advantages when your entire [highly detailed] map has smoothly animating lightstyles), but that engine lacks all the other things q3bsp would require.

Sorry ericw for the late reply, I guess I didn't see your post! Thanks I'll try, even if I prefer to stick to q3bsp (to be honest I hate q3bsp too and I'm literally craving for a brand new level format, modern and completely compatible with blender scene, but, whatever)

I have a fairly large map (bigger than 4096 but below the 8192 qu per quadrant) where in FTEQW occurs the "leaking void mirage", although gl_maxdist is already set to 0. The map is built using TxQBSP 1.13 and VIS 2.31 and there are no leaks. Any suggestions on how to fix/avoid this ?

I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)

1: does the 'void' move with the camera? does it suddenly appear? or is it at a fixed boundary regardless of the camera?2: does the qbsp version that you're using still have 8192 hardcoded into BaseWindingForPlane, or has it already been fixed to deal with larger maps? (iiuc txqbsp 1.13 still has this problem - note that this 8192 limit is radial rather than axial, which means it can be lower for non-axial surfaces)3: did you try compiling with a qbsp that is known to have BaseWindingForPlane already fixed/extended? like tyrutils-ericw or hmap?

1. Yes, it pops occasionally in certain areas (like the spawn point which is roughly at the center);2. Nope, haven't tried other qbsp compilers because I believed it supported bigger maps. Thanks for the tip, I'l check it later.EDITYeah, tyrutils qbsp fixed the void issue... but now some parts of the map are non-solid. :/Welp, I'll try another port. Thanks for the help, guys.EDIT2Tried hmap2 and now everything works as expected. Thanks again.

I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)