Map Crash w/o visible reason

Fender357

Newbie
Joined
Jul 7, 2003
Messages
1,704
Reaction score
0
I've been working on this map for a wile now and its gotten pretty big. The only major thing I had done before this started happening was that I coppied a large part of a building so that now I've got 2 of them. I thought that mabie I had too much stuff in the map after I did that, but I see some maps with a much bigger file size than mine (around 20mb) that are just fine. The crash comes when I try to open the map. There are no errors in Hammers check for problems thing exept for that stupid one you get from making breakable windows and one for my ladder that dosn't seem fixable and dosn't seem to do anything bad to the map anyway.

When I try to run my map I get this message.
http://img108.exs.cx/img108/482/ScrewUp.jpg

After looking at the compile notes these are the things that bug me, but I'm not sure what they exactly mean and what I can do about them.

#1 There are like a thousand Degenerate Triangles

#2 This bit right here with the parts that say VERY FULL... :|


Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 892/1024 42816/49152 (87.1%) VERY FULL!
brushes 6780/8192 81360/98304 (82.8%) VERY FULL!
brushsides 42748/65536 341984/524288 (65.2%)
planes 10210/65536 204200/1310720 (15.6%)
vertexes 53685/65536 644220/786432 (81.9%) VERY FULL!
nodes 10288/65536 329216/2097152 (15.7%)
texinfos 7458/12288 536976/884736 (60.7%)
texdata 285/2048 9120/65536 (13.9%)
dispinfos 33/0 5808/0 ( 0.0%)
disp_verts 9121/0 182420/0 ( 0.0%)
disp_tris 16128/0 32256/0 ( 0.0%)
disp_lmsamples 74062/0 74062/0 ( 0.0%)
faces 30385/65536 1701560/3670016 (46.4%)
origfaces 26857/65536 1503992/3670016 (41.0%)
leaves 11181/65536 626136/3670016 (17.1%)
leaffaces 34554/65536 69108/131072 (52.7%)
leafbrushes 9575/65536 19150/131072 (14.6%)
surfedges 248096/512000 992384/2048000 (48.5%)
edges 152636/256000 610544/1024000 (59.6%)
worldlights 94/8192 8272/720896 ( 1.1%)
waterstrips 1630/32768 16300/327680 ( 5.0%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 37767/65536 75534/131072 (57.6%)
cubemapsamples 32/1024 512/16384 ( 3.1%)
overlays 0/512 0/180224 ( 0.0%)
lightdata [variable] 3556756/0 ( 0.0%)
visdata [variable] 0/16777216 ( 0.0%)
entdata [variable] 470907/393216 (119.8%) VERY FULL!
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/1564 ( 0.1%)
dtl prp lght [variable] 1/4 (25.0%)
static props [variable] 1/16220 ( 0.0%)
pakfile [variable] 377024/0 ( 0.0%)

Win32 Specific Data:
physics [variable] 3704077/4194304 (88.3%) VERY FULL!
==== Total Win32 BSP file data space used: 16216697 bytes ====

Linux Specific Data:
physicssurface [variable] 6107377/6291456 (97.1%) VERY FULL!
==== Total Linux BSP file data space used: 18619997 bytes ====

Total triangle count: 79671
Writing d:\games\steam 2.0\steamapps\[email protected]\half-life 2 deathmatch\hl2mp\notdonemap\TheGalleryDisplace.bsp
19 minutes, 0 seconds elapsed

** Executing...
** Command: Copy File
** Parameters: "D:\Games\Steam 2.0\SteamApps\[email protected]\half-life 2 deathmatch\hl2mp\notdonemap\TheGalleryDisplace.bsp" "d:\games\steam 2.0\steamapps\[email protected]\half-life 2 deathmatch\hl2mp\maps\TheGalleryDisplace.bsp"


So...........whats my problem? Mabie all the displacement maps I have? Or could it be because of the wood railing I made a whole bunch of. I have a ton of stuff, mostly the small things, set as funk_detail. I don't know how much that helps with ..stuff.....
 
the compile log says it all. you just have too much stuff. 119.8% entdata alone could be the problem.
 
Ok thats what I thought..... is there any way to condence complex stuff to get it seen as just one chunk of stuff? Or am I just kinda screwed if I want to keep going on with my level the way I've got it?

Seeing as how I have a whole bunch of stuff like this http://img101.exs.cx/img101/1986/thegallery0064.jpg now.


(and I'm guessing that making things funk_detail dosn't help at all when it comes to having too many entities in the map? )
 
no a func_detail wont help if too many entities is the problem - if you can you will either have to convert entity brushes to world brushes or just delete some unnessecary entities and try to do the same thing in a different way - maybe models...
 
The fence looks like it repeats, so you could get the sizes and model it in a 3d prog. If it doesn't fit somewhere you could finish it off with brushes.
 
I'm betting the fence is a hundred different func_breakables so you can shoot it apart piece by piece. You may need to convert some of your geometry to models. However some errors consume massive amounts of resources cause they screw up the map. Figure out the degerative triangle cause and elimainte them. Your map will compile faster, run faster, be smaller and may actually not be anywhere near full *IF* you fix the obvious errors the compile is complaining about.

My experience says that EVERY warning and error in the compile log is there for a reason, and needs to be eventually eliminated.
 
I get this exact same error when trying to run my CSS map:
It compiles "Fine", and then I run it gives this memory read error. I have gone through the logs, and the only two errors I find are "***leaked***", and " 0 . . . 1 Brush 17084: WARNING, microbrush". If anyone can tell me how to get it working, please do - I'm tearing my hair out.

I can also post my whole log file if anyone needs it.
 
dekstar said:
"***leaked***"

Hate to break it to you, but if you have a leak, you aren't compiling anything. Leaks are fatal errors. VIS and RAD won't work and the map won't ever run.

Also VVIS and VRAD should show other errors were they comlain about not finding files (*.prt), so you may not be looking all too closely at your log.

Use LOAD POINTFILE in Hammer to bring up the leak-Tracing-line.
 
Ok, sort of new question. I took out all of the extreme detail of the wooden railing. Picofit
And yes, I did at first have some of the planks breakable (not all of them, just some) But then I figured I shouldn't do that with all of them and I kept it just to the areas that are most likely to get shot at, and made the rest funk_detail.

Ok, so I did that... replaced the over abundant brushes with the metal railing prop (i only put in 2, just to test how it looks) and when I tryed compileing it...well... I think it would have taken about a day to finnish. But it didn't finnish because my computer died out like its been doing lately. The whole time it was on VVIS too.
So yeah..whats up with that?
 
RoyalEF said:
Hate to break it to you, but if you have a leak, you aren't compiling anything. Leaks are fatal errors. VIS and RAD won't work and the map won't ever run.

Also VVIS and VRAD should show other errors were they comlain about not finding files (*.prt), so you may not be looking all too closely at your log.

Use LOAD POINTFILE in Hammer to bring up the leak-Tracing-line.
And then what should I do? How do I sort these leaks out exactly?

EDIT: Also, My map doesn't have the file that the LOAD POINTFILE thing loads... How do I create one?
 
DO you understand what a leak is or the concept? There are many tutorials on this and contless threads. This hasn't changed--it is exactly the same as HL1.

TIPS:

Compiling it (with just BSP) should generate a pointfile-when it says LEAKED. You then use LOAD POINTFILE. You then follow the red line in the 3D view until it enters your map--viola, LEAK#1. Fix and compile to find more leaks.

If Hammer says no pointfile exists then it normally means you have an entity outside the map. It can also mean your map is so swisscheesed full of holes that BSP couldn't figure out which part was inside the map and which part was outside. In the latter case closing up a few obvious holes will improve things and possibly get to a pointfile.

If you have an entity embedded in a func_detail this has caused a leak failure on some of my compiles. A series of columns were turned into a singl func_detail. A env_glow was in between the columns. that killed BSP.

Hammer now has the AUTO VISGROUPs. VISGROUPS are filters. If your VISGROUP window is blank, hit the EDIT then close or click SHOW twice. It is just a bug that is doesn't show up sometimes. Anyway, UNCHECK the AUTO box. This will remove all ENTITIES from Hammer's view. Now you are looking at just WORLD brushes. THESE MUST MAKE A SOLID HOLLOW MAP. There cannot be any holes to the outside, black void. Getting rid of the entities will help to see possible holes. Some people make outer walls part of entities and there make leaks.

Hopefully that helps, but if not just search for LEAK, there is tons of stuff out there.
 
RoyalEF said:
DO you understand what a leak is or the concept? There are many tutorials on this and contless threads. This hasn't changed--it is exactly the same as HL1.

TIPS:

Compiling it (with just BSP) should generate a pointfile-when it says LEAKED. You then use LOAD POINTFILE. You then follow the red line in the 3D view until it enters your map--viola, LEAK#1. Fix and compile to find more leaks.

If Hammer says no pointfile exists then it normally means you have an entity outside the map. It can also mean your map is so swisscheesed full of holes that BSP couldn't figure out which part was inside the map and which part was outside. In the latter case closing up a few obvious holes will improve things and possibly get to a pointfile.

If you have an entity embedded in a func_detail this has caused a leak failure on some of my compiles. A series of columns were turned into a singl func_detail. A env_glow was in between the columns. that killed BSP.

Hammer now has the AUTO VISGROUPs. VISGROUPS are filters. If your VISGROUP window is blank, hit the EDIT then close or click SHOW twice. It is just a bug that is doesn't show up sometimes. Anyway, UNCHECK the AUTO box. This will remove all ENTITIES from Hammer's view. Now you are looking at just WORLD brushes. THESE MUST MAKE A SOLID HOLLOW MAP. There cannot be any holes to the outside, black void. Getting rid of the entities will help to see possible holes. Some people make outer walls part of entities and there make leaks.

Hopefully that helps, but if not just search for LEAK, there is tons of stuff out there.

Good post. Very good actually. Kudos.

But... You don't have to close your map if you're planning on adding a skybox (!).
 
As to the first one it seems like you might have a bunch of duplicate geometry hiding somewhere like you copied something and forgot to move it then copied both things over and over again, possibly something tied to an entity. You might try running the compile without rad or vis and see if you can still open your map.
 
Cunbelin said:
As to the first one it seems like you might have a bunch of duplicate geometry hiding somewhere like you copied something and forgot to move it then copied both things over and over again, possibly something tied to an entity. You might try running the compile without rad or vis and see if you can still open your map.

No...that was just an example of what I had started doing. That one section of railing I had in the picture I had made about 10 times over. That obviously killed it.
I also just figured that it might take longer to get my map going because I have added alot to the map, but its compile time might have been shorter before because of the errors.

I doubt that I copied and pasted anything in the same place, I don't use copy and paste, I just use SHIFT and drag. It makes things easier when you'r trying to keep something paralell with something else.

But I like the info I'm getting from you guys. Great stuff to know that would take quite a wile to learn on your own. Do any of you remember what button combo brings up that little display that lets you type in the quardinants of stuff to see exactly where it is? I've done it before when the compile log has said something about a specific quardinant and I just typed it in and saw exactly what it was talking about.
 
Back
Top