I believe two engines support bsp2, and they aren't even compatible implementations, sadly (darkplaces has an altered spec for it, for some reason.) 

and it seemed to work at first - i played through the start map and a little way into the first main map, and then as soon as i got to the first "Baron" knight thing, the game crashed with some "cl_parsetent" error.

I tried restarting and quickloading, but the thing crashes if I try to quickload, so that's as far as it looks like I'm going to get with this one. 

I finally managed to play this after Negke sent me an older build of FTEQW that didn't crash when loading a game.

That said, it felt a bit buggy with quite a few graphical glitches that I never get in Fitz. Also, the player movement physics felt a bit...fucked. I'm not sure what the problem was exactly but whenever I was moving on stairs or slopes, it felt like control was partially removed like I was sliding around on ice or something. This caused me to plummet off ledges more times than I can remember and I just got used to hitting noclip and flying back, which kind of killed immersion. Also, the music stopped playing early on and I never could get it back.

I think all this resulted in an experience that was quite a few notches below the level of enjoyment I had playing the extra arcanum maps yesterday, but that's not your fault Tronyn.

The main map is a monumental construction, and to be honest I found it overwhelming at times, but amazingly I didn't get too confused with the layout and it seemed reasonably easy to find my way around it once I'd opened it up a bit.

The scale of some of the spaces is mind-boggling. It would be very interesting to see what could be chopped out to get this to compile in normal bsp format, whilst retaining as much of the epic feel as possible. I'm fairly certain it could be done.

I played on easy, but even so the Quoth enemies do my head in quite frankly so I was a bit dissappointed to find out I had to fight Droles and those flying lightning things.

If this map had vanilla weapons and a skew towards mainly vanilla monsters and worked in Fitz, it would have been one of my all-time favourites, I'm sure of it. 

The build I used to play it allowed me to save whilst dead for some reason. I found this out the hard way during the end map. In the chaos, I quicksaved whilst dead. That was fun. 

that's an odd bug.
I'm sorry this didn't work out as well as it ought to have, though at least you were able to play it at all. And I'm glad for the enjoyment you did get. I do feel your pain though since I don't like messing around in unfamiliar engines. I hope that more engines eventually support this format (at inside3d I was basically told if you build it they will come).

I think that the map could possibly be split in two (the Tyrann castle front/first cave for map 1, and the Necros courtyard/associated areas/second cave for map 2) and compiled in normal bsp. The thing is by the time I got to that point, the layout had become so intertwined on both sides ("swiss cheese" as someone remarked) that it would have been really artificial to cut things up that way. The size of the map is kind of exhausting even for me and as a result I made the decision to split other forthcoming maps in two.

Anyway, thanks for the feedback on this and the Arcanum stuff too! Cheers! 

I should add, that I have nothing against the BSP2 format, and would love to see it supported by Fitz (or whatever we're calling "Fitz" now, Mark V or QuakeSpasm or whatever.)

From what I understand from reading mh's blog, BSP2 is a completely reasonable and minimal change to the BSP29 format, and I think if we didn't have to go through all this engine pain to see it in action, it could be used for good things. 

Having played the second map several times in various formats, I enjoyed this version the most :)

The start map looked great with its blue sky, message plaques, and hidden entrances to Nightmare and Hell skills. It might have been nice to see that sky echoed in the other maps, though.

The final map was just as spectacular as the other two, but a bit frustrating until I realized that I could handle the hoards without breaking my neck to get the power-ups ;) I loved the monster variety, BTW.

The ambient sounds and music in all 3 maps really enriched the experience!

Congratulations, Tronyn, on releasing the best BSP2 map to date! 

why Tronyn doesn't use that extra special Canadian technology in his maps.

Best I can figure, he's been holding out on that. 

I posted a new darkplaces build today with support for this fine map pack and a number of other fixes for existing maps with issues like hip2m3's shalrath now work properly, and sv_gameplayfix cvars are off by default (the disruptive ones, anyway) so it is a more authentic Quake experience.

Congratulations Tronyn, this is a great map pack :) 

Thanks a lot, I will try it out right away!

I'm glad to see Darkplaces supporting this format, since I have a couple more forthcoming maps that are also too large for normal BSP format, and I've always liked playing in Darkplaces. 

checked out your update and saw that this is apparently the less efficient BSP2 format of 2... I'm of course willing to recompile this and change compilers for future maps. And I hope the format will be more unified. 

There's also my hmap2 compiler suite which produces bsp (if within limits) or bsp2 (if not within limits), the raised limits turned out to be essential in compiling a lot of maps that do end up within limits but are a bit over-the-top during compile.

The BSP2 produced by hmap2 is different than the RMQe one however, it has expanded coordinate limit (hmap2 can produce maps "Slightly larger than Earth" after all), the RMQe one kept the +/-32768 coordinate limit of Quake bsp29.

They are otherwise identical and I hope engines will support both, ideally I should add a flag to hmap2 to produce the RMQe bsp2 format for ultimate compatibility.

Not to knock the RMQe BSP2, it's a good upgrade, I just saw opportunity to upgrade it all the way.

DarkPlaces also has a special lump loader that detects expanded lump tables in the bsp, so we could easily extend the bsp format with more data (for instance lightgrid for model lighting like q3bsp), this would work with all quake bsp formats, but obviously the compiler has to produce such data.

My main worry with recommending hmap2 is that although I am confident it is the "anything goes" ultimate limits compiler, it is not multithreaded. This means its qbsp and vis stages can take considerably more time than other compilers, but at least the light stage is super optimized (so fast that -extra8x8 exists just to let you have it grind for minutes on higher quality lighting, normally it doesn't take even a minute), be sure to run light AFTER vis however, to get that speed gain. 

As a regular fan of your work with A Desert Dusk occupying a special primordial place in my heart ...

One troublesome gremlin is that in coop on maps like the Masque of the Red Death or Arwop, client players (i.e. not the listen server) often fight invisible monsters after a while because all of the decapitated scrag heads, coins and such.

I hope at some point engine technology catches up with your monster count. It sucks fighting invisible scrags, hellhounds in coop as a client due to super-high entity count.

Maybe eventually this problem with be solved, as these giant maps are very coopable as coop needs tons of monsters to entertain. 

Thanks for continuing to work on DP from a q1sp POV, it is much appreciated! 

And thanks for the complete BSP2 support as well :) 

so rmq 3714 is the best way to try this? 

DarkPlaces also has a special lump loader that detects expanded lump tables in the bsp, so we could easily extend the bsp format with more data (for instance lightgrid for model lighting like q3bsp), this would work with all quake bsp formats, but obviously the compiler has to produce such data.

Using a light grid could be used to have better shading on liquids? I think maps would look considerably better by having that. 

Why hasn't someone simply supported lightmaps on water, anyway? Is it that hard of an engine thing to support? I mean, it's a surface and it's in the BSP so ... ? 

There are probably a few technical issues you'd have to worry about - like if the water texture is being distorted do you distort the lightmap as well (and is it easy to separate those concerns). I imagine the main problem is that no maps have lightmap data for water, no tools support creating them and no engines can apply them. So what comes first, engine support for lightmaps nobody creates, or tool support for something that can't be loaded?

One thing that might be possible just on an engine level is to create a lightmap for the water in the same way as models are lit - i.e. read the light level from the lightmap directly below. Doing it once at map load time shouldn't be terribly slow. You might end up with a lot of bad looking maps though if people haven't lit underwater spaces thoroughly. I think you'd certainly want to boost the values a bit since water is currently fully lit and you'd want the effect to be subtle. 

are something I asked about before too, I think Tyrann tried to add it but it didn't work, something about the engine needing to support it. I never thought about the water distortion before Preach just mentioned it, I guess it would probably take a little more work to impliment than I originally thought.
What would be nice is if you could add a key that the engine would recognise as lightmap-enabled and on older or unsupported engines it could display in the default fashion? 

From a vague understanding of lightmaps in the BSP, it should be possible to add extra lightmap data in a backwards compatible way, the engine will just ignore it. I don't know if you can associate a lightmap with a water surface as easily without breaking backwards compatibility (I'm sure there will be some way though). 

Why hasn't someone simply supported lightmaps on water, anyway? Is it that hard of an engine thing to support? I mean, it's a surface and it's in the BSP so ... ?

One issue with that is that some maps allow for draining of water etc... which would cause inconsistencies. A light grid wouldn't have that issue since it's volumetric. It would also help the models being lit more consistently; using the lightmap below is a crude approximation -- though it works surprisingly well most of the time.

But imo any vaguely consistent lighting is better than no lighting. 

took me a while to make some time for and about 15 min of dickery to load (first download right rmq engine, then sdl.dll, then sdl_net.dll) but was it worth it?

Absolutely. Totally amazing all round but what I liked was the fact that the architectural scale actually fitted together with the gameplay scale and the beefed up weapon scale. It was one big OTT jaw dropping, brutlaly fun experience.

Seriously I have no idea how long this took to make or how you guys just keep managing to up the ante so much every year but this is mind boggling mappery. 

thanks for the compliments, glad you enjoyed it. It definitely took a long time to make!

I take inspiration from the fourth episode of The Ultimate Doom, "Thy Flesh Consumed," where the designers knew the engine capabilities well, and also knew that anyone playing it would already be familiar with the game, so they just went ahead and made huge, nonlinear levels, that assumed the player would find their own way. Although with this, after some playtesters got lost, I decided to err on the side of making the route obvious, since what's the point of all the testing and compiling etc if people are getting lost. 

I think I got lost maybe once but I have a habit of wandering around levels just looking at stuff anyway so I dont mind even if I do.