ID:151664
 
http://www.byond.com/members/ DreamMakers?command=view_post&post=80230

Is there any way to detect what name the verb is being called under?
Not that I know of, but you can always set another variable when you add the verb, something that matches the name.
In response to Nadrew
Nadrew wrote:
Not that I know of, but you can always set another variable when you add the verb, something that matches the name.

But if you have two verbs created from the same source the variable wouldn't be able to distinguish which one you are using.

This isn't really a big deal to me, more of a 'what-if' situation that I can't even think of needing.
In response to AJX
You can always store the dynamic verbs in objects or datums (not sure how reliable non-atoms are with container verb handling). So each dynamic command is actually an object in your contents that has the verb, instead of the verb belonging directly to the player.
In response to Nadrew
Nadrew wrote:
You can always store the dynamic verbs in objects or datums (not sure how reliable non-atoms are with container verb handling). So each dynamic command is actually an object in your contents that has the verb, instead of the verb belonging directly to the player.

Thats what I was thinking. I believe you'd have to use a child of atom/movable instead of datum because datums don't even inherently have a 'loc' var. Which tells me putting them in contents would probably break something somewhere.
In response to AJX
AJX wrote:
Thats what I was thinking. I believe you'd have to use a child of atom/movable instead of datum because datums don't even inherently have a 'loc' var.

Yep, contents is tied to the movement system and you can only put atoms in it - other objects don't belong there.

Which tells me putting them in contents would probably break something somewhere.

Trying to add any non-atom value to contents simply won't work. Like most (all, IIRC) built-in, special lists, it rejects inappropriate values, so trying to add a non-atom to contents or screen, or a non-mob to group simply fails (some lists produce a runtime error when that happens, some do not).



As for keeping track of the properties of custom verbs, I don't see the need to attach the verbs on different objects in order to do that at all, that's just overcomplicating things. If procedure paths were a valid associative list key like normal paths are, then you could even just use a simple, global associative list do the trick, but unfortunately they aren't. Still, no need to attach the verb on different objects and mess with players' contents, attach it on your intended target still and just use a datum to keep track of its data. Since I doubt you can override New() for verbs through any trick seeing as they're not real datums or even real objects, you'd just redirect your calls to make new verbs to your own function instead:
verb_tracker
var/verb_path

var/verb_name
var/verb_desc
New(p,n,d)
verb_path = p
verb_name = n
verb_desc = d

tag = "tracker_[n]" //also serves to prevent garbage collection: \
you could instead add all verb_trackers objects to a global list


proc/new_verb(type,attachobject,name,desc)
var/V = new type(attachobject,name,desc)
new /verb_tracker(type,name,desc)
return V

Then you could use the objects to get various data back later - either keep a reference to the tracker object instead of the actual verb (so change the above return to return back the tracker) and then read its vars, or scan through all trackers when you need the info:
proc
find_verb_name(verbpath)
for(var/verb_tracker/T)
if(T.verb_path == verbpath)
return T.verb_name
find_verb_desc(verbname or verbpath)
//you get the drill, pretty much the same as previous

find_verb_path(verbname)
return locate("tracker_[verbname]")


However, there's no need to manually keep track of these properties in the first place, because you have the ability to directly read those properties of all procedures by using their reference (which is a procedure type path):
verb_holder/verb/Hello()
set name = "My name"
set desc = "My desc"

mob/verb/SeeProperties()
var/procedure = /verb_holder/verb/Hello
src << procedure:name //outputs "My name"
src << procedure:desc //outputs "My desc"

new /verb() returns the verb's reference back, so you can store it and read its properties anytime - as well as use that reference to add/remove the verb from any verbs lists later on.
You could avoid the use of the : operator by falsely typecasting the var holding the type path, for example as an /atom or /obj, or most accurately in a dummy class made for just this purpose:
procedure
var
name
desc
category
//hidden
//popup_menu
invisibility
//src
//background


(The commented out vars are procedure properties, but they can't be read using this method, so you shouldn't include them in the dummy datum to prevent you from using them, in the same style as the safety of normally using the dot operator in the first place.)
Then when you want to access a proc (or verb)'s properties, it looks neater:
test/verb/Properties()
set name = "Properties() name."
set desc = "Properties() desc!"
set category = "Prop's category"
set invisibility = 5

mob/verb/SeeProperties()
var/procedure/P = new /test/verb/Properties(,"NEW NAME","New desc")
src << P.name //outputs "NEW NAME"
src << P.desc //outputs "New desc"
src << P.category //outputs "Prop's category"
src << P.invisibility //outputs 5