usr Unfriendly/Abuse.

ID:151489
 
Aug 23 2010, 1:36 pm
Allo.

After being yelled at by garthor a couple times about usr abuse in procs ive all but fixed that problem awhile back but another little query has come to mind after awhile since i didn't really go into large scale verb creating and im using the verb package system thats supplied by Jtgibsons forum.

ive gone into proc related verbs for my admin and guild packs.

now since there procs but are technically in the long run verbs does the no usr in procs apply to this case or does it cancel out?

if it does apply what methods are there that are available to counter this rule

Thanks
~midget
Aug 23 2010, 1:54 pm
Your English is horrifically inadequate in the task of explaining what it is you're asking, but I understand the basic question.


The REASON you don't use usr in procs normally is because of logic; DM won't magically know who usr is if there's more than one player online. An example of this would be:

obj
    Food
        proc/Eat()
            view(usr) << "[usr] has eaten [src]. Yummy!" // Alert everyone in "usr"'s view() that usr has eaten the food object
            del(src)


This is extremely wrong because in some cases there will be no usr calling the proc and you will most likely face a lot of difficulties with your code in a populated server. It's better to define SPECIFICALLY who's eating the food.

        proc/Eat(fatman as mob)
            view(fatman) << "[fatman] has eaten [src]. Yummy!"
            del(src)


// To call this, we simply use it in a verb like obj/Food/verb/Nom()

Eat(usr) // for clarification, the src (the food) is being eaten here and in the parentheses we specify WHO is eating


Now that's much better! Here we use a variable, fatman, to reference who exactly is eating the food. What you should keep in mind is that in most verbs it's okay to use usr because it's virtually impossible for one player to call another's verb. The same applies for client procs and mouse functions.

Aug 23 2010, 2:11 pm
In response to Duelmaster409
hmm i thought my english was quite good on explaining it. maybe my head just works a bit different arr well.

Anyways i know how it all works so the snip was somewhat of a pointless thing but thanks for putting the time in to respond anyway.

the reason i asked was mainly because (this is what a basic verb would look like if i used usr in the proc that gets turned into a verb)

guild
    var
        hname
        rname
        list/members
        owner
        coowner

    proc
        Invite(var/mob/human/M in ClientGuilded()) //clientguilded sorts the world for players not in guilds.
            set category    = "Guild"
            set popup_menu = 0
            var/guild/gcheck = oguilds[usr.pguild]
            switch(input(M,"[usr] has requested that you join [usr.pguild]. Accept?","Guild Controls","Yes","No")) // prolly doesnt work but its not a real thing anyway its purely for reference
                if("Yes")
                    gcheck.members += M.name
                    M.pguild = usr.pguild
                    M.rank = "Member"
                    M.title = "Recruit"
                    M << "You join [usr.pguild]."
                else
                    usr << "[M] Declines the invitation"


as you can see this is a proc in the guild datums that uses usr in a proc for the sake of displaying the sender and what not.

but since that would be converted to a verb by the verbpackager the point of the thread becomes is that an ok form of putting usr in a proc or not.

Aug 23 2010, 3:09 pm
In response to Midgetbuster
usr should only be used in neccesary cases such as the Click proc, in my case i dont use them in verbs OR procs at all unless im just doing some quick test thing and overlook(which rarely happens) what im typing :P
Aug 23 2010, 3:23 pm
In response to Masschaos100
yeah i usually use src aswell but since in the case of this src cant be used as the proc that is transferred into a verb is inside a guild datum as opposed to a mob/proc.

so src becomes null and void due to the datum.
Aug 23 2010, 4:12 pm
In response to Midgetbuster
That's what proc arguments are for, if src isn't valid then you should be passing what you need to the proc when you call it.
Aug 23 2010, 4:58 pm
If the only purpose of a proc is to later be added to a player's verbs list, it's fine to use usr in it, because it really is just a verb by another name. However, I'd strongly suggest using a more modular approach than mucking around with verbs lists., such as using objs in contents instead.
Aug 23 2010, 5:01 pm
In response to Garthor
Kind of like how some skill systems are used (skillcards) right?
Aug 23 2010, 5:02 pm
In all honesty this is a little bit of a gray area. The key thing, above all else, is to be sure that if you do use usr, it's used correctly. If you have procs that are extremely verb-like, and are only ever called by verbs, usr may be justified there. The thing is, it's kind of a slippery slope, so if you do this you should be darn careful.

If you've had usr issues in the past though, I recommend extreme caution and passing the acting mob as an argument in all cases. Better to learn how to do it the strict way.

Lummox JR
Aug 23 2010, 7:53 pm
In response to Duelmaster409
The only case where the Eat proc would be incorrect, is if you have a player force-feeding another.

Because of the way that usr is passed along within the arguments of a function, it is generally safe. However, it doesn't mean that it's proper to use it, so you are right in theory, just wrong in all but the most obscure situations.


I strongly dislike the "no usr" argument, because a sense of tribal knowledge has come to surround the entire subject because of mostly vague or incorrect information being thrown around.

But Lummox said it already, it's a slippery slope, and when a system goes from being simple to complex, it can cause some pretty severe issues.
Aug 23 2010, 8:00 pm
In response to Midgetbuster
Wrong. I'm talking about an obj that you place in a player's contents but is invisible, and contains the desired verbs (with the "set src in usr" setting, but that's default for objs).