VVIS crashes after loading broken (?) po Created 10 years ago2014-05-18 08:15:49 UTC by Silvertongue

...rtal file. Broken portal file. Thanks, title character limit.

So I've been working on a CS:GO map for the last month or two and it's been coming along nicely, but today (following the addition of a new room) I've discovered that it no longer successfully compiles. There's nothing particularly remarkable about the room itself (and indeed, the compiler crashes regardless of whether it is cordoned off or not) but it seems to have nevertheless upset something.

What essentially happens: VBSP runs without generating any complaints (aside from some texture issues I can't be bothered fixing). VVIS successfully opens the portal file and starts loading the portals, but crashes on the line 'LoadPortals: reading portal XXX' (XXX is 966 when compiling the whole map, but varies if I cordon). Since I'm well below the portal limit, none of my brush geometry is too exotic and I've been strictly func_detailing, I'm understandably confused.

Incidentally, I navigated to the line in the portal file which contains the offending portal, and it appears as follows:

4 419 -1 (-736 260.940918 -10648 ) (-736 424 -10648 ) (-592 424 -10648 ) (-592 260.940918 -10648 )

The third digit, -1, seems to be the reason for the failure, as all other lines in the file have positive integers ranging from 0 to several hundred in its place. I'd like to find the portal in order to work out what's so funky about its circumstances, but I can't seem to work out how to do that in the Hammer editor.

Anybody know what might be the problem? I've included a pastebin of the portal file and the relevant compiler log.

http://pastebin.com/6RnzdFGT

Are you close to the limits on anything e.g.:

Object names Objects/Maxobjs Memory / Maxmem Fullness
---------- ------------- ------------- ------
models 3/1024 144/49152 ( 0.3%)
brushes 14/8192 168/98304 ( 0.2%)
brushsides 99/65536 792/524288 ( 0.2%)
planes 116/65536 2320/1310720 ( 0.2%)
vertexes 132/65536 1584/786432 ( 0.2%)
nodes 35/65536 1120/2097152 ( 0.1%)
texinfos 40/12288 2880/884736 ( 0.3%)
texdata 11/2048 352/65536 ( 0.5%)
dispinfos 0/0 0/0 ( 0.0%)
disp_verts 0/0 0/0 ( 0.0%)
disp_tris 0/0 0/0 ( 0.0%)
disp_multiblend 0/0 0/0 ( 0.0%)
disp_lmsamples 0/0 0/0 ( 0.0%)
faces 100/65536 5600/3670016 ( 0.2%)
hdr faces 100/65536 5600/3670016 ( 0.2%)
origfaces 58/65536 3248/3670016 ( 0.1%)
facebrushes 0/0 0/0 ( 0.0%)
et cetera..

or is that pastebin the entire compile log?

Maybe try covering the enitre area you just added with a solid brush, and see if it will compile.

If that doesn't work, go back to your lastest autosave or archived version that worked, and rebuild the new room.

Last resort if you can't sort it, feel free to post all or part of the vmf, and we can troubleshoot it

So I tried the 'solid brush' method and eventually worked out the suspect bit of geometry via trial and error. I'm still not sure what was wrong with it, but I've rebuilt it from scratch and now it works fine. Let's just put it down to me not being particularly safe with the Vertex Tool.

Sorry for bothering you with this.

(Also yeah, that was the entire log. Object list doesn't get printed until VRAD)

Let's just put it down to me not being particularly safe with the Vertex Tool.

^
Indeed! Hammer 4 enables much more extreme brushwork hijinks, but also allows for some crazy errors sometimes, even doing simple things like cloning a brush or a simple clip!

The good thing is these errors usually don't crush your whole compile, but it's always good practice to keep regular backups of your work and compile often(in case they do).

BTW forgot to ask, did you try Alt+P Check for Errors?(sometimes this tracks down the problem brush, sometimes not)

Anyhoo, glad you got it sorted

BTW forgot to ask, did you try Alt+P Check for Errors?(sometimes this tracks down the problem brush, sometimes not)

Hooo yes, I end up consulting that window a lot. Didn't turn anything up at the time though.