[BUG] Teleporters Don't Work When Inside SOLID Func_LODs or Func_Brushes

phi

aa
Nov 6, 2011
832
1,815
So there's been an issue that was plaguing me for a while on cp_sunshine: the fact that, in certain spots, a teleporter exit placed would be destroyed when attempted to teleport to. Examples of this occuring in these spots are demonstrated in this video, and these two consecutive images:

2015-06-18_00007.jpg

2015-06-18_00008.jpg


As it turns out, after extensive debugging, I found the problem was in fact NOT with the props (as it sometimes can be), but by the large and daunting func_lod brush that spans this entire indoors area:

Screenshot%202015-06-18%2023.50.36.png


This brush entity has what is called a "bounding box" - an invisible area in a cuboid shape, as seen below from the top view in Hammer: (keep in mind this bounding box has a third dimension to it too)

Screenshot%202015-06-18%2023.51.06.png


This bounding box is part of what causes the issue, but the main culprit is actually solidity.

It must have been an oversight at Valve HQ: func_lods AND func_brushes, when set to have solidity, will not allow a teleporter exit to function while inside its bounding box.

Func_lods and func_brushes with NO solidity, however, DO allow teleporters to work. I can only assume this is caused by the entire bounding box of the entity being treated as a "solid" in-engine rather than the specific brushes making up the entity!

TL;DR:

A func_lod or func_brush set to HAVE SOLIDITY ("Solid" for lods, "Always Solid" for brushes) will NOT ALLOW teleporter exits to be used.

A func_lod or func_brush set to have NO SOLIDITY ("Nonsolid" for lods, "Never Solid" for brushes) WILL ALLOW teleporter exits to be used.

It's crazy to me that I've never seen this engine bug documented anywhere before. I had no idea this was the cause until now. So, kiddos, learn your lesson: if making a func_lod or func_brush with a bounding box large enough to enclose a teleporter exit, always make them nonsolid.
 

tyler

aa
Sep 11, 2013
5,102
4,621
Maybe you (or someone) or should email this to Valve and see if they can fix it somehow. I wonder if they are aware of it.
 

Lenny

L2: Junior Member
May 2, 2013
90
35
I think teleporters are set to auto-destroy when it thinks a player that would teleport would get stuck in world geometry. Pretty interesting that it'd happen with func_lod.
 

phi

aa
Nov 6, 2011
832
1,815
I think teleporters are set to auto-destroy when it thinks a player that would teleport would get stuck in world geometry. Pretty interesting that it'd happen with func_lod.

They are definitely set to do that - what I think is happening here is that the game is treating the entire bounding box of a solid func_lod or func_brush as "world geometry" (or more colloquially, "places you shouldn't be allowed to teleport inside"), instead of just the brushes the entities contain.
 

Empyre

L6: Sharp Member
Feb 8, 2011
309
187
It has been this way since the old TFC. To avoid the problem, don't combine brushes into a single entity with an extent box that would enclose play areas. Make them separate entities.
 

Crash

func_nerd
aa
Mar 1, 2010
3,315
5,499
Bump because more people need to know about this issue.

Also some more keywords for future searchers:

Teleporters explode when taken, teleporters explode when used, teleporter bug, teleporting explodes, teleporting destroys teleporter.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
If you make that large set of beams a single non-solid func_lod, you'll be able to put sticky traps inside the wood, which is bad.

Instead you should convert it to a model (using propper) or split it so each wall is a separate (solid) func_lod. That way it'll only disallow teleporters right up against the walls, which is fine.
 

Toomai

L3: Member
Apr 14, 2011
129
144
Func_detail doesn't fade with distance.
Beam structures that large probably shouldn't be fading anyway. func_lod is intended for long-distance glances that are tricky to notice from far away, and there has to be some point (in size/complexity) where fading something is more expensive than leaving it be. If you can't see it around a corner before it fades away, just leave it as func_detail and let visleaves do the job.
 

Idolon

they/them
aa
Feb 7, 2008
2,105
6,106
It'd be beneficial to func_lod your beams if you had a situation where you can see into a building from a pretty far distance through a window (especially a one-way window). I believe this is the exact case in Sunshine.