ID:175172
 
ok, I'll bite, why exactly is this a horrible baby eatingly bad thing to do?

-Salarn
Ok, I'm gonna answer this before the EVIL...SADISTIC Moderator does(Lummox =p)...USR=BAD, WHAT IF...an obj enters the turf and you have usr!? IT'LL GET A BIG RUN-TIME ERROR, ONE WHICH YOU'LL FIND HARD TO SOLVE...SO, AS WITH ANY PROC NEVER...EVER...USE USR IN IT@!!!
In response to Goku72
Hmm...Interesting, but if usr in procs is so bad, why not have DreamMaker poop out warnings whenever it sees "usr" in a proc?

-Salarn
In response to Salarn
Because usr is perfectly valid in procs. The problem is, people don't know when to use it. Basically, usr is the mob that initiated the string of proc/verb calls. So, for example, a way to use usr in Entered():
turf
nullMagicZone
Entered(mob/M)
if(ismob(M))
if(usr && usr != M)
usr << "Your mind control spell wore off"
usr.controlling = null

If someone used a mind control spell to move you into the nullMagicZone turf, they would lose control. If someone was controlling you, usr would be someone else (and wouldn't be null). But, this is a very rare instance of where usr could be used.
In response to Garthor
Interesting

so are you using

"if(usr"

to be the same kind of test for "istype(mob/M)"

-Salarn
In response to Salarn
No. I'm using it to check to see whether or not usr exists. usr is usually not safe in procs of any kind. Try this: put <code>if(usr != src) world << "\red usr != src"</code> in a bunch of procs in your game. You'll see how often usr is not a replacement for src.

Oh, and I just realized I put src where it should have been M in that proc.
In response to Garthor
Actually in this instance, usr wouldn't do you much good. usr would most likely be the same as M, not the person who initiated mind control, because that would have been a separate action. Most mob movement is initiated by the mob themselves, which is why usr in movement procs usually works. The problem is with "usually".

Lummox JR
usr is the mob of the player that initiated the current action. Whatever verb was called (or some internal proc treated in a verbish way, like client/Topic()) had its usr var set to whoever called it, and any procs it called inherited the same value.

When you perform regular movement, you're effectively calling one of the client verbs like client/North(), which in turn calls client/Move(), then mob/Move(), which calls things like Enter() and Entered() and so on.

But that's only when you move, and only when you do so by choice.

If monsters move about using Move() or one of the built-in procs like step() that call it, usr will not match the monster but whatever player took the steps to spawn the monster and start up its AI code. If an obj like a moving obstacle moves normally, it will have a similar problem.

Enter() takes one argument: the atom that's trying to enter. That's the thing you should use in place of usr, and usr would only be used if you wanted to verify that the mob trying to enter did in fact choose to enter. For example if you set up a system where you can push other players, but have special locked doors whose keys disappear when you open them, it'd be bad if someone could simply push you into a door you didn't want to open. So:
turf/door/special
var/color

Enter(atom/movable/A)
var/obj/key/K
for(K in A)
if(K.color == color)
// only allow entry if A did this on purpose
return (A == usr)
return 0

Entered(atom/movable/A)
var/obj/key/K
for(K in A)
if(K.color == color)
del(K)
new /turf/floor(src)
return
Entered() takes two arguments: The atom that entered, and its old location. However you rarely need the old location, so it's safe to leave it out.

That's an example of a rare situation where usr in Enter() would make sense.

Lummox JR
In response to Lummox JR
Why not just post that ever-useful link, Lummox? That's what I do. =)

usr Unfriendly