Currently, it is possible to use client.screen as a "holder" for objects that a character has special access to, i.e., when there are verbs/procs that are naturally centered in the object that only a certain player or players should have access to but which cannot be adequately covered using the locational references currently supported as src settings for verbs.
Examples would include: items that have situational commands (a sword in contents can be Equipped, a sword in client.screen can be Unequipped) or admin-level controls over atoms (the ability to delete objects, send mobs to time-out).
Using client.screen in this fashion can conflict with using it in its intended fashion, however, and there may well be scaling issues when using it on a global scale as the game expects objects in screen to need to be drawn.
So what I am suggesting/requesting is a var for client and a parallel one for mob (because some applications would be better tied to the character and some to the player), possibly called access_list, that is simply a list of movables the variable's owner "has access to", for purposes of a src setting "in usr.access" or "in usr.client.access").
This would allow a whole new layer of customization for verb access, and allow games that have big, complicated layers of admin verbs to simplify their implementation considerably.
ID:2155092
Oct 3 2016, 8:04 am
|
|||||||
| |||||||
That's a fair point. This is a feature I would like for my own purposes for multiple reasons, and I thought I'd try casting a wider net for applicability.
|
I agree with this idea. Architecturally sometimes you want to grant/deny access to verbs in a packaged set; you can create holder objects on each person individually, but it would be nice to have a central object that you just grant or deny access to.
It's especially nice if you modify the verb list on the package object; if you have do that once for each holder object it's meaningless duplication. In my case I have a logging controller that only has verbs to show logs if those logs have anything in them. It's entirely feasible to do without, just ugly. |
That's not any commentary on the merits of this request for other purposes, of course. I'm just thinking that regarding the verb performance issue for right-click menus and such, it won't help those cases.