The real, let's say let down, for me is gameplay. After a somewhat challenging start, by the time you come back from getting the blue key, it is all over. Nice and varied as they are, Quoth base monsters are still base monsters, at the core, i.e. cannon fodder.

Don't really agree with that. Quoth base enemies are a pain in the arse, I'd rather face medium level Quake enemies most of the time.

Sniping from a distance is all very well if: 1. They are at a distance and not crowded round the top of a very slow sticky ladder you're climbing and 2. Actually visible cos most of the enemies in this map seemed to be lurking the dark spots.

Not that that's always a problem but I don't think gameplay can be glossed over because it's "just" "base" enemies. 

You're right, Sham...

But, having a RL, GL and almost infinite supply of ammo for those, everything becomes quite... Well, you know...

Anytime you hear a suspicious sound, all you have to do is lob some 10 grenades in the hole you heard it come from and you're done. Then you just have to go in a finish off the job with 1/2 SSG shots...

I was referring to the rather large groups of grunts you get to meet while making your way up to the reactor... You take them out without breaking a sweat... Same with Edies on your way back...

But I'm not saying this is necessarily bad, it's just that I had the feeling this was quite easy on NM, and I consider myself a below average player...

But,hey, this is a great level! Maybe it's just me growing up and playing sober. My aim improved dramatically!!!! 

Thinking of TheSilent at the age of 17 playing Quake drunk all the time and dieing 

When I was 17, Quake was still 10 years down the road...

Had to settle with playing with myself... ;P 

But I'm not saying this is necessarily bad, it's just that I had the feeling this was quite easy on NM, and I consider myself a below average player...

You're wrong on that, you're not a below average player that's for sure. Having read your comments elsewhere and on this, it's obvious you're well above average.

This felt reasonably tough on Skill2 and I assume that being a base map Skill3 is definitely harder. It's not too tough by any stretch IMO though, just tough enough.

Anyway, I do agree about the RL, it is all over once one gets that. The GL, hmmm, I was being careful using it. I don't think the terrain is always conducive to it in this map. 

Aw... well... thanks.

As a matter of fact, you get the RL fairly soon, if you hunt it down.

The same in APSP2, for instance, but the shortage of ammo and the environmental hazards made up for a much more balanced experience IMO.

GL is the key to this level. Especially the ending.

Tonight I'll record a demo, so you can see what I mean.

For now, thanks for your rather high consideration of my skills.

And thanks JPL for a great level! 

jdhack:
Thnaks for the positive comments. I had some comments about breakable objetcs made by negke during beta testing, but due to my lazyness (after 1 year of work, I've been quite pissed off the map :P) I didn't add some: my mistake...

robot: Again, thanks for the feedback. I noticed also lately the elevator issue in the fullvis version. My problem is that I don't know why it is not present (i.e HOMs and elevator desapearing) in fastvised version, and present in fullvis version. aguirRe told me some ime ago it may happen for some dark reasons he is not even aware of... Maybe it is due to the map size... not sure.... I also didn't notice the eagle's head issue... anyway...


Shambler: I need feedback: go play the map and provide it please ;)


the silent: I'm glad you enjoyed the map, as regarding your first set of comments it was not obvious ;) the more about gameplay... Well, you maybe should try to play the map without the secrets, then it will be a different story, believe me... and for sure you ar not an average player, as you found the 14 secrets: good job !!

Overall, thanks everybody for the valuable feedback :D 

If I remember correctly, this happens if a brush model is so large that it spans >1 vis leaf. I'm not sure if it's a bug/limitation in qbsp or vis or the engines themselves (although I think DarkPlaces has a workaround). I don't know if there's anything a mapper can do to avoid it...

Probably with the fast vis, the map was divided into fewer vis leafs, so the lift ended up being contained within one area.

[Note that this is all theorizing based on vague memories, so don't hold me to it] 

No problem, at least you provided a possible explanation of the issue ;)

I however have a stupid question (maybe): why all these issues are visible in the fullvis version, and not in the fastvis version ? It is weird because as far as I understood the fullvis processing, it is much about face / volume rendering optimization... How can the process can generate such thing ?

PS: I will ask aguirRe in paralell BTW ;) 

As jdhack said, in the fastvis version the visleafs are bigger, thus the elevator/whatever problematic things are likely not spanning more than one leaf.

Pretty reasonable explanation if you ask me.

The solution would be to change the brushwork so fewer portals/leaves are created in the problematic areas, ie make it simpler, or smaller, or optimize vis blocking.

I think.

You simply hit the limits there. 

You cut it into two pieces - so if its a func wall you make it two separate func walls.

If its a vertical lift then maybe there's something else going on, since vertical spaces are ignored by the vis process.

I still haven't been able to play, but will. 

Smart. 

You don't know exactly where the vis leafs start and end (maybe some engine has the option to draw these) so you don't know where to cut your entity.

Basically the center point of your entity designates which vis leaf it's in, if you're stood in a visleaf that can't see the one that your entity is in then the engine doesn't draw it.

So the physical size of the thing doesn't matter, only dimensions of the vis leaf that it's center is in. 

The overlord of the Dark Places can be summoned with r_showportals 1. I guess those are the VIS leafes. 

No. It's r_drawportals and those are something different. Still fancy. 

Would be to consider on the elevator cage, and add rails on sides of the elevator pipe... removing the huge "cable" on top of the elevator cage...

Anyway: I got this reply from aguirRe:

"These symptoms are both caused by the same thing, namely that a fastvised map is not as accurate (or efficient) as a fullvised map. A fastvised map will typically force the engine to render more of the map and this has several implications.

The main thing is obviously that the map renders more slowly (high r_speeds in-game), but this will also hide portal problems, e.g. HOMs or flickering bmodels. That's why an unvised map can't have any portal-related HOMs or flickering bmodels (the latter being caused by them spanning too many leafs).

With the fullvised map, rendering will usually be much more efficient, meaning that the engine can now skip rendering of objects that are behind other objects. However, skipping rendering basically means that there will now be a HOM in that spot, but theoretically (and hopefully) hidden by an object in the foreground.

If something went wrong in the vis calculations (due to portal problems), the HOM won't be hidden and therefore you notice it. The same goes for the flickering func_train; in the fastvised version the entire train is always rendered, which is slower, but less error-prone.

So the basic idea is that if all vis calculations are correct, the fullvised map will look the same as the fastvised version, but will be much more efficient for the engine.

If it wasn't obvious back then, I actually feared that your CDA map would exhibit HOMs after the 1200+ hour run and you'd might face another huge run after that (ugh ...). You were lucky then and it came out well, but this time you weren't so lucky.

This is the main reason why I recommend aborting long fullvis runs; if there are portal problems in the result, you'll be facing another long run after trying to fix the issues. Cutting down to a more reasonable duration of a few days or even better a few hours, will reduce the frustration enormously.

Having huge fullvis times is just very impractical, since the whole build process is imperfect, mainly due to the floating point inaccuracies that are accumulated during the literally billions of calculations. There are most likely also algorithmic errors in the qbsp/vis programs.

In some cases, you might even consider releasing a map entirely unvised, if the fullvised version has many errors and the fastvis data is huge and still doesn't make much difference in rendering efficiency. Of course, it still sounds unprofessional to release a large, unvised map ... Part of the map mastery is to keep the map efficient and still visually complex and impressive.

While playing through a lot of Q2 maps, I've noticed many similar issues, here often caused by misconfigured "area-portals", i.e. doors that actually block vis when they're closed. Some maps are also released fastvised, which will make even a fast P4 hot and bothered. A lot of mappers have had these issues during the years ...
"

So the explanations provided by jdhack are correct ;)

Well, I'll try (I cannot promise :P ) to not make another monster like this in the future: it is too much deceiving at the end :( 

I guess I try and keep things on a 32x32 grid really.

Sometimes a 16x32, and occasionally less.

When doing some rocky terrain or uneven brushwork using the fabled "triangle techique" I also try and keep that on points of a 32x32 grid.

And small details are generally func_illusionaries, and any little details in the actual brushwork will be on as much of a larger grid as possible, trying to keep individual points on an 8x8 grid here and there, perhaps contained within a rectangular section.

This is because it has been explained to me that the qbsp process has to break the map up into vis-leaves (or leafs maybe) and more importantly clipnodes which are chunks of the physical hull(s) of the maps - so either way if you dont want to incur bugs (of which there are an awful lot) then its best to try and keep these as simple and easy to digest as possible.

"r_showtris 1" on the console in Fitzquake will show you the marksurfaces which to a degree will match some of the outlines of these leafs and clipnodes described above of the actual model (the core "map" as it were)

the portals are the double faces of two adjacent leafs. the visleafs are the spaces between the portals (and at the outskirts of the leafs the marksurfaces i guess)

I guess thats what the vis process does - find out which leafs can be seen from each leaf so as to exclude the unnecessary ones.

Keeping it simple and "on grid" as possible is probably the best way of avoiding such issues. Sometimes bugs in the qbsp output relate to the float issue - the idea of having points of the map on a hypohetical grid size of fractions rather than integers - and a warning may be shown in the qbsp log during the process but it doesn't cause any actual crashes so everything seems fine, even when fas-vised or not vised. But you cant tell what the behaviour will be like after a level 4 vis, when everything has been as optimised as possible.

None of this means you can't have scale though. You can make the brushes as big as you like :)

ramblings..... 

Bengt speaks wisely...

JPL, how about using a hub system, or chopping a big map into several smaller ones like you did with Five Rivers Land. So it feels like one big area, while in reality it's made from several pieces.

This would avoid the insanely long fullvis times (and each part wouldn't break any limits, either). There would be loading screens between parts though.

The problem with a hub approach is that you can't have one big coherent (outdoor) area like in CDA... 

go play it again! Steep cliffs. soe too. 

It has been proposed during beta testing, but unfortunately, the map interconnects are not really helpfull for a split tentative..

Five Rivers Land was more suitable, as more linear in its architecture... hence the easy split...

Well, I will try to not do monster map next time ;) 

clipnodes are affected by collisionable space - so if you have a load of stuff built on a small grid you'll have lots of clipnodes, even though nothing but a grenade or nail will be able to properly touch the detail.

If you want to keep the detail then the solution is metslime's skip tool - enclose all the stuff in a skip brush, meaning you can still see it fine but the processor doesn't waste time figuring out that a Shambler won't fit in there.

Whis is of course what you should do anyway with noclip brushes so that the player doesn't get stuck on geometry.

This is moving into guesswork but noclip affects hull's 1+2, so even just using that should reduce clipnodes.

Let's say you've got a complex corridor with lots of detail, but essentially it's a rectangle. Enclosing the walls ceiling and floor in four no clip brushes will reduce the clipnodes whilst leaving the thing exactly the same visually and without any irritating snags for monsters or player to get caught on.

Also Ricky, something I noticed in e4m1 - trigger brushes have their touch box set by their bounding box, not their brush. So if you have a diagonal trigger then its actually still just a rectangle. The same would apply to a circular trigger - it's still the square defined by the bounding box. 

Oh yeah, clip brushes can greatly cut down on your clip nodes. You need to experiment some but generally if you can wrap 3+ brushes in a clip brush, it's a net win in terms of clip nodes. 

It has been proposed during beta testing, but unfortunately, the map interconnects are not really helpfull for a split tentative..

Yeah, you would have to plan the map as a hub from the start. Just like Q2 maps. 

I'm pretty sure if you enclose surfaces in a skip brush, then the surfaces get clipped away by the compiler, because the BSP compiler itself doesn't know that skip is a special texture(the skip tool is run after BSP compilation). Although you can very carefully place skip brushes to simplify a surface's collision without actually colliding the faces behind, that's going to leave all the clipnodes and leafs in place. You may also have problems when you try to run vis on this.

Placing clip brushes does better, because they are disregarded by the compiler during the part of the build process concerned with visible faces. So that does get rid of clipnodes(usually). But because they are disregarded during the face generation process, they can't affect the number of leafs which are made by the visible faces.

The only way to reduce the number of leafs in the bsp, which are the convex spaces which are used for vis calculations, is to reduce the complexity of the geometry. This option does include offloading the complex geometry into a func_wall or func_illusionary and leaving simple geometry in the actual level to plug the hole. The advantages and disadvantages of this are well known. 

That's the main reason I'm trying out the BSP editor, especially when maps can get this big. It's amazing it all works out anyways. But like I mentioned (or if there are any floating point inaccuracies in the elevator brushes)check your elevator brushes. In the elevator's worldspawn position, if some of its brushes are out of the level, you got a leak and can expect the elevator to disappear. So just by stepping back those protruding bands in the elevator shaft (say by 4 units) you are assuring nothing is out of the level. If the elevator is okay though, eliminating the cable (or making it a separate entity) might do the trick.

This game can handle really big moving entities though. Even a 300 brush walk-in multi level section that is 1500L by 700W by 700H and is 1/5th of a level won't disappear.

Oh yea, don't cut this map up! It's best as it is.