I've taken to using "usr" for a lot of my verbs. But there are some potential cases where I'm wondering if it's OK to do that. Consider something like this:
mob/verb/attack(myTarget as mob)
usr << "You attack [myTarget]."
myTarget.say("Ow, that hurts!")
If "say" relies on usr for anything, then I think I'd get a result that assumed the attacker was executing the verb. Is that the case, and if so, could I work around it with something like this?
usr << "You attack [myTarget]."
var/oldUsr = usr
usr = myTarget
myTarget.say("Ow, that hurts!")
usr = oldUsr
I'm also wondering about similar cases for objs that have their own verbs, e.g.:
usr << "You attack [myTarget]."
var/oldUsr = usr
usr = myTarget
var/obj/pepperSpray/mySpray
for(mySpray in myTarget)
mySpray.spray(oldUsr)
break
usr = oldUsr
obj/pepperSpray/verb/spray(myVictim)
usr << "You spray (myVictim) right in the face!"
Sting(myVictim)
Yeah, I know I could test this, but I can't test it until tonight, and there might be a better way to handle it anyway... so I figured I'd just ask instead. :)
ID:259231
 Sep 22 2000, 3:50 am
|
|
I try to use src unless absolutely necessary to use usr. That always avoids any external "call-me" weirdness. This was my own practice until recently. But now I have embraced usr! I *will* master it! :) As it stands, yes, the attacker would say "Ouch!" every time he beat on someone. =) Aha! I thought so. Now to figure out how to get around it... Thanks for the info, Mr. Giant, sir... :) | |
All of your examples should work. The 'usr' var is treated just like any other global, and can be set and reset as needed. In fact, so can the 'src' var. This is occassionally even useful. When an object is deleted, all of its running procs are killed; you keep the proc alive, though, by disassociating its parent object from its proc. To do this, set src to null at the top of the proc (but make sure not to use any object properties inside the proc, else you will get a dereferencing null error).
| |
On 9/22/00 10:21 am Spuzzum wrote:
Yeah, I know I could test this, but I can't test it until tonight, and there might be a better way to handle it anyway... so I figured I'd just ask instead. :) Another agreement with Spuzz. I now officially consider usr to be bad coding policy, and am not using it anywhere I can avoid it. usr is deceptive...you can go along for months and it seems to work like magic, always giving you what you expect. Then you start putting up games that have lots of multi-player usage, or that indirectly call verbs, or where NPC mobs start using functions that you originally thought would be player-only, or where sleep() or spawn() may change the semantics of usr (this one I'm not as sure about but I think it might have happened to me), and suddenly you get bizarre behavior that can be hard to debug, because you were assuming usr would always point to what you wanted, but sometimes it doesn't. So when possible use src or pass in a reference to the object that you would normally expect to be usr and use that reference instead, that's what I say. | |
So when possible use src or pass in a reference to the object that you would normally expect to be usr and use that reference instead, that's what I say. It's good advice, too. But it's too late for me... I'm addicted. Usr is only the tip of the iceberg of the bad programming practices I've been using in the past few weeks... if/when I release the source code of my current project, God help anyone who actually uses it for anything! :) | |
I try to use src unless absolutely necessary to use usr. That always avoids any external "call-me" weirdness.
As it stands, yes, the attacker would say "Ouch!" every time he beat on someone. =)