if(fexists("players/[src.ckey].sav"))
var/savefile/F = new("players/[src.ckey].sav")
src.loc=locate(lx,ly,lz)
world<<"<font color=red><b>System Informer:<font color=white>[src.key] as logged in"
src.message2()
for(var/mob/M in world)
if(M.creator==1||M.admin==1)
M.money=100000
M<<"<font color=red>usr.key]-[usr.client.address]"
else
usr.money=100
F["mob"]>>src
else
select character blah blah
Logout
Logout()
world<<"<font color=red><b>System Informer:<font color=white>[usr] has logged out."
var/savefile/F = new("players/[src.ckey].sav")
F["mob"]<<src
del(src)
Problem description:
System Informer:CodingSkillz2 as logged in
System Informer:CodingSkillz2 has logged out.
It says the usr being loaded has logged out. Anyway I could fix this?
usr is basically a variable which is equal to the last mob to do something. When you press a hyperlink, you become Topic()'s usr, when you press a verb, you become that verb's usr, when you Click(), then you, the clicker, are the usr of Click(). usr is not a global variable. It only works right in certain situations because it isn't a global variable. If player A presses attack() at the same time as player B, then player A's attack()'s usr is equal to player A, while player B's attack()'s usr is equal to player B.
usr is passed down through the call stack (the area of memory where arguments are passed through) from function to function, so if, from attack(), I call src.Death(), then Death()'s usr variable will be equal to the player who attack()ed. Of course, it usually isn't good to rely on this. If src is usable, then use it.
Since most procs are initialized by the program, and not the player, usr is not neccessarily equal to the player you want it to be equal to at a given time.
One common mistake is to use usr in movement-related procs such as, for example, turf/Entered(). This is a big no-no, for more than one reason. You see, in DM, movement procs are all under or related to atom/movable. atom/movable is a type path which encompasses both mobs and objs. Therefore, if I used usr in turf/Entered(), which takes an atom/movable as its argument, and an obj entered the turf, then chaos would ensue: the last playr to do something would "randomly" be affected by the turf/Entered().
Note the way I use the word, "object": I don't mean "obj". In programming, "object" generally means something like "thing".
You'll find that excepting certain instances (usr is commonly needed in client/Topic(), for example, because the src value of Topic() can actually be manually defined by the developer), and also excepting certain functions, such as, for example, Click(), DblClick(), and Stat(), it's unsafe to use usr in procs. That's because when a function is called manually, and not by the player, then the usr variable of that function will not necessarily be equal to the player you want it to be equal to. To solve this problem, use src instead unless you specifically know that you mean usr.
Remember, usr is the default argument for certain verbs such as input(), alert(), view(), oview(), range(), and orange(), so you'll have to change that argument in situations where usr isn't appropriate.
In sum, a good "rule of thumb" is only to utilize usr when you explictly mean usr, and not src