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. 

Thanks to Tronyn and PM for doing something with the format. Too drunk to elaborate. 

A tremendous accomplishment. Such a huge map that nearly forms an episode by itself: painstakingly constructed to perfection til its smallest bits, ingeniously interconnected to ease up navigation and reward exploration, populated/balanced such that the over an hour long trek never gets boring, unfair nor disencouraging. The single fact that I haven't got lost nor died even a single time throughout a map that took seventy minutes to beat and put me against nearly 700 monsters shows the amount of skill on display here by itself.

I have used RMQE (r3714) and haven't encountered any bugs (this should be the first choice for anyone out there who haven't played this monster of a map yet). Though it still requires a bit of cvar fiddling to revert it back to less 'flashy' visuals. There are a few more, but these three are crucial:

r_colored_dynamic_light 0
r_colored_dynamic_light_mflash 0
r_motionblur 0

Still, I haven't figured a way to keep Death Knights from lighting up the whole area whenever they use their ranged attacks or the spiders from doing the same wherever they die. There isn't any documentation on the specifics of the engine so I had no choice but to try to make it out from the config output. I don't know what the following change exactly and I'll be grateful if any of the original coders can explain them (values are the default ones):

r_instancedlight 1
r_lightscale 1
r_uwfactor 512
r_uwscale 2
r_warpfactor 2
r_warpscale 8
r_warpspeed 4

Anyway, even though it was a bit of a hassle to run, this masterpiece was worth all the effort on my end. It was breathtaking, even intoxicating to behold most of the way and highly enjoyable to play all throughout. It was the perfect finale for today's Quake festivities of mine.

Thank you Tronyn.

wickedstart - 5:40, 2/3s
wicked - 70:15, 12/30s, 674/690k
wickedend - 7:27, 2/2s, 98/101k 

Thanks for the feedback, and the level of detail in it, and the tips that should be useful for other players, too. Cheers.

My Q1SP reviews should finally be coming soon, and I should have another Q1SP out this summer. 

 

unfortunately, I doubt it; it is vised, but there's open areas and lots of monsters... if you could run all the maps in RMQdemo2, you should be able to run this... but I'm not hopeful. Sorry! 

Yes I know what you mean but with that config I still manage to play almost all Quake thingy just with not too demanding engines !

..it's a maniacally well setup config with all the fastest drivers for voodoo3(1.05), directx8.1, win98se tweaked(eheh), etc..

From my experience if a map is vised then..ehr should be at least playable(I'm happy even with 15 frames per second) 

680/690 Monsters 29/30 Secrets

97/104 monsters, 2/2 secrets for the end Map

0/0 Monsters, 2/3 secrets for the beginning

And what is Hell Skill?? 

is pure crazy. Monsters have kind of Zombie mode, they just don�t
die but come to life after some time.
Heavily unplayable, at least you have to be Orbs. 

I put sdl and sdl_net dlls in quake folder but when run rmqenginewin32.exe error:
ARB_TEXTURE_CUBE_MAP_NOT SUPPORTED 

I don't expect to be able to help much, but what version of RMQEngine, and what operating system?
Have you tried DarkPlaces (http://icculus.org/twilight/darkplaces/) or FETQW (http://www.fteqw.com/ftedownloads/experimental)?