engine bug: func_plats behaving as SOLID_NOT

[qbism]

Has this ever happened to you:

The engine I'm working on "almost" supports certain large maps. It can load and run oms2 ( http://www.celephais.net/board/view_thread.php?id=60453 ) EXCEPT that BSP_SOLID entities like func_walls and func_plats seem to behave like SOLID_NOT. Player can trigger plats, but player and bonus items fall through.

Only noticed bug with oms2 so far, although it's not a map bug. Map works fine in Fitzquake. Plats in other largish maps behave normally, such as apsp2 (Plumbers Don't Wear Ties).

Screen of armor under a ledge (actually a plat). The armor spawns above the plat but just falls through.

[Baker]

Not sure what to say ... I have 2 engines with FitzQuake protocol support that don't have this issue ...

I am wondering what your issue could be as mine don't have that issue.

I am also guessing that DirectQ does not have the issue, nor FitzQuake proper. Where does all of this ... barring some possible ignorance of mine ... leave this thread?

Well ... I can only think of the self-made bugs department at this time. Subject to change without notice, but methinks that such a proper notice isn't gonna happen.

[mh]

I'd guess that you're missing the clipnodes fix in SV_HullPointContents; needed for more than 32768 clipnodes in a map. This one plagued me for a long time too (I was only looking at the rendering and loading code at the time and missed the fact that there might be changes needed elsewhere).

Someone really needs to document all the places where changes are needed for large map support.

This was asm in the original code, but it's easier (and not a performance problem) to move it to C.

[qbism]

mh: Sweet mercy, that was it! Thank you!

Thanks to metlslime for the thorough Fitzquake commenting and Baker for the additional Fitzquake protocol documentation.

Two separate big map support issues with a lot of overlap can be confused: data handling and protocol.

[mh]

SV_RecursiveHullCheck also needs it, by the way.

[qbism]