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

[phi]

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:

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:

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)

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]

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]

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]

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]

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]

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]

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.

 

[takabuschik]

Or use func_detail.

 

[Vincent]

Or use func_detail.

Func_detail doesn't fade with distance.

 

[Toomai]

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.

 

[Crash]

func_detail also doesn't help reduce tjuncts, which is generally the point behind propper-ing/ func_brush-ing/ func_lod-ing certain beams.

 

[Idolon]

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.