Inhibitors

[LoganDark]

For example, hiding admin commands from the everyday user if Cmdr is being used as a gameplay element as well as an admin console. Maybe a BeforeRun hook could be used for this, maybe the help command could read from context.State.Hidden if it exists, or maybe context.State.Whitelist?

A custom help command can do this, but what about the default one?

[LoganDark]

Another related concept is the ability to hide commands entirely from some clients, i.e. make client-side Cmdr believe the admin commands don't even exist.

[evaera]

I agree that this is definitely a useful feature. Context doesn't work here because command contexts only represent a single instance of that command running, not the command in general.

I'm thinking about adding another hook for this: BeforeCommandRegister. The idea would be that you would add this hook on the client, and you'd be able to examine the static command definition (this is the same thing that the filter argument for RegisterDefaultCommands receives). Then you could return true to interrupt the command registration so that client-side Cmdr would never register it.

[LoganDark]

command contexts only represent a single instance of that command running

Yes, exactly. Imagine a user being granted admin privileges. Then the commands will be shown in the help command the next time they run it. I think evaluating which commands should be hidden every time help is run is a better idea than providing a permanent block-list. However, being able to re-register a blocked command (see below) is now my preferred solution.

Then you could return true to interrupt the command registration so that client-side Cmdr would never register it.

That sounds good. How would you re-register it later though, for example in the case of a permissions raise?

[evaera]

That's a good point. The registration hook wouldn't be as versatile for that.

When originally designed Cmdr I had a feature outlined in my notes called "inhibitors" -- basically functions that would run and prevent the user from seeing commands. These eventually evolved into the hook system that exists today. However, I think inhibitors could fit into this hook system. Instead of blocking registration, there could be a hook called BeforeDisplay that would be integrated with the calls for autocompletion and the help command. If you return true from this hook it'd make it so that command doesn't appear in those UIs. This would also allow for on-the-fly permission updates.

The downside of something like this though is of course that the developer will be forced to create their own systems to keep the BeforeRun hooks on the server and the BeforeDisplay hooks on the client in sync. (They could vary, but that doesn't seem like a very common use case). However it might not be possible to design a system that solves that problem without making too many assumptions. Perhaps it's a job best left to the developer.

[LoganDark]

The server should decide which commands the client sees. My idea is this: You tell Cmdr on the server to hide/unhide commands, Cmdr will send a request to the client, and the client will unregister/register commands accordingly. Commands that you hide before registering never get sent to the client in the first place.

Requests to run hidden commands will be met with a command not found message. However, there could possibly be some "blind" commands that the client doesn't see that the server accepts... Who knows?

Of course, a hook in the help command would be nice too.

[LoganDark]

#75 would fit well with this, being able to switch command sets might be a useful feature

[LoganDark]

Telling the client to register/unregister from the server is a good way to approach this, IMHO. There can still be hooks on the client to control display of commands, but the server should be able to control it too.

[autonordev]

IMO making this work in a way that satisfies everyone's needs would require a massive overhaul of how Cmdr works. This type of behaviour desired is currently possible (although there's no way to 'take back' a registration) although it does require a bit of work.

I considered closing this issue but I'm going to recategorise this as 'future' for now: it's something that we might look at again in the future but have no intention of doing so currently.