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?
ID:151664
Sep 23 2009, 3:02 pm
|
|
Sep 23 2009, 5:44 pm
|
|
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 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 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() 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 (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() |