Dynamically created verbs act like they are static verbs when added to an objects verb list

ID:2034698
 
Feb 10 2016, 11:28 pm
BYOND Version:509
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 48.0.2564.103
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Basically I want to make a screen object have a verb, and add it to the right click of another atom, normally this wouldn't be doable (how does it know what insistence of the screen object to run the verb on) but with dynamic verbs, you can attach the verb to a src:

/obj/thing/New()
  var/verb/button_verb = new /obj/thing/proc/verb_action (src, "NAME_HERE", "DESC_HERE")


Now that will work correctly, it will attach that dynamic verb with its special snowflake name and desc to that object.

but if i wanted to do other_obj.verbs += button_verb to make a dynamic system for control over right click options, that doesn't work, the proc will run as if it was typed to the other obj then runtime over type errors.

It seems like in this use case, the src given in the verb's New should override the type path of the object that the verb is attached to using verbs += when running the verb.

Or we just need a better system for handling rightclick control.

In my case, we have a dynamic system for making screen objects for doing actions on objects, since in general, hud icons are better than verbs.

I want to keep verbs, but the code maintainers don't want making action buttons requiring making the action button, then adding a verb to do the same thing, they want to remove verbs for objects in favor of action buttons.

I started on this quest to make the action button system dynamically add verbs, but i run on this snag.

Feb 11 2016, 1:05 am
It's been so long since I've looked into dynamic procs I'm not even sure where they're mentioned in the reference or the guide. I'd like to review any documentation on that.

Right now I'm not sure if this is actually a bug, or if it's more of a feature request.
Feb 11 2016, 7:33 am
I don't think they're in any official documentation but they sure as hell are in the red book.
Feb 11 2016, 7:44 am
It is documented under the "verbs" ref entry and this old Nadrew post.

Whatever is in the Red Book is some pretty bad documentation on my part, I've been meaning to change up the Red Book a bit to be more demo-ish.
Feb 11 2016, 9:24 am
Okay, this is where I'm stumbling:

MrStonedOne wrote:
but if i wanted to do other_obj.verbs += button_verb to make a dynamic system for control over right click options, that doesn't work, the proc will run as if it was typed to the other obj then runtime over type errors.

Runtime type errors are pretty much strictly from type mismatches, or trying to access a var that the object doesn't actually have. None of those would be expected to come up in this kind of scenario. Is there something I'm missing?
Feb 11 2016, 9:44 am
This is the behavior that I would expect. The src of a verb shouldn't just suddenly change to the src of the verbs list it was added to. This is what usr is for. If you want this to happen, then simply use new() to set the src yourself.

If this were changed, it would remove a very useful hook to other objects, and could certainly break some games; mine included.
Feb 11 2016, 11:39 am
The src of a verb shouldn't just suddenly change to the src of the verbs list it was added to.

But thats exactly what is going on, its changing to the src of the verbs list it was added to, i want to fix that.


Okay, this is where I'm stumbling:

Lummox, if i do

/obj/thing1
  var/var1 = 0
  var/obj/thing2/thing
  proc/blah()
    var1++
  New()
    thing = new()
    thing.verbs += new /obj/thing1/proc/blah (src, "Press me!" "")
/obj/thing2
  var/var2 = 0


and activate that verb, it will runtime saying could not read /obj/thing2/var/var1
Feb 11 2016, 11:49 am
Ideally i'd want it to respect the given src in new() and run it in the context of src, not the thing the verb was added to.

This might be more of a FR then a BR, but the documentation on it is too short to know.

And i'd reckon that changing the type context of a proc at runtime isn't intended (unless dan did this, then it most likely was intended) (that being said, keep it for if src is a different type, i can see some use cases where changing the type context of a verb would be handy, (and while your in there, could you make it so src could be a /datum/ so i don't have to use an obj as a place holder))
Feb 11 2016, 12:04 pm
The behavior you're describing is totally correct, though. When a verb is added to an object's verbs list, src is the object itself. What you're trying to do is call the verb with a different, pre-defined src, and procs simply don't work that way.

I think what you're really looking for is some kind of equivalent to the JavaScript bind() function, which can call a function with a specific "this" object and some of the arguments already filled in. At the moment we have nothing like that, though.
Feb 11 2016, 12:09 pm
but in the case of dynamic verbs, don't you think it wise to respect the given src?

Hell nothing would have to change in the protocol or the compiled code, the server would handle the translation
Feb 11 2016, 12:11 pm
I was misunderstanding this problem. It's better not to change this, or you could end up with either disappearing verbs or verbs with null srcs.

The workaround is to simply add the object you want to be the src, to the contents of the user, then add the verb to the verbs list of the object. This will give the usr access to the verb, while maintaining the src. This is how I have always done it.

I think a much better feature would be to add verb support to datums in general, and not just atoms. An interface doesn't necessarily require a graphical object. Data objects would be much more efficient containers for verbs.

I should also point out that call() will let you call procs or verbs of a different src.
Feb 11 2016, 12:12 pm
It gives you the ability to have a bind(), the ability to do more dynamic right click menus, more dynamic verb control in general and I doubt it would break much with pre-existing projects.
Feb 11 2016, 12:13 pm
The workaround is to simply add the object you want to be the src, to the contents of the user, then add the verb to the verbs list of the object. This will give the usr access to the verb, while maintaining the src. This is how I have always done it.

That workaround doesn't work, as this system HAS to support verbs when the proc on the object to call is not known at compile time (overridden procs in child objects)
Feb 11 2016, 12:18 pm
In response to MrStonedOne
Who said you have to know the object at compile time? You can add it to the contents at any time during runtime. I don't quite understand what the problem is.
Feb 11 2016, 12:20 pm
We have an action button datum system, it handles giving the user a hud object, and binding the click to the object.

For each button, you make a child of the datum, and have the object create that.

Because objects can have multiple action buttons (and many do) I can't call a proc on the object, i have to call a proc on the datum (trigger()) and let the child handle calling the proc on the object.

If i put it on the hud object, then it doesn't show up in the right click of the target object.

If i put it on the target object, then i don't know what proc to call, and i can't define a base proc to call as objects support an unlimited number of action button datums, how would it know what one is clicked?
Feb 11 2016, 12:29 pm
Override New() for the parent object type, to maintain a list of all created child instances, then add all of them to the contents of the usr.
Feb 11 2016, 12:32 pm
That doesn't solve it, one, there is no such thing, and two, i still have no way of knowing what verb was triggered in the verb code, three these objects are world items, they exist on the map and are picked up, four, objects add and remove action buttons depending on state
Feb 11 2016, 12:36 pm
All of that sounds like some kind of design flaw, but I can't tell for sure without seeing the code.