Has anyone else experienced VRAD crashing intermitently.

There doesn't seem to be any pattern to it but it is getting very annoying. I have tried uninstalling Steam and SDK and re-installing but it makes no difference. Have also tried Batch Compiler but same problem the whole computer just locks up.

It's not a fault with the map as it will complete a full compile on my mates computer and will sometimes complete on mine. It doesn't seem to be light related as earlier today the map compiled fine and i've not added or changed any lights since the last compile, just added a few props and this time it froze my computer.

Here is the log

materialPath: c:\program files\steam\steamapps\mike@topleyxxx.freeserve.co. uk\day of defeat source\dod\materials
Loading C:\Documents and Settings\Mikeyboy\Desktop\dods\mapsrc\lobby51.vmf
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...6...7...8...9...100...1... 2...3...4...5...6...7...8...9...10Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...done (0)
Merging details...done (1)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing C:\Documents and Settings\Mikeyboy\Desktop\dods\mapsrc\lobby51.prt. ..done (0)
Creating default cubemaps for env_cubemap using skybox materials:
skybox/sky_dod_01_hdr*.vmt
Run buildcubemaps in the engine to get the correct cube maps.

Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/sky_dod_01_hdr*.vmt
Run buildcubemaps in the engine to get the correct cube maps.

Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (0) (158450 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 302 texinfos to 156
Reduced 26 texdatas to 20 (836 bytes to 682)
Writing C:\Documents and Settings\Mikeyboy\Desktop\dods\mapsrc\lobby51.bsp
3 seconds elapsed



1 threads
reading c:\documents and settings\mikeyboy\desktop\dods\mapsrc\lobby51.bsp
reading c:\documents and settings\mikeyboy\desktop\dods\mapsrc\lobby51.prt
387 portalclusters
1207 numportals
0...1...2...3...4...5...6...7...8...9...100...1... 2...3...4...5...6...7...8...9...10Optimized: 159 visible clusters (0.00%)
Total clusters visible: 89062
Average clusters visible: 230
Building PAS...
Average clusters audible: 386
visdatasize:40351 compressed from 43344
writing c:\documents and settings\mikeyboy\desktop\dods\mapsrc\lobby51.bsp
51 seconds elapsed



[Reading texlights from 'lights.rad']
[39 texlights parsed from 'lights.rad']

Loading c:\documents and settings\mikeyboy\desktop\dods\mapsrc\lobby51.bsp
1720 faces
196547 square feet [28302848.00 square inches]
0 displacements
0 square feet [0.00 square inches]
1720 patches before subdivision
18350 patches after subdivision
19 direct lights
0...1...2...3...4...5...6...7...8...9...100...1... 2...3...4...5...6...7...8...9...10transfers 3428123, max 694
transfer lists: 26.2 megs
0...1...2...3...4...5...6...7...8...9...10 Bounce #1 added RGB(9352, 7641, 5015)
0...1...2...3...4...5...6...7...8...9...10 Bounce #2 added RGB(1716, 1255, 647)
0...1...2...3...4...5...6...7...8...9...10 Bounce #3 added RGB(414, 270, 111)
0...1...2...3...4...5...6...7...8...9...10 Bounce #4 added RGB(106, 61, 20)
0...1...2...3...4...5...6...7...8...9...10 Bounce #5 added RGB(29, 15, 4)
0...1...2...3...4...5...6...7...8...9...10 Bounce #6 added RGB(8, 4, 1)

does it really freeze? Have you left it sit for an hour or so? It might just lag at that spot for a bit

Try to compile a map that only has a hollowed out brush with a player entity, then you'll really know whether vrad is crashing or just taking a long time.

My VRAD sometimes appears to crash - even displaying the Windows error box. If I acknowledge the crash box, Hammer will crash. If I just leave it however, it carries on processing until it completes the job.

With me, I think it's just the strain that the Hammer, VRAD and Steam process put on my CPU.

Its buggy software, and frankly I don't know how valve ever completed a project with their own compile tools.

It's probably just a memory error. Try using Batch Compiler or Batch Files without Hammer running and see if it works that way. If it doesn't, something is happening on your rig that it doesn't like, and frankly I don't see reinstalling or refreshing the SDK content will do anything, but always try that, it certainly won't hurt.

-Try compiling a SDK example map and see if that works. If not, your having computer problems.

-Processor type/amount of RAM plz. Also note Vrad.exe will not work unless your processor has SSE support.

-Do you have mismatched RAM simms? I.E. a 256mb and a 512mb card?

-Does your RAM have stock clock speeds?

-Is your CPU overclocked?

Yes it freezes by that I mean my entire pc locks up, the mouse everything.

Can't think it would be my pc as i've been mapping for over 18 months and have currently finished more than 6 maps, alot of them far more complicated than this one and never had a problem.

Batch compiler does exactly the same thing locks my pc up, mouse everything, the only way to resolve it is to turn the power off :mad:

So do SDK example maps crash too? Do other maps work?

Please explain if NOTHING is working or only that map isn not working.. We need that information.

If nothing is working, my best guesses would be:

-Currupt SDK files

completely back your map files up to seperate location, ie partitions or a cd/dvd. DELETE your sdk, don't refresh it. Do an absolute clean install after its all off your hard drive. 'Delete local content' and mop it up by deleting remaining directories and files. Registry settings will remain though.

-Currupt OS Componet
(format HD, self explanitory. Reinstalling Windows MAY work, not a guarantee. If a format doesn't work than its probably Hardware.)

-Recent Windows update (this can happen)
When was the last time your pc updated itself? A recent windows update can seriously screw alot of 3rd party apps up. When was last time anything worked?

-RAM/Mother Board problems
Break out the wallet.

Not sure if SDK maps will compile or not so will try that when I get home from work.

It's been happening for about 7-10 days now and as I say some times it will compile and sometimes the same .vmf locks my pc up on the VRAD compile. Yesterday I took the .vmf and deleted all my lights and it compiled. I then added a light_enviroment and it compile fine, I then added one internal light and it failed and locked my pc up.

Will try one of the SDK example maps when I get home and one of my final release maps and see what happens.

Did you try compiling a simple map like I said before? :\

Going to try a simple map and one of the SDK example maps tonight together with one of my earlier maps that I know has no issues.

But it's not a case of VRAD taking a long time it locks my pc up. I've had it before where VRAD and VVIS appear to have crashed but are taking a long time due to poor optomisation etc but this is different. When it happens I can't even move the mouse the entire pc is frozen.

Will post back once i've tried the other maps.

Well after several hours of trying to compile different maps i'm still no nearer to coming to a hard and fast conclusion.

Some maps will compile others crash, some maps that I released up to a year ago crash others compile ok.

Thought I had narrowed it down to the fact that I still had SDK running whilst using batch compiler but then ruled that out when batch compiler crashed without sdk running.

The last version of my current map crashed my computer in batch compiler so I rebooted opened Hammer renamed the .vmf shut Hammer and sdk and it compiled in batch compiler.

Seems to be too intermitent to tie down the reason it is happening, unless anyone else has a bright idea :D