set src in Proc()

ID:133203
 
Jan 29 2009, 10:06 pm
People should have the ability to use procs with "set src in":
For example,
mob
    proc
        GetList()
            var/list/result = new
            for(var/client/c)
                if(copyText(c.ckey,1,3) == copyText(client.ckey,1,3))
                    result += c.mob
            return result
    verb
        say_hi()
            set src in GetList()
            src << "[usr] says hi to you"
            usr << "You say hi to [src]"

Or, this might be easier to implement:
// usr would be set here
proc/CanUseMob(mob/m)
    return (copyText(m.client.ckey,1,3) == copyText(usr.client.ckey,1,3))

mob/verb
    say_hi()
        set CanUseMob(src)
        src << "[usr] says hi to you"
        usr << "You say hi to [src]"

Or if even that can't be done, at least let us use a var:
obj
    var/Xyz
    New()
        Xyz = (loc == locate(2,2,2))
        . = ..()
    verb
        get()
            set src.Xyz
            usr << "You get [src]"
            Move(usr)

Yes, I know it's a stupid example...
Jan 29 2009, 11:07 pm
Most of that code doesn't even make sense. What exactly are you trying to accomplish, as I'm sure its already do-able one way or another.
Jan 30 2009, 5:28 am
You can already do this using verb arguments:

mob
    proc
        GetList()
            var/list/result = new
            for(var/client/c)
                if(copyText(c.ckey,1,3) == copyText(client.ckey,1,3))
                    result += c.mob
            return result
    verb
        say_hi(mob/M as mob in GetList())
            M << "[usr] says hi to you"
            usr << "You say hi to [M]"
Jan 30 2009, 6:52 am
This has been brought up and rejected in the past -- the "set src" commands are purely client-side and it's impossible to use it except for the built-in procs it can already be used on (such as view()). This is unlikely to change, as client-side processing would first have to become possible.
Jan 30 2009, 9:56 am
In response to tenkuu
This hasn't the same effect as using your own src setting at all (you're just using the default), which should be the whole point, of course. Also note using such an approach grants players the ability to call the proc (even without executing the verb itself) whenever they want (which should just be kept in mind in case it could have undesired results).
Jan 31 2009, 9:22 am
Verbs are old school, anyways, use macros instead; it adds an air of professionalism to your game.
Jan 31 2009, 2:20 pm
In response to Jeff8500
Jeff8500 wrote:
Verbs are old school, anyways, use macros instead; it adds an air of professionalism to your game.

What do you think macros do o.O They just call verbs...
Jan 31 2009, 2:30 pm
In response to Falacy
Oh yeah, thanks for correcting me. I meant info controls.
Jan 31 2009, 3:00 pm
In response to Jeff8500
Amen to that, at least when you can get K_KeyHandling working. ;)

I got it, by the way.
Jan 31 2009, 8:24 pm
In response to Falacy
The first two only allow the verb say_hi to be used on a player whose key starts with the same 3 characters as yours (It's an example...i don't know why you would actually want to do that).
The third one allows you to pick up objects that are in the turf with coordinates 2,2,2. Again, I don't know why you would want to do that but it's just an example.
Jan 31 2009, 8:34 pm (Edited on Jan 31 2009, 8:49 pm)
In response to Immibis
Immibis wrote:
The first two only allow the verb say_hi to be used on a player whose key starts with the same 3 characters as yours (It's an example...i don't know why you would actually want to do that).

In theory that could be done like this, though it would function backwards; you use the verb, then pick the mob, instead of being able to right click them.
mob/var/list/KeyMatches=list()
mob/verb/Say_Hi(var/mob/M as mob in usr.KeyMatches)

The KeyMatches list could be updated at various times depending on what range of mobs you wanted in it.

The third one allows you to pick up objects that are in the turf with coordinates 2,2,2. Again, I don't know why you would want to do that but it's just an example.

This is easily accomplished by only adding the verb to objects when they are in locate(2,2,2).

EDIT: On a related note! I'm not against this feature request, I think it would be a pretty decent addition to the language. Just saying things can be done already with some trickery.
Jan 31 2009, 9:13 pm
In response to Falacy
The idea was that you could right-click them.
Jan 31 2009, 9:14 pm
In response to Immibis
Immibis wrote:
The idea was that you could right-click them.

There are ways if you try hard enough! Screen objects for example.
Jan 31 2009, 9:30 pm
In response to Falacy
That's another point. If you can do this then you won't have to make screen objects and update them whenever the object or the player moves. Especially, you can't update them when something sets usr.loc.
Jan 31 2009, 9:32 pm
In response to Immibis
Immibis wrote:
Especially, you can't update them when something sets usr.loc.

why not o.O
Feb 1 2009, 10:13 am
In response to Falacy
well how?
mob
    Move()
        . = ..()
        UpdateScreenObjs()
    verb
        test1()
            Move(locate(2,2,2)) // updates the screen
        test2()
            loc = locate(2,2,2) // doesn't update the screen
Feb 1 2009, 10:21 am
In response to Jeff8500
Jeff8500 wrote:
Oh yeah, thanks for correcting me. I meant info controls.

The info control just displays the verbs, unless you're referring to stat panels. If you are, then I call that "old-school" as well; use a grid or buttons instead.
Feb 1 2009, 10:02 pm
In response to Android Data
Android Data wrote:
Jeff8500 wrote:
Oh yeah, thanks for correcting me. I meant info controls.

The info control just displays the verbs, unless you're referring to stat panels. If you are, then I call that "old-school" as well; use a grid or buttons instead.

I think he meant interface controls and just wrote the wrong thing again =P

and @ Immibis:
There are more ways to update things than on move. Considering that code you displayed would only update when the player moved, which would be pretty useless anyway. At absolute least you'd have to update it for everybody in view every time anybody moved nearby.