ID:1778014
 
(See the best response by DarkCampainger.)
Code:
/turf/Enter(atom/movable/mover as mob|obj, atom/forget as mob|obj|turf|area)
if (!mover)
return 1
// First, make sure it can leave its square
if(isturf(mover.loc))
// Nothing but border objects stop you from leaving a tile, only one loop is needed
for(var/obj/obstacle in mover.loc)
if(ismob(mover) && mover:client)
world << "origin: checking exit of mob [obstacle]"
if(!obstacle.CheckExit(mover, src) && obstacle != mover && obstacle != forget)
if(ismob(mover) && mover:client)
world << "Origin: We are bumping into [obstacle]"
mover.Bump(obstacle, 1)
return 0

var/list/large_dense = list()
//Next, check objects to block entry that are on the border
for(var/atom/movable/border_obstacle in src)
if(border_obstacle.flags&ON_BORDER)
if(ismob(mover) && mover:client)
world << "Target(border): checking exit of [border_obstacle]"
if(!border_obstacle.CanPass(mover, mover.loc) && (forget != border_obstacle))
if(ismob(mover) && mover:client)
world << "Target(border): We are bumping into [border_obstacle]"
mover.Bump(border_obstacle, 1)
return 0
else
large_dense += border_obstacle

//Then, check the turf itself
if (!src.CanPass(mover, src))
mover.Bump(src, 1)
return 0

//Finally, check objects/mobs to block entry that are not on the border
for(var/atom/movable/obstacle in large_dense)
if(ismob(mover) && mover:client)
world << "target(large_dense): [mover] checking [obstacle]"
if(!obstacle.CanPass(mover, mover.loc) && (forget != obstacle))
if(ismob(mover) && mover:client)
world << "target(large_dense): checking: We are bumping into [obstacle]"
mover.Bump(obstacle, 1)
return 0
return 1 //Nothing found to block so return success!


Problem description:
Have an interesting bug resulting in a certain mob type being able to phase through border objects. Example of the bug in action: http://a.pomf.se/yclmqq.webm

I've been trying to figure out what's going on and the only thing I can think of is for this mob child only is atom/Enter being called when it tries to move past one of these directional windows and if a mob is on the otherside it will swap places due to code in Bump. Thing is I don't call the super in turf/Enter, only return 1 or 0 as seen above.
Best response
I think it's atom/movable/Move() that is responsible for calling Bump(), not atom/Enter(). If I had to guess, I would say your Enter() is returning false, and then the default Move() is looking for an obstacle to explain the failure, finding the other player's mob, and calling Bump() with it.

Best solution is probably to transfer most of this logic into Move().
Well I have no reading comprehension today then.
Thanks I was able to solve my issue.
Yep, DC nailed it. The built-in Move() does all of the following:

1) Check to see if the movement is a "slide", and if so if it moves more than the mover's actual size. If so, it breaks the move into multiple steps.

2) Get a list of all atoms the mover is "on", and a list of all atoms the mover would be on at the end of the move. Atoms on both lists are ignored.

3) Attempt to exit/uncross any of the atoms on the old list. If any check fails, the move fails.

4) Attempt to enter/cross any of the atoms on the new list. If any check fails, the move fails if this is a jump. If it's a slide, the move is restricted to where the failed atom would be touched; any atoms no longer belonging on the new list are removed from it. The atom that failed is added to a list of bumped atoms; if the move got restricted further than it already was, the bumped list is cleared first.

5) The move has either succeeded fully, succeeded partially, or failed.

6) If success, the mover is moved.

7) Bump() is called for anything that got bumped.

8) Exited(), Uncrossed(), Entered(), and Crossed() get called as appropriate.