Help with HUD buttons

ID:1788507
 
Feb 17 2015, 6:18 pm (Edited on Feb 17 2015, 10:53 pm)
Keywords: buttons, help, hud
(See the best response by Phat T.)
Code:
obj/Huds
Test_Button
    name = "Test"
    icon = 'button.dmi'
    icon_state = "Test"
    layer = AREA_LAYER+1
    New(client/c)
        screen_loc = "1,1"
        c.screen += src


Essentially, I am stuck here with what to do next.. What I am trying to do is make this button run a proc in game. For example let's say this was a button to turn flight off and on.

I've tried using Click() with usr.Flight() which doesn't bring back an error but also doesn't work once I run the game, which makes me think I'm on the right track.

Feb 18 2015, 12:37 am (Edited on Feb 18 2015, 4:36 am)
Best response
 
obj/Huds
    Test_Button
        name = "Test"
        icon = 'button.dmi'
        icon_state = "Test"
        layer = AREA_LAYER+1
        New(client/c)
            screen_loc = "1,1"
            c.screen += src
        Click()
            usr.Fighting()

mob
    var/figting
    proc
        Fighting()
            if(!src.figting)
                src.figting=1
                src<<"On"
            else
                src<<"Off"
                src.figting=0


Here you have an example
Feb 18 2015, 4:13 am
In proc always use "src", no "usr".
Feb 18 2015, 10:47 am
In response to Marekssj3
Using usr in Click() is fine.
Feb 18 2015, 11:41 am
In response to Marekssj3
Marekssj3 wrote:
In proc always use "src", no "usr".

Fighting() is a mob proc, so usr.Fighting() would be fine in this context.

Now if Fighting() was an obj proc, then you'd be completely right.
Feb 18 2015, 11:48 am
Guys, I'm guessing Phat T's original post had actual usr abuse in it, since he edited it after Marekssj3's post. The post as it stands now is obviously fine though.
Feb 18 2015, 8:19 pm
Yes. I was in hurry and i edited it later.
Feb 19 2015, 3:16 am
Word of advice... Learn the difference between usr and src. It makes a whole world of difference.

usr is what is calling the procedure.
src is what the procedure is called on.

Tutorial on the difference. Since so many people never take the time to just sit down and figure out the difference and test it.

And if you get it wrong, just know all you have to do is reverse the two. A simple way of doing this is copying and pasting it in to a separate file. Then, CTRL+H (replace & find) for src and rename it to u_sr. Then replace and find usr and replace it with src. Then, replace u_sr with usr. This way you switch all instances of the two within a certain location. Once you're done, plop it back in to your sources and test away.
Feb 19 2015, 5:04 am
In response to Xirre
Xirre wrote:
usr is what is calling the procedure.
src is what the procedure is called on.

Well, not exactly. usr is the mob who called the verb. When that verb calls procs in turn, usr gets passed along as a hidden var and keeps its initial value unless it's modified--including by the mob being deleted.

That's why usr often works as expected inside procs, like for instance in Entered() where even Dan was apt to abuse it, but the only procs it's really safe in are those that are guaranteed to be used as or called (directly or indirectly) by a verb--such as Click() is, by client/Click(), in the example above.
Feb 19 2015, 6:28 am
In response to Lummox JR
Lummox JR wrote:
Xirre wrote:
usr is what is calling the procedure.
src is what the procedure is called on.

Well, not exactly. usr is the mob who called the verb. When that verb calls procs in turn, usr gets passed along as a hidden var and keeps its initial value unless it's modified--including by the mob being deleted.

I know there are instances where this statement doesn't hold entirely true. I just fail to remember all of the instance and, by simply using src mainly, I avoid even encountering them nowadays.

That's why usr often works as expected inside procs, like for instance in Entered() where even Dan was apt to abuse it, but the only procs it's really safe in are those that are guaranteed to be used as or called (directly or indirectly) by a verb--such as Click() is, by client/Click(), in the example above.

mob/Login()
    usr.RandomProc()


This would also be another example, am I correct?
Feb 19 2015, 7:01 am
Is there any instance in which using usr would be better than using src? Or where using the src over usr would actually cause an error?
Feb 19 2015, 8:50 am
I've said in the past that Login() is semi-safe for usr, but I really think on the whole it isn't. If you have any kind of character login or save system it definitely isn't, and src is always correct there--and easier to use.

To answer your question, Gtgoku, there are times when src isn't what you want, and you need something else. If you're in a verb and need to know who initiated the verb, usr is the way to go. If you're in another proc, the other object you need should be passed as an argument. For instance:

// good use of usr
obj/item/verb/Get()
    set src in oview(1)
    loc = usr  // move src into usr's contents

// bad use of usr
turf/trap/Entered()
    usr.Die()

// correct version:
turf/trap/Entered(atom/movable/A)
    if(ismob(A))
        var/mob/M = A  // type cast
        M.Die()

In Entered(), you can't be sure it was called by a verb or not--thus usr is incorrect there. The entering object could be an obj or a mob, and is passed as an argument to the proc.

But in that Get() example, it is a verb so usr is valid, and usr refers to the mob who initiated the verb; src would be the obj.
Feb 19 2015, 10:27 am
In response to Lummox JR
Lummox JR wrote:
I've said in the past that Login() is semi-safe for usr, but I really think on the whole it isn't. If you have any kind of character login or save system it definitely isn't, and src is always correct there--and easier to use.

How would it not be safe? I'm thinking of it, and can't see a way it would be bad to use usr there. I thought Login() comes directly from client/New() and client New() would pass both usr and src as the same entity? I, for one, use src in Login() and everywhere else and use usr sparingly (when truly needed). But, I just can't help wonder... at what point do these things change?
Feb 19 2015, 10:49 am
Using my login system as an example, I think usr would be unsafe to use in player/Login in this case:

creation_mob
    parent_type = /mob

    Login()
        var/turf/tile = locate_maptag(MAPTAG_TESTING)
        if(!tile)
            CRASH("Maptag not found.")
            return 0

        client.mob = new/player(tile)
Feb 19 2015, 11:16 am
In response to Xirre
Xirre wrote:
How would it not be safe? I'm thinking of it, and can't see a way it would be bad to use usr there. I thought Login() comes directly from client/New() and client New() would pass both usr and src as the same entity? I, for one, use src in Login() and everywhere else and use usr sparingly (when truly needed). But, I just can't help wonder... at what point do these things change?

Login() and Logout() are called whenever a client is assigned to or away from a mob. When called from client/New(), usr is that mob; but if you were to load a player from a savefile, for instance, usr would be whatever mob initiated the load via a verb.

In character creation systems, it's very common to have a /mob/loginscreen type (the name doesn't really matter) that will let a user go through a character loading process, and that in turn will load them from a savefile. When the load happens, usr is pointing to the old, temporary /mob/loginscreen version they used when they first logged in.

Bottom line: In Login(), usr may not be correct based on the game, but src is always correct there.
Feb 19 2015, 11:44 am
I always feel like I have subconsciously dodged these tricky pieces somehow by not doing things this way... I can't tell if deep down I am smart or just plain lucky. I've never encountered an instance where Login() had usr passed. I've never actually thought of changing things like this.

My guess is that the benefits would be more control over what object has what variables, procedures, and other mumbo-jumbo? I'm talking about with what FKI has done.
Feb 19 2015, 11:53 am
In response to Xirre
Xirre wrote:
My guess is that the benefits would be more control over what object has what variables, procedures, and other mumbo-jumbo? I'm talking about with what FKI has done.

Yeah, that's exactly why I do it.
Feb 19 2015, 11:55 am
In response to FKI
FKI wrote:
Xirre wrote:
My guess is that the benefits would be more control over what object has what variables, procedures, and other mumbo-jumbo? I'm talking about with what FKI has done.

Yeah, that's exactly why I do it.

Good practice. Yet, I'm one lazy bastard.
Feb 24 2015, 5:27 pm
In response to Gtgoku55
Gtgoku55 wrote:
Is there any instance in which using usr would be better than using src? Or where using the src over usr would actually cause an error?

Normally src>usr unless they are separate atoms. In procs, src is best used, but when you want to call to the player when src!=usr, then you would call the proc to usr (usr.proc())

Example:
mob
    something
        Click()
            usr.procName()//in this instance, src=mob/something and usr=player

mob
    proc
        procName()//usr is both src <b>and</b> usr in procName, but only usr in mob/something/Click()
            src << "hi"

So usr becomes src in proc() even though on mob/something/Click() it's usr.

I don't know if this makes any sense so far, so if you need me to clarify just ask! :)