ARGH!! 2 BAD problems - help please!!!

[sabre0001]

2 probs and following is the compile log...Firstly it says about MAX_MAP_PLANES -> I deleted the brush but i dunno if that worked or not...What should i do

It also says later that it cant read the .prt file - this means that any changes i actually make to my map dont take effect - even after compiling and copying the file...this is very annoying because as you can see, the compile time is huge. Anything i can do about this, other than restart from last back-up point??? I really would like to avoid having to do that.

Thanks for any help.Here is compile log...

materialPath: C:\Program Files\Valve\Steam\SteamApps\+++\half-life 2 deathmatch\hl2\materials
Loading C:\Program Files\Valve\Steam\SteamApps\+++\sourcesdk\hl2mp_sample_content\maps\cockpit.vmf
Brush 83278: MAX_MAP_PLANES
Side 5
Texture: LIGHTS/WHITE002



1 threads
reading c:\program files\valve\steam\steamapps\+++\sourcesdk\hl2mp_sample_content\maps\cockpit.bsp
reading c:\program files\valve\steam\steamapps\+++\sourcesdk\hl2mp_sample_content\maps\cockpit.prt
LoadPortals: couldn't read c:\program files\valve\steam\steamapps\+++\sourcesdk\hl2mp_sample_content\maps\cockpit.prt



Could not find lights.rad in lights.rad.
Trying VRAD BIN directory instead...
[Reading texlights from 'c:\program files\valve\steam\steamapps\+++\sourcesdk\bin\lights.rad']
[45 texlights parsed from 'c:\program files\valve\steam\steamapps\+++\sourcesdk\bin\lights.rad']

Loading c:\program files\valve\steam\steamapps\+++\sourcesdk\hl2mp_sample_content\maps\cockpit.bsp
5524 faces
3 degenerate faces
115155 square feet [16582461.00 square inches]
0 displacements
0 square feet [0.00 square inches]
5521 patches before subdivision
zero area child patch
18711 patches after subdivision
3937 direct lights
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 transfers 888909, max 250
transfer lists: 6.8 megs
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #1 added RGB(49421, 51564, 29656)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #2 added RGB(12130, 10092, 3479)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #3 added RGB(5574, 4047, 759)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #4 added RGB(2188, 1357, 152)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #5 added RGB(1060, 571, 35)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #6 added RGB(468, 219, 8)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #7 added RGB(229, 93, 2)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #8 added RGB(107, 38, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #9 added RGB(52, 16, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #10 added RGB(25, 7, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #11 added RGB(12, 3, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #12 added RGB(6, 1, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #13 added RGB(3, 1, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #14 added RGB(1, 0, 0)
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 Bounce #15 added RGB(1, 0, 0)
Build Patch/Sample Hash Table(s)..... Done<0.0263 sec>
0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 FinalLightFace Done
Ready to Finish
3933 of 3933 (100% of) surface lights went in leaf ambient cubes.
ComputePerLeafAmbientLighting: 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 2/1024 96/49152 ( 0.2%)
brushes 1185/8192 14220/98304 (14.5%)
brushsides 20116/65536 160928/524288 (30.7%)
planes 26786/65536 535720/1310720 (40.9%)
vertexes 7176/65536 86112/786432 (10.9%)
nodes 1203/65536 38496/2097152 ( 1.8%)
texinfos 729/12288 52488/884736 ( 5.9%)
texdata 14/2048 448/65536 ( 0.7%)
dispinfos 0/0 0/0 ( 0.0%)
disp_verts 0/0 0/0 ( 0.0%)
disp_tris 0/0 0/0 ( 0.0%)
disp_lmsamples 0/0 0/0 ( 0.0%)
faces 5524/65536 309344/3670016 ( 8.4%)
origfaces 4603/65536 257768/3670016 ( 7.0%)
leaves 1206/65536 67536/3670016 ( 1.8%)
leaffaces 5896/65536 11792/131072 ( 9.0%)
leafbrushes 1767/65536 3534/131072 ( 2.7%)
surfedges 40629/512000 162516/2048000 ( 7.9%)
edges 21345/256000 85380/1024000 ( 8.3%)
worldlights 3937/8192 346456/720896 (48.1%)
waterstrips 299/32768 2990/327680 ( 0.9%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 4491/65536 8982/131072 ( 6.9%)
cubemapsamples 0/1024 0/16384 ( 0.0%)
overlays 0/512 0/180224 ( 0.0%)
lightdata [variable] 702920/0 ( 0.0%)
visdata [variable] 129563/16777216 ( 0.8%)
entdata [variable] 1506/393216 ( 0.4%)
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/12 ( 8.3%)
static props [variable] 1/12 ( 8.3%)
pakfile [variable] 20193/0 ( 0.0%)

Win32 Specific Data:
physics [variable] 394683/4194304 ( 9.4%)
==== Total Win32 BSP file data space used: 3393673 bytes ====

Linux Specific Data:
physicssurface [variable] 0/6291456 ( 0.0%)
==== Total Linux BSP file data space used: 2998990 bytes ====

Total triangle count: 12107
Writing c:\program files\valve\steam\steamapps\+++\sourcesdk\hl2mp_sample_content\maps\cockpit.bsp
4 hours, 52 minutes, 0 seconds elapsed

 

[sabre0001]

Sorry for the bump but i really need this sorted, its a weird problem thats annoying me and i would like to either sort it or get working on this piece again (soon)...Its all niggly details that i had fixed in this (lost?) version so it would be handy to have it again...

Would it work if i loaded up a New map and just copied the whole level over? i would like to know before i try because of the 5hr! compile time

 

[Morgue]

It also says later that it cant read the .prt file - this means that any changes i actually make to my map dont take effect - even after compiling and copying the file...this is very annoying because as you can see, the compile time is huge.

Crikey, 5 hours? How fast is your computer, or is it just a huge map?

Anyway, I've had this happen before where no changes will register. From what I remember, all I had to do was hit 'Check for Problems', I manually fixed almost all of what I saw, and it worked the next time I compiled. Make sure there are no leaks as well (and judging by the compile log you posted there are none). Your problem may be a bit more complicated because of the .prt problem, but it's worth a shot.

 

[omnix32]

max_map_planes

max_map_planes (Qauke III engine) means that you have to many brush faces or two many rotating objects in your map.

in other words you exceeded the brush face limit of the source engine.

this is what would cause the error in Quake III related engine.

So, the new source engine can handle very large maps and it would be hard to reach this limit unless you used the carve tool (ALOT) in which case I would just start over and never use CSG again as it's a very noob and sloppy way to map.

this is what max_map_planes means for quake and Half-life1. I am sure the error has not changed just higher limits with the source engine.

 

[sabre0001]

the map is fairly detailed - the time doesnt bother me too much cos i just leave it overnight (a fire hazard just waiting to happen really) - i can sort that with hint brushes (ive heard) and entity brushes...

Check for problems doesnt work either - no problems found
Wish it was just something like that, i could manage that...

 

[sabre0001]

dont worry omnix32 - its just a lot of brushes, dont like the carve tool - would deleting more brushes help solve problems - my missing pointfile being the major one and also the lack of any changes between any compiles i do now and one i did a long time ago...

 

[sabre0001]

Thanks all, got it sorted just by deleting brushes and converting some to func_details, compile time nearly cut in half too...

 

[Mr Neutron]

yeah, definitely start converting a bunch to func_detail. Still, func_detail geometry is still not as cheap as static_prop's, so make sure anything particularly complex gets done that way, expecially if you have several instances of it.

I'm not sure that 5 hours is necessarily an outrageous compile time; if I understand it correctly, the hl2 sp maps took quite a long time--except Valve compiled their maps on some sort of distributed setup. Anyone see any guidelines from Valve about typical compile times?

 

[omnix32]

Awsome!!!

I am glad you got things working by deleting brushes not really needed and turning some to func_detail.

I know how it feels to lose a good map by simply not keeping the engine limits in mind. I have been mapping since Doom. (original doom on my 486 100)

you must have spent alot of time on this map to reach the source limit.

keep in mind a few things:
new mappers want to add lots of detail. like brushes for bottom paneling on walls and making every little detail possible.

the sad truth is that most people that play your map wont even really notice this extra hard work or soon forget it in the heat of the battle. We map because we like to create and make worlds.
players play because they want action and compititon with a well thought out map design.

most maps have become great only because of level design and game flow.

Item placement will decide where the heat of the battle is going to occure. Players like rocket launchers, and high powered weapons.
so, you may think that players will fight in one area of you map when in reality the battle normaly occurs around these weapons.

in multiplayer mapping try to keep those dead end rooms to a limit and make sure that there are no out of the way places. If you want to create worlds then map in single_player.

use texture and lighting to your advantage, the right combination of textures and lighting can really be enough to make the map look good. Like I said all that extra detail is normally ignored as players don't seem to care or understand all those hours you spent putting it there. game flow is the most important and often overlooked.

look at the maps that servers are running. Most the ones I have played that use custom maps are horrible looking as a map but are fun because they have a good flow and theme.

fun mapping.

 

[sabre0001]

thanks for the pointers^^

yeah too much detail was the straw that broke the camels back...the map basically looks the same now too and still gets what i had visioned

So im happy now and i didnt have to resort to drastic measures...From now on though im keeping about 5 backups...just in case...