ID:272262
May 18 2008, 11:44 pm
|
|
And when making it so GMs would log in with their verbs, instead of putting:
if(src.key=="GM1"||src.key=="GM2"||src.key=="GM3"||) I put: if(src.key=="GM1"||src.key=="GM2"||"GM3") And now people have GM verbs until updates. What I want to know is if this would 'cause what we call the "GM Bug" or would it be something else? | |
1. I know not to use usr. Sometimes I just end up doing it though.
2. I was asking whether or not what I did would 'cause the "GM Bug". I've already got a verb for giving GM out. However it kind of gets tedious to keep doing it after pwipes. | |
"GM3" always evaluates as true, so the statement " a==something || b==something || "gm3" " always evaluates as true, so the if statement is always executed.
| |
No that wouldn't be it. Because ALL MOBs are usr's. You're taught to use src in proc's because it is a more correct way and since 75% of the time a usr isn't involved.
| |
Wrong. usr is the mob that ultimately called the function being executed. For a procedure, that may not be the mob you expect. It's quite possible to get some very weird effects from usr abuse. An example:
turf/fire/Entered() Some simple code to display a message to people entering a turf. It works - try it out, you'll get the message if you walk into it. But a bit more investigation reveals the insidious effects of usr abuse. Say you have some NPCs: mob/NPC/New() Every so often, you get runtime errors about accessing a null value in turf/fire/Entered(). What gives? Well, mob/NPC/New() has a null usr, so when walk_rand() is called, that function gets a null usr. So when that ends up calling turf/fire/Entered(), /that/ has a null usr. You can see where this is going. Worse yet, what if you can push players? mob/verb/push(mob/m in view(1)) Some canny player tries to push an opponent into the fire - but the pusher gets burnt, not the pushee! What's going on? Well, when push() is called, usr is the pusher - this makes sense. usr is safe to use in push(), because you know exactly who it is - the person who called the 'push' verb. I calls step_away on m, making it take a step away from src (which is probably equivalent to usr right now). So m.step_away() has been called with usr == the pusher. So when it enters the fire turf, usr == the pusher. Which proc is this GM code in? | |
mob/Login.
Well, not only did I learn the problem, but you solved a runtime error I have (at least I think you did...). Thanks! | |
This would be so much better and easier if you used a list.
| |
Hmmm... usr really shouldn't be used in mob/Login(), but I'm not certain it'd cause only some players to have this weird stuff going on. You might want to check if removing that usr (if you don't specify a source, it defaults to src) and fixing the if() fixes anything.
| |
Jp wrote:
Wrong. usr is the mob that ultimately called the function being executed. For a procedure, that may not be the mob you expect. It's quite possible to get some very weird effects from usr abuse. An example: > turf/fire/Entered() Some simple code to display a message to people entering a turf. It works - try it out, you'll get the message if you walk into it. But a bit more investigation reveals the insidious effects of usr abuse. > mob/NPC/New() Every so often, you get runtime errors about accessing a null value in turf/fire/Entered(). What gives? Bad example. usr is set to src in mob/New(). I wouldn't rely on this behavior, though, because it's still a bad practice. The pushing example is good, though. | |
Remove GM verbs and add them again IF they are GMs.
//codes here..src.verbs-=typesof(/mob/GM/verb)
if(src.key=="GM1"||src.key=="GM2"||src.key=="GM3")
src.verbs += typesof(/mob/GM/verb)
//codes here..