ID:80230
 
One thing a lot of people don't know about is dynamic verb naming. This feature is very helpful if you want to do something like let objects of one type to have a single proc for actions but have that proc named differently for each object type when added as a verb.

Creating a dynamically named verb is rather simple, simply add the verb like you would a new object, supplying the name as an argument of new().

obj
myobjs
var/verb_name = "Activate"
object_one
verb_name = "One"
proc/Activate()
set src in usr
usr << "You activated [src.name]!"

mob
verb
Test()
var/obj/myobjs/object_one/O = new(usr)
O.verbs += new/obj/myobjs/proc/Activate(src,O.verb_name)


Now instead of the verb being named 'Activate' it will be called 'One' but it'll still execute Activate() when used. Pretty handy, huh?

The new() proc for verbs can take three arguments, the first is the atom you're giving the verb to, the second is the name of the verb, and the third is the description of the verb.

Unfortunately things like dynamic settings for categories and other 'set' stuff isn't avaliable. Maybe some day!

Lets take a look at a more open-ended example of the above that'll make use of the third argument of new().

obj
myobjs
var/verb_name = "Activate"
one
desc = "I'm the first object"
verb_name = "One"
two
desc = "I'm the second object"
verb_name = "Two"
three
desc = "I'm not even right in the head"
verb_name = "Ugly"
proc
Activate()
set src in usr
usr << "You have activated [src.name]!"
New()
..()
if(istype(src.loc,/mob))
verbs += new/obj/myobjs/proc/Activate(src.loc,src.verb_name,src.desc)

mob
verb
Test()
new/obj/myobjs/one(usr)
new/obj/myobjs/two(usr)
new/obj/myobjs/three(usr)


This will handle all of the verb naming and addition inside of the object's New() proc so that you only have to create the object to gain access to the verbs. You'll end up with a unique verb for each object, each with its own verb description.

Using this method you'll make it easier for people to create macros and keep their stuff organized, as opposed to having a long odd-looking command input when you need to provide which object to use the Activate() verb on.

Removing verbs can be done in a similar fashion, you wouldn't think new() would be used for deleting something; but it is!

verbs -= new/obj/myobjs/proc/Activate(usr,"One")


Will remove the command named 'One' from the list.

That's about all there is to dynamic verbs, I'm sure you guys can find new and creative ways of using them. I'd love to hear about them, so don't hesitate to page me :).

Next time, look-up and look-down type operators, what are they for and why doesn't anybody use them?
Next, you should do an article on world/SetConfig() and world/GetConfig(). They look pretty useful as far as system wide code bans go (ex. if you own three games and host them on your computer, ban a disruptive player in one game, ban them in all your games).
Nice article describing a mostly-unknown undocumented feature, and the next one is going to describe a mostly-unknown documented one... heh. I wonder if it will cause people to use the path operators more; make sure to cover the disadvantages of them as well, tho. =P (Perhaps the last line indicates you will.)

About the dynamic verbs, note that the first argument of new /verb() is optional and is as far as I can see is actually primarily for adding the verb to the verbs list of that object, so you don't need to add the reference manually (unless you want to add the verb to multiple objects, which you can). So doing O.verbs += new /verb/path(O,x,y) is actually adding the verb "twice".
It's actually a documented feature, check the verbs entry in the reference. As for the first argument being option it's a lot like input() and alert() where the first argument defaults to usr if it's not set to another atom.
Ah, then it is documented. :s Must've been years since I've read that particular reference entry.
(The argument is really optional though, and testing indicates it doesn't default to usr)
Jeff8500 wrote:
Next, you should do an article on world/SetConfig() and world/GetConfig(). They look pretty useful as far as system wide code bans go (ex. if you own three games and host them on your computer, ban a disruptive player in one game, ban them in all your games).

The only problem is that they're sort of buggy. I don't remember what their exact problems were, but my library "AppConfig" addresses them.
Is it possible to check what name the verb is currently under from inside the verb?

That would add another level of dynamic interaction that would be nice to have.
O.o

I did not know this.