ID:150119
 
Hello its me kalzimere again. I started using the Enter() and Exit(). I have it so that it checks when a usr enters a certain icon_state then something is overlayed on them. It works but then it doesn't. It works because it overlays correctly and goes off when off that icon_state. But for some reason it makes it so the usr can walk over everything dense or not dense. So perhpas i need to add something to tmy code. Here it is :

turf
icon = 'Terrain.dmi'

Enter()
if(icon_state=="waterM")
usr.overlays +=/obj/overwater
if(icon_state=="plains")
usr.overlays +=/obj/pgrass
return 1
Exit()
if(icon_state=="waterM")
usr.overlays -=/obj/overwater
if(icon_state=="plains")
usr.overlays -=/obj/pgrass
return 1

Well theres my code. I also thought perhaps making an area instead, but i was still ealrning what areas where. Thanks for all your help.

-kalzimere
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 response to Air Mapster
I understand now THANKS A TON AIRE MAPSTER. Was first time using this command lol. Thanks again.

-kalzimere
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

In response to Shadowdarke
Shadowdarke wrote:
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

Looks like you changed O to M halfway through... you probably want to stick to the Os.
In response to Skysaw
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.
In response to Shadowdarke
Shadowdarke wrote:
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.

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?
In response to Skysaw
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
In response to Lummox JR
Yeah sorry haven't been checking back on forums i figured air mapster was going to be last post lol. I was wrong, I read over what you guys said and made changes. Just writing back to sya thank you.

-kalzimere