ID:261438
 
In the following code, the compiler refuses to acknowledge that the following variables exist, even though they are declared in /mob/pc and usr is of that type:

mob/Stat()
statpanel("Status", "HP", "[usr.HP]/[usr.Max_HP]")
stat("MP", "[usr.MP]/[usr.Max_MP]")

The declarations of those variables do exist, and I have added the "mob = /mob/pc" line under the "world" tree. What more is there to do?

mob/pc
var
HP = 25
Max_HP = 30
MP = 10
Max_MP = 15

I don't see anything wrong myself...
Even though the default type of a player is mob/pc you could very easily put the player in a different mob or make it a new mob of a different type during the course of the game.

That is why the compiler can't assume that usr's type will be the default type for players.

One way to fix this is to change your Stat proc for just pc's like this:

mob/pc
Stat()
//stuff here

Also, you really shouldn't be using usr because you can only be sure that there will be a usr when the player physically clicks on a verb. Just remove the usr. and those variables will default to src (which will be of type /mob/pc)
In response to English
Also, you really shouldn't be using usr because you can only be sure that there will be a usr when the player physically clicks on a verb. Just remove the usr. and those variables will default to src (which will be of type /mob/pc)

Well, while in this case the recommendation is sound, the actual reasoning isn't -- usr is defined for you in all of the pre-defined mob procs; Stat(), for example, does legally accept usr. However, if *another* mob were to call my Stat() proc, then it'd display the results to that mob instead of me. Well, actually, it'd cause an error, since you're not allowed to do that, but you get the idea. =)

It is highly recommended to avoid using usr except in the situation of verbs. src is a much better alternative, because then you can be certain you're affecting only this mob, even if other mobs call that proc for you.
In response to Spuzzum
The F1 help seems to agree with me (although it really doens't matter, it leads to the same conclusion) :p

"While it can simplify your code in some situations, it can also lead to subtle problems if you are assuming that usr is automatically assigned to src when you call a verb programmatically. It is not.

The only time usr is assigned for you is when a player (in Dream Seeker) executes a verb, clicks something with the mouse, or any other such action."
In response to English
"The only time usr is assigned for you is when a player (in Dream Seeker) executes a verb, clicks something with the mouse, or any other such action."

Strange that the documentation should say that, given that all of the pre-defined mob procs that I ever use accept usr. Of course, Dantom may be trying to deter its use by saying that you can't use it. =)
In response to Spuzzum
It is odd, now that I re-read it there seems to be some contradiction...

"Essentially, usr is an implicit parameter that is passed to <font color=red>every</font> proc or verb. Each procedure inherits the value from its caller."

That would seem to imply what your saying, yet the other part seems a bit contradictory to it. Lets just say we're both right and we should avoid usr unless we need to use it :op
In response to English
English wrote:
It is odd, now that I re-read it there seems to be some contradiction...

"Essentially, usr is an implicit parameter that is passed to <font color=red>every</font> proc or verb. Each procedure inherits the value from its caller."

That would seem to imply what your saying, yet the other part seems a bit contradictory to it. Lets just say we're both right and we should avoid usr unless we need to use it :op

There is a good use for usr in procs, though I would always stear newbies away from believing so.

If a proc is specifically written as an action a mob will take on another mob or object, then it's fine to do. For example, in MLAAS mobs have a proc called do_suspicious whenever they are trying to be sneaky. This looks for nearby mobs, and calls a proc within them called see_suspicious. In this case, see_suspicious will have a usr value equal to the mob trying to do something sneaky.

True, I could explicitly pass in the mob and avoid usr, but in this case I liked the usage.
In response to English
No contradiction there. It's only saying that usr is equal to the object which "owns" a proc if a player uses that proc themselves. If you call a proc (even a verb) manually, then usr will be taken from the usr of the calling procedure.

That is, suppose you have an equipment system with an unequip verb. If a player uses the unequip verb, then usr will be equal to that player. But if another player casts a Shizban's Shameful Immodesty spell on them which calls unequip() on all the victim's worn items, usr will actually be the caster, not the target.