Return to City 17

[DaMaN]

That leak is probably caused by a misplaced origin.

Thanks for the hint, i already thought about that, but there was nothing wrong with the origins.

A couple of the ladders like having their origins far outside the map for some reason. I just threw a skybox textured brush around them

I just found out what it was all about. It wasn't a misplaced orogin, but
just a small gap between two nodrw brushes. The pointfile was crap
because hammer tried to draw it starting from a func_useableladder.
I don't know why, but i found out that this doesn't work and the line gets
screwed. So i had another test compile woth only world geometry and
triggers enabled and got a corrct pointfile that enabled me to fix the leak.

Wow, must have been related to your 'optimization'. No leak on my version...

Glad you found it though! Those leaks can be annoying.

What makes me so curious is the fact the map is double the bsp size (102 mb)from what the 1.23 version (52 -53 mb)is and if you really didn't go 172% end_data, then I think your map bsp is like doubling or something?

Indeed, that is exactly why I'm so frustrated with this map. For some reason it goes double the size and won't run.

The ent_data never was a problem on this map. Others, yes, this one nope. But reduce the nodes if you want - that's a good idea. (BTW I mainly put them in for the headcrabs to chase you around. The ones on the beach and especially on the bridge are pretty useless - I tend to go a bit overboard when it comes to nodeing).

I'm not sure if it's the bsp... that would be a good test actually, to try running it under ep1 with just bsp then under OB with just bsp and comparing the two. Personally I'm betting it's something to do with vrad. It'll compile and run fine without vrad (IE full bsp and fast vis) but turn on rad and BOOM! Engine Hunk Overflow. Hmph.

Well, over the weekend (IE when I'm not at work) I'll see about doing some more test compiles. I've chopped up all the water into nice bite-sized pieces, so I'll see if that makes a difference (I doubt it). Next I'll try removing sections of the water to see just how much water it can take. (BTW, I tried it without any water and with fast rad - compiled and ran fine).

But yea. I'd really like to see this map re-released, so I can release the next few.

EDIT: ACK! Page 10!? I thought I'd have them all released by now...
I guess my software engineering teacher was right - the first 90% of a project takes the same time as the remaining 90% of the project. (And yes, that math is correct when speaking about a software project).

[fug4life]

Was your ent_data anywhere near a 100%?
Reason I say is some maps gain about 10% just switching to OB engine, entities have larger properties etc, etc.

But 172%? Blues you can do all the optimisation in the world, but that ent_data needs to be down at 150%.
But like I said I'd be more worried about the fact the bsp size is double what it once was. That suggests something is very wrong!

But yeah info_nodes are a good thing to cull, we all add too many at the start and start culling them

[Shana]

ent data doesnt need to be under 150%, only the total number of ents needs to be under 4096.

[Blues]

A couple of the ladders like having their origins far outside the map for some reason. I just threw a skybox textured brush around them

Wow, must have been related to your 'optimization'. No leak on my version...

Yeah the other one was caused, when i deleted your angular nodraw brushes and didn't fix up all gaps correctly

But now i have to admit that there really were some misplaced ladder origins, when i enabled them again via the vis-groups.
So you were right, theMoon.
I just deleted the ladders and made some new ones, then it worked.
but there is still the "too many light styles" issue. This may also increase the rad information and perhaps cause the engine hunk overflow.

[DaMaN]

Was your ent_data anywhere near a 100%?
Reason I say is some maps gain about 10% just switching to OB engine, entities have larger properties etc, etc.

But 172%? Blues you can do all the optimisation in the world, but that ent_data needs to be down at 150%.
But like I said I'd be more worried about the fact the bsp size is double what it once was. That suggests something is very wrong!

But yeah info_nodes are a good thing to cull, we all add too many at the start and start culling them

Not sure what the old one was up to. As W0rf0x said, it's only got to have less than howevermany entities. But 170% sounds about right.

And again, I've gotta agree with you here fug, the fact that the bsp size is double what it once was is indicative of something very wrong. (Anyone have any ideas? Guess it couldn't hurt to ask...)

But now i have to admit that there really were some misplaced ladder origins, when i enabled them again via the vis-groups.
So you were right, theMoon.
I just deleted the ladders and made some new ones, then it worked.
but there is still the "too many light styles" issue. This may also increase the rad information and perhaps cause the engine hunk overflow.

Yea, I'm still not sure where those "too many light styles" issues come from. Might increase rad info, I dunno.

[fug4life]

The last time I had too many light styles on a face, I had some geometry that wasn't very well built with the Vertex tool (func_detailed). And I had too many lights in the map, I would delete lights around where the badly built brushes are and always seemed to fix my trouble. But it restricted me from adding more lights which I know I can keep adding until my heart is content, what Is hould of done was rebuilt the brushes to be a bit more compile friendly, but i was lazy and deleted lights to fix error.

Here from Interlopers:

WARNING: Too many light styles on a face (x,y,z-coordinates)
Description:
There's a face with too many different light styles of light shining on it. (more than six). For every switchable light (that is: any light that is named or has a custom appearance) shining on a face, vrad.exe makes a new lightstyle. Basically, it calculates how the face looks like when: -light 1 is on and light 2 is off -light 1 is on and light 2 is on -light 1 is off and light 2 is off -light 1 is off and light 2 is on I'm sure you understand how 6 switchable lights make 2 ^ 6 lightstyles, and how this enormous amount of memory has to be saved somehow. and limited.

Solution:
To stop this error, remove lights, dont give the light names unless you need to, make sure certain lights dont shine on the face (max_shining distance or by blocking it with brushes) or simply dont use that much switchable lights. Dynamic lights are not used by vrad.exe thus dont count. Lights with the same names are counted as the same lights. Find the location of the error using the coordinates.

But for me I still belive it was the bad geometry casuing the problem.

[Blues]

No, I've already fixed that one yesterday, before i saw your post, fug.
I know what this is normally related to, but i didn't notice before that
there were green lights in the xen spawners, initially dark and only
activated when xen things spawn.

Those are causing that "too many light styles" thing, because for every
light that can be off or on in game you have to have two lightmaps for
each face that it casts light on.
If you have three of those lights, then you have to have lightmaps for
every combination of them being off or on.
Three is perhaps no problem (I didn't try it).
But if you have like four, five or I don't how many then you have a
problem.

Also if you have a light like the one at the generator that casts light into
the boat hut thing, you can't place three of those lights there anymore.


Well i just wanted to say that I disabled them by creating a new visgroup
and hiding it and that ficed the error.

Concerning the optimization i still got one bad fps spot outside. It's when
you're on the beach near the rocks where you have to meet the russian
looking in the direction of the base.
Then i have about 35 fps, running the game on highest graphics settings
with an 8800GTX.
I'll see how to fix that today.

Edit: OK, i got it up to 30 fps in wireframe mode and 45~50 in normal
view.

Just because some areaportals that could perhaps get the fps up some
more don't work...

Well, this is almost always a problem of wide outside areas... the
performance

[DaMaN]

So tell me, do you still get the "Engine hunk overflow" error? Because at this point that's at the top of my priorities. Though it's nice to get my map optimized for me! Thanks Blues!

BTW there are some areaportals that aren't working - don't know why. Try fiddling around with them - near the entrance of the underground complex. It might be what's upping the fps by Shaftoe's camp.

EDIT: Ahhh... the xen spawners... that'd do it. I had forgotten about those...
Since dynamic lights don't take up vvis info, might it be a good idea to change them to dynamic lights? Not sure if that would make the resultant lag too much.

[fug4life]

I would say just delete the lights for all spawners, I started to get in the habit of looking for lights like that when they come in prefabs, it still uses a sprite right? so thats ok.

Or, there is a 1.3 specific entity called env_teleport_effect. Which is nice and quick to use and I find it nowhere near as resource intensive as the xen prefab.

You can set options like #beams #width #sound to play and a few others.
In this picture I didn't change too much mostly scaling and I set a short lifetime.

[Blues]

well, i don't have the engine hunk overflow thing anymore, otherwise i coulldn't have said how many fps i have in that special spot.

But i think i have to re-add another 4 or 5 nodes because sometimes the guide walks in circles or returns to the previous node if you don't push it into the right direction...

Well, i already deleted many your areaportals and made new ones (just to keep the track) so i don't think it's yours that don't work

But i'll see what i can do with func_occluders

[DaMaN]

well, i don't have the engine hunk overflow thing anymore, otherwise i coulldn't have said how many fps i have in that special spot.

AAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!

What did you do to get rid of the engine hunk overflow!!! That's what I've been trying to do! Well, congrats, whatever you did...

But i think i have to re-add another 4 or 5 nodes because sometimes the guide walks in circles or returns to the previous node if you don't push it into the right direction...

Well, i already deleted many your areaportals and made new ones (just to keep the track) so i don't think it's yours that don't work

But i'll see what i can do with func_occluders

Occluders should do some stuff, i don't think i've done much with them in 01. And yea, I found that the guide needs quite a few nodes to walk around properly.

Let me know when you finish your optimizations, because I'd like to release the others again. (Unless you feel compelled to optimize the others as well

[Blues]

I think i fixed the engine hunk overflow thing by just deleting those unnecessary nodes.

Well, at least i think that's the last thing i did before the error disappeared.

[DaMaN]

I think i fixed the engine hunk overflow thing by just deleting those unnecessary nodes.

Well, at least i think that's the last thing i did before the error disappeared.

Huh... weird... guess orange box needs less ents...

[Blues]

By the way... did you ever consider adding HDR to those maps?
I think, if you don't make it too intense, then it'll really look good.

[DaMaN]

By the way... did you ever consider adding HDR to those maps?
I think, if you don't make it too intense, then it'll really look good.

I've considered it briefly, and I think i'd like to have it in there - it'd certainly look great! However, I don't have an HDR vid card in any of my machines, so I don't have a lot of motivation to do it