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

Discussion in 'Tutorials & Resources' started by phi, Jun 19, 2015.

  1. phi

    aa phi Within The Vacuum Of Infinity...

    Messages:
    793
    Positive Ratings:
    1,516
    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:

    [​IMG]
    [​IMG]

    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:

    [​IMG]

    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)

    [​IMG]

    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.
     
    • Thanks Thanks x 15
  2. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,032
    Positive Ratings:
    3,978
    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.
     
  3. Lenny

    Lenny L2: Junior Member

    Messages:
    90
    Positive Ratings:
    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.
     
  4. phi

    aa phi Within The Vacuum Of Infinity...

    Messages:
    793
    Positive Ratings:
    1,516
    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.
     
  5. Empyre

    Empyre L6: Sharp Member

    Messages:
    279
    Positive Ratings:
    131
    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.
     
  6. Crash

    aa Crash func_nerd

    Messages:
    3,124
    Positive Ratings:
    4,693
    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.
     
    • Thanks Thanks x 5
  7. YM

    aa YM LVL100 YM

    Messages:
    7,099
    Positive Ratings:
    5,741
    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.
     
  8. takabuschik

    aa takabuschik

    Messages:
    660
    Positive Ratings:
    308
  9. Vincent

    aa Vincent 🔨 Grandmaster Lizard Wizard Jedi 🔨

    Messages:
    914
    Positive Ratings:
    580
    Func_detail doesn't fade with distance.
     
  10. Toomai

    Toomai L3: Member

    Messages:
    129
    Positive Ratings:
    77
    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.
     
  11. Crash

    aa Crash func_nerd

    Messages:
    3,124
    Positive Ratings:
    4,693
    func_detail also doesn't help reduce tjuncts, which is generally the point behind propper-ing/ func_brush-ing/ func_lod-ing certain beams.
     
  12. Idolon

    aa Idolon the worst admin

    Messages:
    1,432
    Positive Ratings:
    4,181
    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.