Engine hunk overflow error Please help

  • If you're asking a question make sure to set the thread type to be a question!

sitood

L1: Registered
Jan 21, 2014
13
0
Hey guys,
I'm making a jump map for soldiers and its almost done.
Since yesterday tf2 started giving the engine hunk overflow error.
This is the second time i got this. (first time i solved it)
I've searched google many times but it didnt help a lot.

First i went to the compile log checker and it seems that i have a leak.
XJbpfHL.png

Sadly i cant find a leak anywere.

So after that, i tried to load the map pointfile.
2ErHpOq.png

It gave me a line that seems pretty useless.
xSsadZF.png

Because the line doesn't got trough anything.

After that i searched the location of the leak.
zAaG0Uk.png

And as result the 3d view screen send me to the top of the line even when there's nothing there.
8DE3Kp6.png


I really hope you guys can help me! :)
 

sitood

L1: Registered
Jan 21, 2014
13
0
Dammit, it happend again. A teleporter leaked this time.

Edit: i just selected the whole map and clicked on center origins.
i hope it works now.
 
Last edited:

sitood

L1: Registered
Jan 21, 2014
13
0
Yesh, the map finally works! but i got another problem now. The lights are not working. Everywhere is light.
08ABD9C684B23E9088E2959241B56C18037B20EC

And i couldn't find the solution on the internet.
 

henke37

aa
Sep 23, 2011
2,075
515
First of all, you did place lights in the first place right?
Second, you did fix all leaks right?
Thirdly, did you run vrad?
 

Seba

DR. BIG FUCKER, PHD
aa
Jun 9, 2009
2,364
2,728
I know I'm late as fuck but

>
SUzZt5K.png


>
DKqiHBD.png
 

Waffe

L5: Dapper Member
Dec 2, 2012
230
203
Can you paste the compile log? It usually will tell what the problem is
 

sitood

L1: Registered
Jan 21, 2014
13
0
Can you paste the compile log? It usually will tell what the problem is

Loading c:\users\gebruiker\desktop\tf2 stages\jump_home\jump_home_b1.bsp
21095 faces
4 degenerate faces
80740096 square feet [11626573824.00 square inches]
9 Displacements
188902 Square Feet [27201972.00 Square Inches]
21091 patches before subdivision
832619 patches after subdivision
2054 direct lights
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6.


materialPath: E:\Steam\SteamApps\common\Team Fortress 2\tf\materials
Loading C:\Users\Gebruiker\Desktop\tf2 stages\jump_home\jump_home_b1.vmf
Can't find surfaceprop asphalt for material REALWORLDTEXTURES/NEWER/1/ROAD_1_01, using default
Can't find surfaceprop asphalt for material REALWORLDTEXTURES/NEWER/1/ASPHALT_1_06, using default
Can't find surfaceprop Asphalt for material REALWORLDTEXTURES/NEWER/1/ASPHALT_1_07, using default
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
Patching WVT material: maps/jump_home_b1/dev/dev_blendmeasure_wvt_patch
Patching WVT material: maps/jump_home_b1/nature/blendrockgroundwallsnow_wvt_patch
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...
Merged 320 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing C:\Users\Gebruiker\Desktop\tf2 stages\jump_home\jump_home_b1.prt...Building visibility clusters...
done (1)
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
WARNING: node without a volume
Creating default LDR cubemaps for env_cubemap using skybox materials:
skybox/realsky1*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/realsky1*.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...
WARNING: Map using power 4 displacements, terrain physics cannot be compressed, map will need additional memory and CPU.
done (15) (1418014 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Water found with no water_lod_control entity, creating a default one.
Compacting texture/material tables...
Reduced 4411 texinfos to 2663
Reduced 218 texdatas to 190 (7591 bytes to 6187)
Writing C:\Users\Gebruiker\Desktop\tf2 stages\jump_home\jump_home_b1.bsp
28 seconds elapsed



2 threads
reading c:\users\gebruiker\desktop\tf2 stages\jump_home\jump_home_b1.bsp
reading c:\users\gebruiker\desktop\tf2 stages\jump_home\jump_home_b1.prt
3507 portalclusters
9614 numportals
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Optimized: 3211 visible clusters (0.56%)
Total clusters visible: 572368
Average clusters visible: 163
Building PAS...
Average clusters audible: 216
visdatasize:422282 compressed from 3086160
writing c:\users\gebruiker\desktop\tf2 stages\jump_home\jump_home_b1.bsp
49 minutes, 19 seconds elapsed



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

Loading c:\users\gebruiker\desktop\tf2 stages\jump_home\jump_home_b1.bsp
21095 faces
4 degenerate faces
80740096 square feet [11626573824.00 square inches]
9 Displacements
188902 Square Feet [27201972.00 Square Inches]
21091 patches before subdivision
833383 patches after subdivision
2054 direct lights
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6.

Thats it.
 

henke37

aa
Sep 23, 2011
2,075
515
Vrad crashed. Those progress lines always end at ten and there are nearly always more than two. And the ending statistics are missing.
 

Fish 2.0

L6: Sharp Member
Nov 22, 2012
324
262
If it is a successful compile it will tell you the runtime of the compile at the end of the log. I usually just look out for that so I know the map has compiled, however this method does not account for any leaks (maps usually compile with leaks).
 

re1wind

aa
Aug 12, 2009
644
588
49 minutes, 19 seconds elapsed

Ouch.

I think you may want to optimize the map a bit before attempting to compile again. that should be 49 seconds, not minutes. open the portal file (located under the open point file) and it will show you how the map is split up into visleafs. the more blue lines, the worse it is. A leak can cause this to happen without generating a point file or being caught by the vbsp compile.


WARNING: Map using power 4 displacements, terrain physics cannot be compressed, map will need additional memory and CPU.
I also suggest cutting your displacements up into 4 parts and setting them to power 3 instead of power 4. power 4 displacements are just asking to cause problems.
 

sitood

L1: Registered
Jan 21, 2014
13
0
Ouch.

I think you may want to optimize the map a bit before attempting to compile again. that should be 49 seconds, not minutes. open the portal file (located under the open point file) and it will show you how the map is split up into visleafs. the more blue lines, the worse it is. A leak can cause this to happen without generating a point file or being caught by the vbsp compile.


I also suggest cutting your displacements up into 4 parts and setting them to power 3 instead of power 4. power 4 displacements are just asking to cause problems.

Okay, i opened the portal file and i see lots of blue lines now.
ttx1.png

But i have no idea what i have to do with them. Also my pc is not that fast so the compile process is always over 5 minutes.

About the displacements, ill try to change the power to 3. thanks for the tip c:
 

henke37

aa
Sep 23, 2011
2,075
515
The blue lines indicate the visleaves. Vvis is responsible for computing which leaves are potentially visible from each other. Correct map design ensures that this is kept to a minimum, so that as little geometry as possible has to be rendered.

And "slow computer" is nonsense when it comes to the vvis time. You have way too many visleaves that can see each other if vvis takes a notable amount of time.

You will need to func_detail things that don't contribute in any meaningful way to visibility blocking. For example, that slightly raised floor in the screenshot.
 

sitood

L1: Registered
Jan 21, 2014
13
0
The blue lines indicate the visleaves. Vvis is responsible for computing which leaves are potentially visible from each other. Correct map design ensures that this is kept to a minimum, so that as little geometry as possible has to be rendered.

And "slow computer" is nonsense when it comes to the vvis time. You have way too many visleaves that can see each other if vvis takes a notable amount of time.

You will need to func_detail things that don't contribute in any meaningful way to visibility blocking. For example, that slightly raised floor in the screenshot.

Alright, ill try to make some brushes to func_detail.
Many thanks for this tip c: