It compiles. Despite the 80 something K clipnodes, I can run e1m2rq again in RMQe. And everything works. Even the rotating bmodels work correctly, which means the rotation fix appears to do what it’s supposed to. So BSP2 is working, and RMQrotate is working. It’s not a dream, even. It’s SOLID_BSP reality.
When a tree falls in the wood, and no one hears it fall, does it matter? Oh yes, it does. It fell with a deafening noise, actually, but it’ll be some time before the shockwaves hit. BSP2 means that 64k vertices or clipnodes are no longer a hard limit in Quake mapping. This allows for truly monstrous maps. A couple other hard limits were also raised (about doubled, IIRC) so the BSP format should no longer be an obstacle to your bloated levels…
This is crazy stuff. We can all thank MH for a heroic piece of tools coding, despite not being a tools person. Hats off to you, sir. I’m sure this won’t just benefit RMQ, although it resulted from RMQ development, it’s in fact independent of it. Everyone can use these tools and the engine for their purposes. MH even wrote a relatively thorough documentation of the changes aimed at engine coders.
I hope there will be a release of the tools and engine as soon as they stabilize somewhat.
For us RMQ mappers, this means that a couple especially decadent maps can now be finished without having to always watch the vertex or clipnode counter. We can now go all out with realizing our visions. For e1m2rq, this means a map that’s completely open, where you can walk and grapple around on the roofs, fighting dragons, jump off massive towers, and gaze at the terrain the core of the level is embedded in, as if it was part of a much bigger world. The new format will also enable me to create an absolutely massive outdoor setpiece in e1m5rq, containing a fully realized massive stronghold / keep in a landscape of dead moats and mountains, again completely playable – you should be able to climb every part of the fortress’ walls and ramparts, and siege engines can send fireballs over large distances.
It also means that I can now make meaningful use of Entar’s terrain generator program, and I can use a smaller grid size for it since I don’t have to watch the vertex count as closely anymore. This means not only bigger, more realistic, but also more detailed terrain. I’m sure some of the terrain artists in the Q1 mapping community will appreciate this new freedom.
Two other relevant things shouldn’t be forgotten: First off, the RMQe not only runs this bloated map, it also runs it fast. And that’s with a fastvis and the level being totally open (ie enclosed only in a big sky box). Second, the inclusion of the rotation fix (thanks to Lord Havoc) in the BSP2 tools means that RMQrotate is fully working, collision included. This means origin-rotating bmodels like in Half-Life or Quake 2 (using an info_null instead of an origin brush, but otherwise the same). The one thing that’s missing from RMQrotate is a rotating train. What we already have are rotating doors (including paired doors, key doors etc) and continuously rotating bmodels with acceleration and deceleration. No more func_movewall collision hacks, no more stairstep effect on rotating entities, smaller model count. It beats hiprotate hands down.