HLVIS.exe Needs to Close Created 16 years ago2007-08-31 12:00:33 UTC by StoneFrog

[quote]
** Executing...
** Command: Change Directory
** Parameters: "C:Program FilesSteamsteamappsstone_frogteam fortress classic"

** Executing...
** Command: C:PROGRA~1VALVEH~1HLCThlcsg.exe
** Parameters: "c:program filesvalve hammer editormapssfdoomsday" -nowadtextures -texdata 7000

hlcsg v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlcsg ---
Command line: C:PROGRA~1VALVEH~1HLCThlcsg.exe "c:program filesvalve hammer editormapssfdoomsday"-nowadtextures -texdata 7000
Entering c:program filesvalve hammer editormapssfdoomsday.map

Current hlcsg Settings
Name | Setting | Default
--------------------|-----------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 7168000 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ legacy ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ off ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]

Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]

12 brushes (totalling 76 sides) discarded from clipping hulls
CreateBrush:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (16.84 seconds)
SetModelCenters:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (0.00 seconds)
CSGBrush:
10%...20%...30%...40%...50%...60%...70%...80%...90%... (7.45 seconds)

Using Wadfile: program filesvalve hammer editorhlcthlarchivevalvehalflife.wad

• Contains 387 used textures, 92.81 percent of map (3116 textures in wad)

Using Wadfile: program filesvalve hammer editorhlcthlarchivevalvedecals.wad

• Contains 0 used textures, 0.00 percent of map (222 textures in wad)

Using Wadfile: program filesvalve hammer editorhlcthlarchivevalvexeno.wad

• Contains 14 used textures, 3.36 percent of map (264 textures in wad)

Using Wadfile: program filesvalve hammer editorhlcthlarchiveopfor.wad

• Contains 1 used texture, 0.24 percent of map (332 textures in wad)

Using Wadfile: program filesvalve hammer editorhlcttfcarchivetfctfc.wad

• Contains 1 used texture, 0.24 percent of map (279 textures in wad)

Using Wadfile: program filesvalve hammer editorhlcttfcarchivetfctfc2.wad

• Contains 3 used textures, 0.72 percent of map (395 textures in wad)

Using Wadfile: program filesvalve hammer editorcustomwallysf_skid.wad

• Contains 0 used textures, 0.00 percent of map (4 textures in wad)

Using Wadfile: program filesvalve hammer editorcustomwallysfdoomsday.wad

• Contains 9 used textures, 2.16 percent of map (9 textures in wad)

Including Wadfile: program filesvalve hammer editorhlctzhlt.wad

• Contains 1 used texture, 0.24 percent of map (8 textures in wad)

Using Wadfile: program filesvalve hammer editortreeofp.wad

• Contains 0 used textures, 0.00 percent of map (2 textures in wad)

Using Wadfile: program filesvalve hammer editorhlcthlarchivevalveliquids.wad

• Contains 1 used texture, 0.24 percent of map (32 textures in wad)

Using Wadfile: program filesvalve hammer editorcustomwallysfdis.wad

• Contains 0 used textures, 0.00 percent of map (5 textures in wad)

Using Wadfile: program filesvalve hammer editorcustomwallywb-dragoon.wad

• Contains 0 used textures, 0.00 percent of map (88 textures in wad)

Warning: More than 8 wadfiles are in use. (13)
This may be harmless, and if no strange side effects are occurring, then
it can safely be ignored. However, if your map starts exhibiting strange
or obscure errors, consider this as suspect.

added 95 additional animating textures.
Texture usage is at 5.09 mb (of 6.84 mb MAX)
27.02 seconds elapsed

--- END hlcsg ---

** Executing...
** Command: C:PROGRA~1VALVEH~1HLCThlbsp.exe
** Parameters: "c:program filesvalve hammer editormapssfdoomsday" -texdata 7000

hlbsp v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlbsp ---
Command line: C:PROGRA~1VALVEH~1HLCThlbsp.exe "c:program filesvalve hammer editormapssfdoomsday"-texdata 7000

Current hlbsp Settings
Name | Setting | Default
------------------|-----------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 7168000 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 8192)

SolidBSP [hull 0] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5447 (1.53 seconds)
BSP generation successful, writing portal file 'c:program filesvalve hammer editormapssfdoomsday.prt'
SolidBSP [hull 1] 500...1000...1500...2000...2500...3000...3500...4000...4500...4627 (0.83 seconds)
SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4035 (0.67 seconds)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5215 (1.09 seconds)
17.98 seconds elapsed

--- END hlbsp ---

** Executing...
** Command: C:PROGRA~1VALVEH~1HLCThlvis.exe
** Parameters: "c:program filesvalve hammer editormapssfdoomsday" -texdata 7000 -estimate

hlvis v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlvis ---
Command line: C:PROGRA~1VALVEH~1HLCThlvis.exe "c:program filesvalve hammer editormapssfdoomsday" -texdata 7000 -estimate
3188 portalleafs
11358 numportals[/quote]

After calculating the number of numportals, I get your standard "HLVis.exe has encountered a probelm and needs to close - Send Report/Don't Send" error message.

I haven't the slightest idea what is causing this. When I run fast VIS, this occurs randomly once in a while, though if I run my map, it seems as though VIS did run all the way. However I ran full VIS this time, and it appears as though it did not run all the way.

What can be causing this error?

Lack of memory maybe?

That just might be the case.

This is the largest map I've ever worked on (it's one of three in an escape map series). I'm almost done with this part, every new room or so I need to do some heavy editing to remove MAX_MAP_TEXTURES, so the map is getting ready to explode.

Could you upload the map file in the problem maps section?

If nobody else can come up with any possibilities, I may have to.

When I run fast VIS, sometimes I don't get the error. The same may apply for normal VIS - I'm not sure, as I haven't ran normal VIS since way before it started occuring!

I'm going to try anti-multitasking and see how it works out, memory-wise.

More then eight wads will break a map, trust me i've dealth with it myself.

For a while, restraining my wad usage to 8 wads worked fine.

Sadly however, I'm getting the error again!

So you don't actually have more than 8 WADs loaded into Hammer? That seems incredibly unlikely.

Try to compile without the -estimate-parameter.

Upload the map file, please. I got this error when hlvis stopped responding and fixed the problem.

I used to use a lot of WADs, if I recall, I used:
-halflife.wad
-liquids.wad
-decals.wad
-xeno.wad
-opfor.wad
-tfc.wad
-tfc2.wad
-zhlt.wad
...and about three custom WAD files I made (though only one applied to this map).

I removed liquids.wad, the WADs I weren't using for this map, opfor.wad (it was only using one texture in the map anyway). Something like that.

VIS goes byebye after calculating:

3188 portalleafs
11358 numportals

Did I exceed the limit for one of these values, maybe?

[u]UPDATE[/u]
I uploaded the map to the Map Vault.
Clicky.

Have you tried compiling it without the -estimate-parameter?

Yes I did. No improvement.

FFS...

Remove the giant box around your map, that box makes vis choke.

That worked, though now I need to put up with those @#()#$*$# leaks.

My map's pointfile never works (I load it in Hammer).

So find them manually.

If the pointfile do not work then you're doing something wrong.

It's actually pretty easy, load your map in Hammer, go "Map"-->"Load Pointfile" and load the .lin-file with the same name as your map. Then just follow the line and see where it goes outside your map, seal that place and do another compile, if you got more leaks just repeat the procedure. Also, to be able to see the pointfile in the camera-view(which makes it alot easier) you need to be using the VHE 3.5 BETA.

You've got a lot of bad habits going on in that map. There are several complex objects that are left as world brushes: pipes, barrels, carts, the helicopter, etc. This complicates the VIS process significantly. Make them entities - it prevents not only face splitting, but also volume splitting, because similar to faces, volumes can't be concave. And the more volumes, the longer VIS takes. I also see you carved out some pipes. This is risky and can lead to leaks (that may or may not be visible in Hammer). I suggest redoing them and manually shaping the brushes using the clip and vertex manipulation tool, or creating an arch and aligning the outside vertices so that it becomes square on the outside.

I would also highly recommend sticking to the grid, at least for the rough architecture. It prevents a lot of unnecessary problems, like tiny, 1-unit wide leaks. And personally I find larger brushes easier to work with, for example while aligning them.

Another note: is the map you uploaded a correct version? It looks like several brushes are missing - after taking out that skybox (which complicates the VIS process a lot too because everything between it and the levels outside is also processed), there are a lot of obvious leaks present. And the helicopter misses some brushes, too.

That is a correct version, though I do not note things such as missing helicopter brushes.

Note: One segment of the helicopter is breakable, complete with incorrect material and gib fields. This is just to get out of the chopper without having to wait for the monologue.

Killer-Duck: I know how to load a pointfile, but no line appears. Also, who doesn't use Hammer 3.5? Well, besides everyone who maps for Source?

Ah, my mistake. My approach to manual leak-hunting involves hiding all entities first, so the helicopter is probably just fine. However, you're probably overlooking several leaks since they're sealed off by entities, and these are ignored during the BSP process. Note that any entity outside the level will also generate a leak.

Somehow the pointfile is working now and I've already fixed a couple of leaks.

I have put more VIS optimization in newer areas than older. You may have noticed that classic "welded walls by means of the clipping tool" or more func_wall'd props in later areas (if you follow the map, the oldest areas are the above ground ones, and the newer ones are that second tram station, the tram tunnel itself, etc).

How can an entity seal off a leak, aside from, say, putting a func_breakable in front of one?

I have func_wall'd some props, though not any walls to the best of my knowledge, so the only other possibility for an entity sealing a leak would be like that.

GASP! Come to think of it, some lighting fixtures are func_walls and may be causing that. I must return to Hammer immediately! rushes to escape pod

Omg, you had a massive box arounf you map?

Anyways with the leak, but a massive, unhollowed box around your map, than compile. No leeks good. Slowly make the box smaller and smaller and it will uncover one or more leaks. Fix the leaks as you go, compileing.

Just remember to make the box smaller, slowly for a more accurate sign of where the leak is. If you suspect a leak is in an area, than use this method in that area only.

I've been doing some leak maintenance and have one problem:

How do I go about fixing hull 0? The process of elimination "put a block around a segment of your map and gradually make it smaller" technique doesn't seem to be capable of containing leaks in hull 0, and my pointfile, when I trace it (I trace it in-editor BTW), the red end of the line stops in mid-air, not flowing out of any wall or anything!

Leak in hull 0 is a normal leak. If you can't find the leak with the big block method than it is possible that you have a entity outside your level.

However I would say that your leak is in the level geometry. Put the block over the whole map in all three views covering everything and do the method again, you can also use more blocks, for example a block covering everyroom and try them out.

Just remember you can't have func_walls as part of your hull (the outer most layer of your map).

If you want, I can find the leak for you? Make sure that you upload the right map into the map vault.

I fixed hull 2 some time ago using the big block method. I tried that last night for hull 0 and it didn't pick up anything, though I may have missed a small segment or something.

If I am unable to find that nasty little bugger today, I'll upload my map into the Map Vault.

Don't download the old version I have, as I have done some leak fixes, among other things, since then. I'll post here when (and if) I put the up-to-date, leak-filled version.

It appears that the big block method can only find one leak at a time, as when I fixed hull 2 that way, it never found anything. Now it has found hull 1's problem. Perhaps that is the real reason they say the big block method is not for multiple leaks - not due to the immense amount of time needed, but somehow BSP and CSG work in ways that only one leak at a time can be found that way.

I have all day, I'll try to single out each leak until it finds hull 0's problem.