Return to City 17

[fug4life]

Also I just checked and my water wasteland 002a beneath is the same as yours. I do not appear to have the water_coast 01 beneath or its main texture.

[Blues]

DaMaN, you can just change the *_beneath* material in the VMT and make it point to an existing one of another water texture

Problem solved

[DaMaN]

want one of us to have ago at compiling it for you? Or you think it wont make slightest bit of deifference?

Sure, if you're up for it. I'll pm you the .vmf, but like you said I doubt it'll make a difference. I think this problem is more engine-based than computer-based, but anybody is likely to have a faster/better computer than me, so hopefully it'll work.

Prehaps try chopping some of the water brushes up into smaller or go the opposite way and make merge them to be larger?, make sure they are well trimmed at the edges under those displacements, dont let them shoot off to map edges if not nessercary etc, etc.

That's what I was going to try next, though I'm not entirely sure if there should be a form or function to my chopping. Most of the water is already chopped so it doesn't go too far under displacements. One of my other maps wasn't compiling due to the size of my water blocks, so perhaps I'll try out a compile chopping all the water up into bite-sized pieces.

Also I just checked and my water wasteland 002a beneath is the same as yours. I do not appear to have the water_coast 01 beneath or its main texture.

Aha!! I'm not the only one missing this texture!! Weird huh? I'm not sure how to fix it either, though I'm going to try extracting the .vmt from source materials and putting it in the obsidiandev folder. Perhaps the "source materials 2007" gcf doesn't have the same stuff as the "source materials" gcf.

DaMaN, you can just change the *_beneath* material in the VMT and make it point to an existing one of another water texture

Problem solved

Haha, that would probably work. I've also suggested an alternate solution that i'm going to try out as well, but that's also a good idea. If re-extracting the texture doesn't work, I'll extract one that DOES work and I'll re-name it to the one that's missing!! Brilliant, Blue!

EDIT: Oops. Sorry BlueS

[Blues]

Brilliant, Blue!

My poor 's' always feels left out in these forums

It's Blues
Just wanted to remark this once, because many people only write Blue

[fug4life]

Where's detahy when I need him!!!

[Deathy]

Where's detahy when I need him!!!

Huh? Detahy is there when you need him (2pm to 11pm).

[DaMaN]

Figured I'd do a bit of an update:

- Still working on transferring all the maps over to the Orange Box engine.

- Still can't get oc_return_c17_01 to compile a non-crashing version. (Thanks for trying, fug!!) (It's weird, because 02, 03, 04, 05, 06a, 06b, 07, 08, and 09 all compile without crashing. That's right, lots of maps. Check out below for more info.)

- Still annoyed with Valve.


EDIT: One weird thing that's happened to me recently is that the source sdk orange box has changed things around so that any model that was previously transparent is now no longer transparent. For example, the scripted sequence entities, the info_nodes, and models with transparent parts (like some of the trees and tree cards) are no longer transparent! Ack! What happen? Did someone set up me the bomb (did valve screw up again)? If so, where do I get signal (fix it)? Are all my base belong to yous (is it stuck like this for ever)?



Normal stuff aside, here's what's actually new:

First off, I got a job! Yay!! I've got a co-operative education job for the summer doing online flash game development with what looks like a great company. Just got back from all-you-can-eat sushi with the company - yum! Should be a great experience!

Secondly, and what you guys probably want to hear more about: Maps. Lots of maps. Zomg lots of maps. Since I've been annoyed with valve/hammer/etc, and since I'm out of final exams (which I aced of course), I've done what I normally do to alleviate my annoyance: do more mapping! Yea, it's kind of odd to do more mapping when your mapping doesn't go well, but whatever.

Essentially what's happened is that I've put together oc_return_c17_06b, and it's almost done - just have to tweak some stuff and compile with lights, etc. (It's a much smaller map than most of the others - 06a and 06b were going to be in the same file, but 06a's structure got in the way so I had to split the maps (see, I split my maps up sometimes...)).

As I've said many times before, 01 won't compile properly with vrad, though it seems to be fine without vrad, which strikes me as complete lunacy. It makes me want to stick my tongue out and go "blublblublblublblubl" at my computer.

02 and 03 have gotten some updates. While I still have the game_texts doing the storyline, (unfortunately), the text now sticks around for a bit longer. Apparently I read too fast. 03 is now in need of info_bigmomma's because Orange Box bigmomma doesn't seem to want to run around without them.

04 and 05 are, to the best of my knowledge, release-ready. That is, as soon as I get around to compiling them again. 06a is very nearly release-ready; it needs only one more element: Music! I've got the tracks picked out, I just need to give them a test run.

06b, as I've said, is mostly done, but still in need of tweaking and stuff. (I'm not entirely happy with it right now - it feels like it's missing something, though it could be because it's like, 1/8th the size of the other maps... yea, well, I felt it was a necessary addition to the series).

I've also gone and updated 07 and 08, (again) (the very first beta maps from oh so long ago), still a bit to do with them (I've been thinking of adding some music to 08...)

09 needs some work, but all the main stuff is there. Just need the fancy window dressings.

10 I haven't started, but that's mainly because I'm saving it 'till last. Got some sweet stuff lined up for it though... sweet stuff... though at the rate Hammer is screwing up I'll have to start mapping it out to alleviate more annoyance...



By the numbers: (I never consider my maps 100% done, so think of 99% as close enough to 100% to release. IMO)
oc_return_c17_01: 98% (If the damn thing would compile it'd be 99%)
oc_return_c17_02: 99%
oc_return_c17_03: 99%
oc_return_c17_04: 98%
oc_return_c17_05: 98%
oc_return_c17_06a: 97%
oc_return_c17_06b: 80%
oc_return_c17_07: 90%
oc_return_c17_08: 95%
oc_return_c17_09: 70%
oc_return_c17_10: 50% (Geometry is done, that's about it)


Whew! Hopefully that'll get some people excited... I know I am... (Or would be, if 01 would compile)

My current plan is to re-release 01 through 03 and 04 through 06a sometime very very soon (possibly a beta first - we'll see) with 06b through to 08 soon after that, with the last two maps coming out whenever I finish 10. However, any release will have to wait until I can get 01 to compile without killing the engine...

*sigh*

I've already bemoaned it, but I think it's worth mentioning that a new engine update shouldn't break existing maps. It's a real hassle for the mappers involved. Thanks Valve...

[Blues]

I could also do some test compile for 01 and look for errors that i know if you like...

If I don't find any solution then i could still ask in the german mapping forums where i'm registered.
normally you can get help for most of the problems there.

[DaMaN]

I could also do some test compile for 01 and look for errors that i know if you like...

If I don't find any solution then i could still ask in the german mapping forums where i'm registered.
normally you can get help for most of the problems there.

Hehe, sure. I'll pm you the .vmf. I sometimes wish I could read german, 'cause it looks like they have a lot of good mapping forums in german. And Google Translate just doesn't do enough

[Blues]

I had some time today to look over the return_c17_01 VMF.
Seems you have screwed up a whole lot of Nodraw Brushes
outside so many of them have angular faces.
For vis blocking nodraw brushes behind displacements this is
of no use but it's annoying vvis.exe and so normally you wouldn't do it.
You should use normal cuboids with 90° angles instead.

Apparently you also didn't use func_detail in all cases wher it should be used.
especially for the angular tunnel ceilings in those mountains.
Same problem here: This screws up vvis.exe so it will take forever to
compile the map. (It's not very easy for vvis.exe to divide a map into
billions of vis leaves, because all the world geometry is skewed)

Oh and why are the hint brushes outdoors placed like this?
It seems pretty weird, because it looks as if you wanted to
cut your map into 8 parts, like a pizza.
i've just deleted the angular ones of them, tomorrow i'll think about
the other ones again. Now I think they should be deleted and then
you should reconsider where to place hint brushes.
I'll continue (kind of) optimizing tomorrow, i'll try to compile when i've
finished, but this may take some days, because i'm writing multiple tests
this week...

Good Night

[DaMaN]

I had some time today to look over the return_c17_01 VMF.
Seems you have screwed up a whole lot of Nodraw Brushes
outside so many of them have angular faces.
For vis blocking nodraw brushes behind displacements this is
of no use but it's annoying vvis.exe and so normally you wouldn't do it.
You should use normal cuboids with 90° angles instead.

Apparently you also didn't use func_detail in all cases wher it should be used.
especially for the angular tunnel ceilings in those mountains.
Same problem here: This screws up vvis.exe so it will take forever to
compile the map. (It's not very easy for vvis.exe to divide a map into
billions of vis leaves, because all the world geometry is skewed)

Nodraws behind displacements are primarily for blocking light and/or limiting the available space. Usually I find it helps for optimization, but I can see why regular cubeoids would work better. Also, I made this map over a year ago, so I don't remember all the stupid things I did (there's a lot).

Angular tunnel ceilings not being func_detailed -> laziness. Plus, doing all that work isn't going to help the performance of the map by a significant amount. I find laying out hint-brushes and compiling with fast-vis works out better than letting vvis lay everything out. But I could be wrong.

Oh and why are the hint brushes outdoors placed like this?
It seems pretty weird, because it looks as if you wanted to
cut your map into 8 parts, like a pizza.
i've just deleted the angular ones of them, tomorrow i'll think about
the other ones again. Now I think they should be deleted and then
you should reconsider where to place hint brushes.

The hint-brushes outdoors are for conjunction with the big hill in the middle of the "pizza" -> by placing them like that it prevents anything radially on the other side from being rendered. Probably not making a huge difference having/deleting them thanks to fog, but w/e.

Regardless about the un-optimizationionedness, it still compiled on ep1 sdk.

Anyways, I tried compiling it today without water, and presto! It worked. So it seems to me that there's something to do with the water that hl2 doesn't like.

I'll continue (kind of) optimizing tomorrow, i'll try to compile when i've
finished, but this may take some days, because i'm writing multiple tests
this week...

Good Night

Hehe, gotta love those tests

[Blues]

I managed to compile it today, when i finished the 'optimization'.
(Well, normally i'd have optimized in a different way, but then i'd have to
change most of the brushwork of the rebel base )

It took about 20 minutes (due to a leak there was apparently no vis information, as the log told me... loaded the point file and the lovely red
line started above the map in the void and ended there, too, so no idea
where the damn leak could be...) and i got a billion "too many light styles"
warnings (even for faces that are only lit by the light_environment)
Also hammer gave met a "VERY FULL" note for the entdata.

"OK, this should not be a problem" i thought... well, thought wrong, for
when i started the map, i got a nice "ENGINE ERROR! Engine hunk
overflow!" message


I think the ground node things also fill the entdata...
So what are those thousands of ground nodes for?
I don't think you need so many of them...
I'll just remove some and see how it'll work.

entdata [variable] 676868/393216 (172.1%) VERY FULL!

[TheMoon]

That leak is probably caused by a misplaced origin.

Select the whole map (or only "Brush Entities" via VisGroups), and turn helpers on, then you can see all the origins as white circles and check whether any of them is outside the map.

Many nodes are generally only needed at corners, doorways, places with many obstacles etc... for open huge spaces you can decrease their amount drastically while still maintaining a good navigation of your NPCs.

Good luck optimizing

[fug4life]

I found at 152-153 % My map would fail on map load with ED_Alloc: Max map edicts or what ever, I reduced to 150.8 and it compiles. so a 172% is probably what the hunk error is all about.

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?

[Blues]

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.

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.