Enter() and Exit() are called when a player attempts to enter or exit a turf. BYOND uses these procs to determine if it should allow that player to enter or exit the turf. They return 1 if the player is allowed, or 0 if not. What you really want to use is Entered() and Exited(). These get called after the player has successfully entered or exited the turf. If the turf is dense, then Enter() will return 0 and the player will be denied entry - and thus Entered() will never be called.

So, the reason you saw the behavior you did was because (a) you were using Enter() instead of Entered() and (b) you returned 1 no matter what, meaning even if the turf was dense it allowed the player to enter. When you change to Entered() and Exited(), you probably want to return ..() which calls the default versions of those procs.

In addition to the things Air Mapster pointed out, you shouldn't use usr in these procs. It works fine since you are testing single player, but if you test this with other players, you will get unexpected results. Usr is the last mob to use a verb or click on something, not necessarily the person entering the turf.

Enter, Exit, Entered, Exited, and many other procs recieve an argument to indicate who or what it should effect.

Entered(O)
if(ismob(O))
var/mob/M = O // store it in a mob variable so we can access mob vars
if(icon_state=="waterM")
M.overlays +=/obj/overwater
if(icon_state=="plains")
M.overlays +=/obj/pgrass

Skysaw wrote:

Looks like you changed O to M halfway through... you probably want to stick to the Os.

I changed to M with this line
var/mob/M = O // store it in a mob variable so we can access mob vars
so that it could access mob variables without using the : operator. I probably should have highlighted it as well.

I could have used
Entered(atom/movable/O)
and avoided the M var, but if he wants to do anything that is mob specific later on, it's better this way.

Skysaw wrote:

Whoops... totally missed that line, hehe. I am wondering if (atom/moveable/O) is even necessary, since something can't enter if it's not already moveable, huh?

I think it's necessary in the sense that any time you override a proc, you define a new set of arguments that may or may not match the old set. Thus, although Entered(atom/movable/O,atom/oldloc) may be part of the built-in code, your new code could define something completely different. It could be possible, I suppose, for DM to check on the old type and make an assumption about the new type, but not only would this be more difficult, it wouldn't even be the desired behavior in some cases (usually for other procs, though).

I think you may also be assuming that Entered() should be handled differently inasmuch as it's a built-in proc that performs a specific task, or rather an override of a built-in proc, but I don't think DM actually looks at things that way. Or more to the point, just because Entered() is only ever called for movable atoms doesn't mean DM really knows that, because then you're talking about the purpose of a proc rather than its declaration. In terms of a declaration, it does take atom/movable as its first argument, but an override could change that type at will.

Lummox JR