Is usr.group still available as a src setting? The blue book says that usr.group is a possible src setting, but the online reference does not.
One of the problems with verbs is that the src settings are limited and filtering a verb argument causes some verbs to be accessible when they shouldn't be. If you can put the src in a mob's contents, you can use "set src in usr" (i.e. "set src in usr.contents"), but there are many things that you don't want to add to the contents list especially if you want it available to many people. Things can only be in one contents list at a time.
It would be useful for there to be a special list on mobs made specifically for verb src settings. Then you could create the verb with "set src in usr.verblist" to access the item's verbs:
example:
manalink
var
manalevel
list/members = list
verb
bind(mob/M in oview(1))
set src in usr.verblist
members += M
M << "[usr] binds with you in a manalink."
usr << "You bind with [M] in a manalink."
M.verblist += src // let the new member access this manalink's verbs
draw_mana(mana as num)
set src in usr.verblist
mana = min(manalevel,mana)
manalevel -= mana
usr.mana += mana
usr << "You draw [mana] mana from the manalink"
feed_mana(mana as num)
set src in usr.verblist
mana = min(usr.mana,mana)
manalevel += mana
usr.mana -= mana
usr << "You feed [mana] mana into the manalink"
ID:137016
 Mar 10 2002, 10:41 am
|
|
It's strange how "set src in usr" (also oview ect.) never really settled well with me. I suppose it's because it sounds like the usr is allowing what is in its contents to be the src even though the usr doesn't "own" the verb. It sounds like it's giving away something it doesn't have.
What sounds more natural to me is: set loc as usr //same as "set src in usr" or instead of "set src in oview(1)" set usr in oview(1) That gives me the image of the object giving away access to it's own verbs instead of someone walking by and saying "I'll let you be the src for your own verb." This is how "set src in usr" would make sense to me: mob Drop() set src in usr That says it will select something in the usr's contents and set it as the src. If I had never used these statments before (or seen examples and explanations) I would say, "What usr? No one has clicked the verb yet..." I can definetely see where the current syntax comes from though. "set src in oview(1)" makes sense because oview() defaults to arround the usr but it just doesn't seem very intuitive. | |
The thing is, though, the src is completely passive... it's the usr that uses the verb.
obj/sword/verb/get() set usr in oview(1) This means, if the sword can see you on the ground next to it, you can get the sword... tell me again why this makes more sense? | |
Well, ok, when you put it that way it does sound funny.
When I start thinking about how I would do it my train of thought leads back to the way they're doing it. I guess I was just thrown off when it took me a few minutes to figure out what Shadowstarke was doing. Usually I can scan a piece of code and get the general idea quickly but I had a brain stutter on that one. | |
Tom wrote:
I believe usr.group is a valid src setting, but you'll want to test that out and let us know for sure :) Yes, "set src in usr.group" is still valid. You might want to update the reference entry for verb settings. :) The problem is that mob.group only accepts mobs. Given that the only default BYOND behaviour involving group is to swap places on bump it's understandable. You could expand that to include any atom/movable, but fixed loc atoms and custom datums would conflict with the default behaviour. I totally agree on your followup point-- DM definitely needs some sort of client-side list that can be used for this purpose. Lexy made a suggestion a while back about perhaps having a correlation between the statpanel lists (set src in statpanel(..)) and the verb accessibility, since those are already available client-side, and I thought that was a pretty good idea. We'll keep thinking about it. I'd still like to have a client side anything list specifically for verb src settings. "set src in statpanel" is also a good idea. Lexy is welcome to the tatoo for that and many other great ideas. ;) Until then, I can impliment my datum as a specialized mob and add it to group. | |
Nadrew wrote:
And I can get on that says "Lexy had a good idea!". I'm curious... do you try to reply to every one of Lexy's posts that are silly? ;-) | |
Spuzzum wrote:
I'm curious... do you try to reply to every one of Lexy's posts that are silly? ;-) <sarcasm>Yes, I live to do that, Spuzzum. </sarcasm> | |
Shadowdarke wrote:
One of the problems with verbs is that the src settings are limited and filtering a verb argument causes some verbs to be accessible when they shouldn't be. One nice little hack that might work for you is that you can do <code><nobr>set src in client.screen</nobr></code>. You don't have to set the object's screen_loc, so it doesn't necessarily have to be visible anywhere; it just has to be in the client.screen list. | |
Dan wrote:
One nice little hack that might work for you is that you can do <code><nobr>set src in client.screen</nobr></code>. You don't have to set the object's screen_loc, so it doesn't necessarily have to be visible anywhere; it just has to be in the client.screen list. Perfect! Thank you, Dan. :) | |
I believe usr.group is a valid src setting, but you'll want to test that out and let us know for sure :) I totally agree on your followup point-- DM definitely needs some sort of client-side list that can be used for this purpose. Lexy made a suggestion a while back about perhaps having a correlation between the statpanel lists (set src in statpanel(..)) and the verb accessibility, since those are already available client-side, and I thought that was a pretty good idea. We'll keep thinking about it.