Deadlock Doorman Bugs: Why Doorway Exploits Keep Returning
Valve fixed more Doorway and Luggage Cart exploits on July 8. New clipping reports followed, and a forum user now argues the portal needs a different physics architecture.
The door is working. The space around it is where the trouble starts.
Valve fixed "various" Doorway out-of-bounds exploits and Luggage Cart bugs on July 8. By mid-July, the official forum was already collecting new reports about players stuck behind doors, clipped into terrain, or moved outside the map.
One player thinks the cycle will continue until Deadlock stops treating Doorman’s portal as a teleport.
The proposed answer is a "solver space": a hidden, continuous physics room where the game could resolve carts, players, projectiles, and collision before projecting the result back through the two visible doors. It is an ambitious community design, not a Valve feature or announced fix.
It is also the first recent Doorway argument that tries to explain why patching individual locations may never be enough.
What did Valve fix on July 8?
The July 8, 2026 update was short and focused on bugs. The preserved Yoshi note lists four relevant changes:
- Fixed Unstick not working in tunnels.
- Fixed a bug that allowed players to rotate upside down.
- Fixed various Doorman Doorway out-of-bounds exploits.
- Fixed various Luggage Cart bugs.
Those are real fixes. The patch note does not identify every Doorway location, interaction, or exploit it addressed, so it cannot be read as a promise that all portal problems were solved.
Forum activity after the update supports the narrower interpretation. Related threads describe Vindicta’s Stake creating stuck states behind a door, Doorway interactions near the Urn lane, map clipping, and other cases where forced movement or collision behaves badly around the portal.
Why Doorman’s portals are unusually hard
Most game physics assume that space is continuous. A player moves through the points between one location and another. Collision checks the surfaces along that path.
A portal breaks that assumption. An entity crosses a surface at one point on the map and appears at another. Movement, collision, abilities, projectiles, animation, and networking all need to agree on what happened during that transition.
Doorman makes the problem worse in ways that are good for the hero and terrible for the engineers:
- The doors can be placed on many different surfaces.
- Twelve players and dozens of abilities may interact with them.
- Luggage Cart adds forced movement.
- The map and its collision geometry keep changing.
- Every interaction must remain consistent over a network, not just on one machine.
The forum proposal uses a cart pushing an enemy through a door as the clearest example. The cart’s movement system wants to continue along a vector. The portal wants to place the target at a corresponding point on the other side. A small disagreement can leave the player inside a wall, behind the door, or out of bounds.
What is the Doorman solver-space proposal?
Forum user Siker_7 proposes creating a small physics-only environment outside the playable map.
When Doorman places two doors, the game would copy the nearby collision geometry around both entrances into that hidden environment and stitch the two sides into one continuous room. Players, carts, abilities, and projectiles near either door would receive shadow versions inside the room.
Inside solver space, there is no teleport. A cart pushes a player through an ordinary doorway using continuous geometry. The solver decides the valid position, then maps that result back to the visible game world.
The conceptual benefit is one source of truth. The game does not ask every system to independently interpret a discontinuous jump; it lets ordinary physics resolve the crossing first.
Would solver space actually fix Doorway?
Nobody outside Valve can establish that from a forum design.
The proposal includes difficult assumptions:
- The game would need to copy and join collision geometry reliably.
- The authority boundary around each portal could become a new seam.
- Multiple Doormen in custom modes would require special handling.
- Every shadow entity must stay synchronized with the visible entity.
- Performance and networking costs cannot be measured from a written concept.
The author argues that Deadlock already maintains a disconnected area below the map for the Baroness Hotel and that Source 2 work may provide useful building blocks. Those are technical inferences, not confirmation that Deadlock’s current Doorway implementation can adopt the design.
Another forum reply suggests a smaller collision adjustment might fix the cart trapping case without an architectural rewrite. That response is a useful reminder: one visible symptom can have a local fix even if the larger class of portal problems remains.
Why the proposal is worth Valve’s attention
The useful claim is not "a forum user solved Source 2." It is that Doorway bugs may be a category rather than a finite list.
If the failures emerge whenever teleport logic, forced movement, and collision disagree, fixing one wall or cart angle will not prevent the next ability or map surface from creating a new version. Valve may still have a better internal solution. The architectural framing tells players why repeated fixes and repeated reports can both be genuine.
Doorman’s identity depends on the portal. Removing the difficult interaction would remove the hero. The question is how much engine work that identity can justify while Deadlock is still in development.
For the character behind the mechanic, read DramaLock’s Doorman lore guide. For current ability basics, use the Doorman gameplay guide.
Sources
- Official Deadlock forum: Doorman’s Solver-Space proposal — player-authored technical proposal, limitations, and follow-up discussion.
- Deadlock Wiki: July 8, 2026 update — preserved Yoshi note for Doorway, Luggage Cart, Unstick, and upside-down fixes.
- Official forum: Vindicta Stake stuck-state report — reproducible July 14 example with an attached video.
- DramaLock: Doorman lore — internal lore companion.