that looks really different!
shot2 has great use of trim to highlight the structures and shot4 is impressive with it's melding of organic and inorganic.
the lighting is kind of bland though. not much contrast and very few shadows. with all the freestanding architecture, there should be some really dramatic shadows. 

I am not so sure about those flame textures though. Looks promising!!! 

it'll really depend on what it looks like animated i guess. 

Looks really nice, Orl. Please don't make it ridiculously hard. 

What others said: really nice ! Can't wait to play it... 

Also they give me an idea: Someone should make an "ikred" map... to go with the ikblue and ikwhite maps already out there. 

Nice one, cool shapes. The orange bricks fit well, too. I agree you might want to change the latern texture (why not use a flame mdl). Animated lavafall? 

Orl look's awesome :)

Hope release is soon, need to kick some ass on these babys! 

That looks really cool. Love the terrain design, the broken architecture, the curves, lanterns and most of the texturing. Not sure about the blue stuff.

One thing - the trim!! Make sure it looks like actual trim that goes down a bit onto the wall, not just like something painted on the top surface.

Also nice to see well lit, clearly visible shots :). 

This looks very good. 

gb: Difficulty levels will be supported, so it won't be ridiculously hard.

negke: I would use the regular flame model, but apparently I've already used too many of them (too many efrags) so I made the flame texture as a substitute. I'll try to make it more appealing though. And yes, the lava falls and waterfalls are animated. :)

Shambler: Blue stuff? What blue stuff? 

looks nice but please tell me that is fullbright lighting.

Also, is that a monster to vis, line of sight seems to be unbroken in those shots.

Architecture looks smashing though. 

But if the map exceeds various other limits, requires an enhanced engine anyway, which would take care of the efrags things, wouldn't it? Or do you think it's still possible to tweak it to fit into the standard protocol?
Depending on how many lamps there are and how many free edicts you still have, it probably could be done with info_notnull flames (=dynamic entities). Or a proper lantern texture - illuminated glas. One of the stock yellow-tinted window textures, for instance. 

The metal trim in the first shot. I take it back, it's not that bad. 

looks great, I like the flame texture, it's different but looks fine in the shots. Architecture looks great, a nice twist (uneven/broken/custom textures) on a Quakey theme. Looking forward to playing it. 

nitin: Lighting looks different in any map with a different engine, as well as what your gamma level is set to. I took those screenshots in glquake, and when they came out they were very dark so I manually brightened them. Chances are the lighting will look different with your setup, possibly darker.

Also, is that a monster to vis, line of sight seems to be unbroken in those shots.

I'm sorry, but I'm not sure I understand.

negke: Believe it or not, the map currently exceeds some of Quake's enhanced limits (clipnodes are sitting at 64k, marksurfaces at 70k, nodes at 35k etc) and efrags are currently above 2048, which is enhanced glquake's limit. There is no chance that this map will fit onto Quake's standard limits.

As for the lantern texture, I'll try to make it look a bit more respectable, but I can't guarantee :) 

If that's the case, then using the hack for displaying flame models would work out fine. It would take two entities for each lantern if you want every single one of them to emit that fire sound, too.

Lantern texture: To specify what I meant earlier - e.g. the yellow region in window02_1, or a modified version of window1_3 (or 1_4?), or possibly something like +0light01. At least those would be textures readily available without additional effort required. 

I like the rocks a lot.

Shame about the flame models - what engine are you running it in? 

negke: I had a look through the teaching progs dat new tricks thread, but I couldn't find the specific hack you are mentioning. Could you point me in the right direction, or re-post it?

ijed: enhanced glquake is what I was using. 

i think what negke was thinking of was the trick to get around the static entities limit. however, you mentioned efrags which is something else.

from aguirre's site:
"Too many efrags!"
This console warning is normally caused by having entities (typically torches) too close to or
even partly inside solid walls. Another possibility is too many (or too far apart) brushes that
are included in one brush entity. EFrags means Entity Fragments. Enhanced Win/GLQuake has higher
limits.

as you can see, the efrags problem is not directly related to the # of torches. check your func_ bmodels maybe. 

So it can probably be fixed by making the lantern cages into func_illusionary... 

How could making the laterns into func_illusionary help the efrags problem? I'm still not 100 percent certain what causes efrags in the first place. 

well, according to aguirre, it seems to me as though it has something to do with a bmodel being in more than one 'vis zone'. i don't fully understand all the bsp stuff, but when you vis a map, each volume separate 'area' which has faces assigned to it (ie: it can be visible or not such that it will or will not display faces attached to it) would be like a 'vis zone' and entities that have a bounding box (anything that has a visible model and isn't explicitly set to be a point entity via setsize() in qc can touch more than one of these zones. this means that the entity has to be attached to more than one zone and in a visually complex area that has been split up many times by vis, that entity could potentially be attached to quite a lot of these zones. these are entity fragments (efrags).
now if you have a big bmodel (say like a really tall elevator), it could be attached tons of zones and if you had more than one of these elevators (or equally larged doors, trains, etc) you can see that it may run over the limits.

but i'm honestly not even sure what i said above is right. :S bsp and vis are not transparent subjects. :P 

But I suspect that those small cages are causing complicated leafs. Efrags is related to 'solid walls' - that doesn't mean walls, just anything that's a world brush.

This is just an idea, but maybe the flame models were causing the bug because they were too close to fiddly world brushes. If they become entities then there's no more problem since they no longer define the vis tree but are commanded by it.

In other words, they become visible or not as vis says so, instead of causing the vis to be more complex.

On the other hand, necros could well be right... although I'm not so sure for two reasons. Firstly, you've already identified the lanterns as being the problem, for some reason. The second reason I'm just pulling out of the air and half-remembered conversations, but typically when you've got a large bmodel that's producing the efrags bug it's also subject to entity flicker (becomes visible/not) because it's residing in multiple leafs.

The lanterns are small... so I doubt that's the case. But I could be wrong. Those bars though are already producing multiple additional leafs though - the viz zones Necros mentions.

Either way, small brushwork tends to produce these types of problems and bump your compile time. It's a habit but I tend to avoid using such and go for alternatives. With a hack you could put the Nehahra lantern model in there instead. Not sure which hack though. 

Open the map up in Fitz or Quakespasm and use the command called r_showtris 1 (I think that's what its called) which will show you exactly what viz is allowing to be drawn.

If the lantern cages are creating the efrags problem then you'll see wierd effects there in comparison to the rest of the map.

Won't be easy to see though since they're small.

En fin. My advice, so you don't have to do too much work or a visual change, is to group the bars of each lantern into singular func_walls - func_illusionaries being slightly cheaper.

If it doesn't work at least it's a simple change to test, and should speed up compile anyway.