ID:2077911
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
There currently exists no way to differentiate between a verb clicked in a panel, a verb used in a statpanel, a verb used via an input, or a verb used via the command menu.

I'd propose that a new verb setting be added that prevents them from running when called in certain ways. This would return the inaccessible error message you see when a verb is entered in an invalid way.

This value could have the following values:

set origin = ORIGIN_PANEL (1) //called only via a verb panel
set origin = ORIGIN_POPUP (2) //called only via a right-click context menu
set origin = ORIGIN_COMMAND (4) //called only via the command prompt
set origin = ORIGIN_INPUT (8) //called only via an input element
set origin = ORIGIN_MACRO (16) //called via a macro

By default, all verbs would be set to 31, for callable from anywhere.


Additionally, it would be nice to know how we got to the current point of execution. Verbs could transmit their source of origin via two values:

1) The name of the interface element (if any) involved in the last verb or verb-like proc (mouse foo) sent to the user.

2) The type of client-side hook that called the last verb or verb-like proc (mouse foo) processed.

proposed names would be:

client.command_origin
client.command_element

command_origin would match one of the above defined bitflags.

command_element would be the interface element associated with the verb call.

In the case of statpanels, it would return the info element's id followed by a ":" and the name of the panel the verb was clicked on. For instance: "mainwnd.statpanel:Combat"

In the case of input elements, it would return the input element's id.

In the case of a right-click context menu, it would return either a statpanel string like a regular statpanel verb if the context originated in a right click, a grid if the right click originated in the grid, the map element if the right click originated on the map, etc.

In the case of a client-side winset verb invocation, it would return the element that initiated the .winset()

In the case of a server-side winset verb invocation (...Why?), it would return "winset"

In the case of a macro, it would return either the id of the macro set or the macro set plus the macro id if the macro has an id.

For a command prompt call, the value would simply be null.
I think restricting access via bitflags would be the easiest part of this to handle. Sending info to the verb would be less so, because it'd be a new internal var like usr that would have to be handled. (Worst-case, it could just be assigned when the proc is called and not carry over into procs and pseudo-verbs like usr does, but the downside is that this adds to proc overhead.)

Handling the origin info as global vars would certainly be easier, although it has the disadvantage of not persisting through a sleep/spawn.
Does this prevent them from just running, or from showing as well?

This would be useful for hiding some right click verbs that cannot be physically hidden through any other way, like if you are inside the atom of the verb.