Compiling explanation...? (subject changed)

Nice, this forum breaks post if you edit it...

Message submitted 15 minutes after original post:
So

I tought to do a map for mod named Dystopia. Everything went fine exept it always errored from some spawn points are leaking (not info_playerstart) but it still worked. Now when I removed every entity from my map (no info_p... . creating brushes first) it errored that info_playerstart has leaked. I was just creating one totally separate room and when I looked it with noclip I noticed that other places are gone. Well, I compiled it again with the start entity in the bigger place. Then the leaked error comed. Why it was like this?
Or does map work if player leaked? (It was pitch-dark when tested

I started to block some areas and trying to see where exactly is the leak. But when i tried it second time it compiled the earlyer map (which wasent on my hard drive any more...). Tried it a second time. Didn't work. Again it was the erlyer map no matter what I did. I restarted the computer, opened hammer and loaded my map (again). Hammer showed the last saved map just like it should do. Then i deleted all temporary bsp files on that map. Compiled the map and then tried it with HL2 but it just isnt the map that i had in hammer. It is the early compiled map. Can somebody give some explanation on this? (Worst problem right now)

The compile log that this forum requires:

---

materialPath: c:\program files\valve\steam\SteamApps\SourceMods\dystopia\materials
Loading C:\Program Files\Valve\Steam\SteamApps\SourceMods\dystopia\maps\RMF\2.vmf
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...Brush 86394: WARNING, microbrush
Brush 86383: WARNING, microbrush
Brush 86353: WARNING, microbrush
6...7...8...9...10**** leaked ****
Entity dys_spawn (8491.59 6261.53 6412.00) leaked!

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9728.0, 8192.0, 8037.5)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 8265.4, 8930.2)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 8594.1, 8702.9)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 8240.2, 8142.4)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 8704.0, 9201.5)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 8600.0, 8172.7)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 9112.0, 8460.2)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (9216.0, 8704.0, 7077.4)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:

*** Suppressing further FindPortalSide errors.... ***
Processing areas...done (0)
Building Faces...done (0)
FixTjuncs...
Too many t-junctions to fix up!

1 threads
reading c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
reading c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.prt
LoadPortals: couldn't read c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.prt

Could not find lights.rad in lights.rad.
Trying VRAD BIN directory instead...
Warning: Couldn't open texlight file c:\program files\valve\steam\steamapps\dheath\sourcesdk\bin\lights.rad.
Loading c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
6 faces
1441 square feet [207528.00 square inches]
0 displacements
0 square feet [0.00 square inches]
6 patches before subdivision
314 patches after subdivision
0 direct lights
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10transfers 17872, max 127
transfer lists: 0.1 megs
0...1...2...3...4...5...6...7...8...9...10 Bounce #1 added RGB(0, 0, 0)
Build Patch/Sample Hash Table(s).....Done<0.0002 sec>
0...1...2...3...4...5...6...7...8...9...10FinalLightFace Done
Ready to Finish
0 of 0 (0% 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 1/1024 48/49152 ( 0.1%)
brushes 2128/8192 25536/98304 (26.0%)
brushsides 38960/65536 311680/524288 (59.4%)
planes 56092/65536 1121840/1310720 (85.6%) VERY FULL!
vertexes 31/65536 372/786432 ( 0.0%)
nodes 12/65536 384/2097152 ( 0.0%)
texinfos 12/12288 864/884736 ( 0.1%)
texdata 10/2048 320/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_lmsamples 0/0 0/0 ( 0.0%)
faces 6/65536 336/3670016 ( 0.0%)
origfaces 6/65536 336/3670016 ( 0.0%)
leaves 14/65536 448/2097152 ( 0.0%)
leaffaces 6/65536 12/131072 ( 0.0%)
leafbrushes 2262/65536 4524/131072 ( 3.5%)
areas 2/256 16/2048 ( 0.8%)
surfedges 48/512000 192/2048000 ( 0.0%)
edges 37/256000 148/1024000 ( 0.0%)
LDR worldlights 0/8192 0/720896 ( 0.0%)
HDR worldlights 0/8192 0/720896 ( 0.0%)
waterstrips 0/32768 0/327680 ( 0.0%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 0/65536 0/131072 ( 0.0%)
cubemapsamples 0/1024 0/16384 ( 0.0%)
overlays 0/512 0/180224 ( 0.0%)
LDR lightdata [variable] 4336/0 ( 0.0%)
HDR lightdata [variable] 0/0 ( 0.0%)
visdata [variable] 14/16777216 ( 0.0%)
entdata [variable] 287/393216 ( 0.1%)
LDR leaf ambient 14/65536 336/1572864 ( 0.0%)
HDR leaf ambient 0/65536 0/1572864 ( 0.0%)
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] 14863/0 ( 0.0%)

Win32 Specific Data:
physics [variable] 761811/4194304 (18.2%)

Total Win32 BSP file data space used: 2248705 bytes

Linux Specific Data:
physicssurface [variable] 761811/6291456 (12.1%)

Total Linux BSP file data space used: 2248705 bytes

Total triangle count: 12
Writing c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
1 second elapsed

---

From compiling logs:
"
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...Brush 86394: WARNING, microbrush
Brush 86383: WARNING, microbrush
Brush 86353: WARNING, microbrush
6...7...8...9...10
"
What this exactly means?

How can i go to coordinates like this: "(9216.0, 8704.0, 7077.4)"?

"
FindPortalSide: Couldn't find a good

I think you have some invaild brushes in there. Avoid carving whenever possible.

First, fix the leak. There's a part of your map that has a hole to the outside. In hammer, under the menus, go to load pointfile. You should see a red line in the 3d view. Follow this line until in goes outside the map. This will be the hole.

Remember that entities (including func_details) do not block the map from the outside.

You also have microbrushes. These are very bad, and are brushes that are less than 1 unit in size. Use the Go to brush... menu item and enter the the number of the microbrush (ie. 86383) then hit the delete key. Do this for both of them.

And try to compile again. Hope this helps, if you want me to take a look at the map for you, don't be afraid to send it to my email address, I'd be happy to take a look.

---

Dark_Kilauea
DVS Administration
http://www.dvstudio-production.com/

The:

...1...2...3...4...5...

Brush 86394: WARNING, microbrush

Brush 86383: WARNING, microbrush

Brush 86353: WARNING, microbrush

Is causing the leak, you need to fix thoes up FIRST before you do anything.

Ctr-Shift-G ----> then enter the number of the brush, delete it and
replace it with a larger brush. (cant have anything less than 1 unit in
size).

Recompile and your other problems will go away.

---

Posting And You

Just a note: deleting entities does not solve leaks (unless it's an entity outside the playable part of the map). The entities noted in the compile log are simply the ones closest to the leak, so use them as a reference point rather than removing them.

---

Create-ivity - a game development blog

Thanks!! That helped a lot! That was very helpful!
Most of the problems is succesfully removed. :smile:
Especially thanks for the leak finding tool.

There are still some things I would like to know:

---

.....
No such variable "$hdrbasetexture" for material "skybox/sky_day01_01rt" [*]
Can't load skybox file skybox/sky_day01_01 to build the default cubemap!
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 (1) (485235 bytes)
Emitting linux collision data (use -nolinuxdata to disable).
Building Physics collision data...
done (0) (485235 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 27 texinfos to 16
Reduced 10 texdatas to 8 (244 bytes to 186)
Writing C:\Program Files\Valve\Steam\SteamApps\SourceMods\dystopia\maps\RMF\2.bsp
8 seconds elapsed
Memory leak: mempool blocks left in memory: 1

** Executing...
** Command: "c:\program files\valve\steam\steamapps\dheath\sourcesdk\bin\vvis.exe"
** Parameters: -game "c:\program files\valve\steam\SteamApps\SourceMods\dystopia" "C:\Program Files\Valve\Steam\SteamApps\SourceMods\dystopia\maps\RMF\2"

Valve Software - vvis.exe (Jan 2 2006)
1 threads
reading c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
reading c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.prt
1152 portalclusters
3333 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (5)
PortalFlow: 0...1...2...3...4...5...6...7...8...9...10 (285) [**]
WARNING: Cluster portals saw into cluster
WARNING: Cluster portals saw into cluster
WARNING: Cluster portals saw into cluster
Optimized: 1713 visible clusters (0.00%)
Total clusters visible: 166888
Average clusters visible: 144
Building PAS...
Average clusters audible: 382
visdatasize:150385 compressed from 331776
writing c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
4 minutes, 50 seconds elapsed

** Executing...
** Command: "c:\program files\valve\steam\steamapps\dheath\sourcesdk\bin\vrad.exe"
** Parameters: -game "c:\program files\valve\steam\SteamApps\SourceMods\dystopia" "C:\Program Files\Valve\Steam\SteamApps\SourceMods\dystopia\maps\RMF\2"

Valve Software - vrad.exe SSE (Jan 16 2006)
----- Radiosity Simulator ----
1 threads
Could not find lights.rad in lights.rad. [***]
Trying VRAD BIN directory instead...
Warning: Couldn't open texlight file c:\program files\valve\steam\steamapps\dheath\sourcesdk\bin\lights.rad.
Loading c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
4408 faces
25 degenerate faces
93503 square feet [13464519.00 square inches]
0 displacements
0 square feet [0.00 square inches]
4383 patches before subdivision
19979 patches after subdivision
0 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9...10 (1)
BuildVisLeafs: 0...1...2...3...4...5...6...7...8...9...10 (11)
transfers 2202076, max 563
transfer lists: 16.8 megs
GatherLight: 0...1...2...3...4...5...6...7...8...9...10 (0)
Bounce #1 added RGB(0, 0, 0)
Build Patch/Sample Hash Table(s).....Done<0.0183 sec>
FinalLightFace: 0...1...2...3...4...5...6...7...8...9...10 (1)
FinalLightFace Done
Ready to Finish
0 of 0 (0% of) surface lights went in leaf ambient cubes.
ComputePerLeafAmbientLighting: 0...1...2...3...4...5...6...7...8...9...10

.....

Total triangle count: 13173 [****]
Writing c:\program files\valve\steam\steamapps\sourcemods\dystopia\maps\rmf\2.bsp
14 seconds elapsed

---

[*] Is this a problem?
[**] This phase takes lots of time. Why? What is it trying to do here?
[***] There are no lights but will this cause problems when i create them?
[****] Is this a bad thing?

Thanks for all the help. I really appreciate it!

The warning you get about your skybox missing an HDR base texture or whatever isn't an issue as far as I'm aware - it only matters if you are trying to use HDR (the fancy new lighting system Valve added to the source engine with DoD:S) in your level, which isn't something you should concern yourself with at this stage in your mapping career!

The VIS stage of the compile process splits up your map into sections, and figures out which sections can be seen from other sections. This means that when you are playing the game, it only needs to render certain sections rather than the whole lot, which vastly improves performance (and is why you should always run with full VIS). The amount of time it takes to do the necessary calculations varies from map to map. In order to make it go faster you can ensure you build your level efficiently, and keep small details (ones that don't really block visibility and don't contribute to the outer "hull" of the level) as func_detail entities. Having it take around 5 minutes isn't anything to worry about though - back in the HL1 days it wasn't that abnormal to have it take hours, and sometimes the really complex maps took a night or more!

When the RAD compile stage can't find lights.rad, it again isn't any sort of critical error. Lights.rad is a text file that is referenced for texture lighting, but while texture lighting was a common form of lighting in the HL1 engine, in the source engine it is generally preferrable to use light entities. This file being missing will make no difference to the lighting in the level if you are just using light/light_spot/light_dynamic entities anyway.

I've never really taken note of the sort of triangle numbers to expect, but 13000 odd sounds fine to me. This will vary massively dependant on your level.

---

[img]http://card.mygamercard.net/sig/Default/reno84.png[/img]
Designer @ Haiku Interactive | ReNo-vation.net

WARNING: Cluster portals saw into cluster
WARNING: Cluster portals saw into cluster
WARNING: Cluster portals saw into cluster

Are caused when there is a concave vis leaf that can see into its-self
(for a definition of a vis leaf see reno's explanation above).

Normaly these occur when you've ran vis on fast (NEVER EVER DO unless
its a test compile). Or when youve got some complex brush work that
should be turned into func_detail.

---

Posting And You

Like omegaslayer mentioned it
Normaly these occur when you've ran vis on fast (NEVER EVER DO unless its a test compile). Or when youve got some complex brush work that should be turned into func_detail.

How exactly I could find these brushes?

Is there any list where is (almost) all compiling things are explained? (that will answer, "what this and this means?" questions from compiling logs)

Is it possible to create trapezium/trapezoid that has smaller than 1x1 side? (so it is like 0.7x0.5x200)

By the way where could I find models that I could freely use in my map?

Like Dark_Kilauea mentioned it
And try to compile again. Hope this helps, if you want me to take a look at the map for you, don't be afraid to send it to my email address, I'd be happy to take a look.

I sort of like to keep things in secret. I think that it still looks terrible because all textures and entities are missing (= same work process texture everywhere). If I send something, I would like to send the same thing for all at the same time and "my" (=my friend's) server is broken right now (hardware). If someone wants to see it, I can send something... Brushes are like 60-70% complete. It is quite big.

But thank you for those helpful answers!

Try not to group too many questions together in the same thread please - the system we use here works best when we use a thread per question. Only group questions if they are obviously linked.

That said...

1. You find brushes that should be func_details simply by looking around. Its not really something there are definate rules or checklists for I'm afraid - its something you'll get better at identifying as you get more experience in level editing and a better understanding of the compile process. In general, any insignificant pieces of geometry - such as a handrail, or small pillar, or support beam - that aren't really blocking off the player's view of a significant amount of other geometry and aren't part of the exterior hull of the level, should be made into func_detail brushes.

2. Have a read through of the article below, and plenty of other stuff on that wiki, to get a better understanding...
http://developer.valvesoftware.com/wiki/Controlling_Geometry_Visibility_and_Compile_Times

3. No - you should never have any brushes with faces smaller than 1 unit in any dimension. In general while mapping you should use a much larger grid size. 8 or 16 units is good for the basic geometry, dropping lower when working on details. If you need intricately detailed objects in your level, the best plan is to model them in XSI/3Dsmax/Milkshape/Maya, and import them.

4. I don't know of any good model repositories I'm afraid :sad: We do have some models here, but there are only a few of them.
http://www.snarkpit.net/editing.php?page=files&game=HL2&type=models

Anyway, good luck. If you have any other questions, please post them in their own threads, thanks.

---

[img]http://card.mygamercard.net/sig/Default/reno84.png[/img]
Designer @ Haiku Interactive | ReNo-vation.net