Added ProxyDefineCommandsEvent #3642
Conversation
|
Fixed an incorrect reference comparison |
| @@ -743,13 +745,32 @@ public void handle(Respawn respawn) | |||
| @Override | |||
| public void handle(Commands commands) throws Exception | |||
| { | |||
| final Collection<Map.Entry<String, Command>> unmodifiedCommandMap = bungee.getPluginManager().getCommands(); | |||
| final ProxyDefineCommandsEvent event = new ProxyDefineCommandsEvent( server, con, unmodifiedCommandMap ); | |||
There was a problem hiding this comment.
I think there is a design question about whether the event includes all commands or just bungee commands. Including all commands would give more flexibility (like the Spigot event https://hub.spigotmc.org/javadocs/spigot/org/bukkit/event/player/PlayerCommandSendEvent.html)
There was a problem hiding this comment.
Ahh you're right, I forgot that it only has the bungee commands. The other two places that you left comments are because of that.
Supporting non-bungee commands doesn't add extra features if they can edit downstream commands on the downstream, but it would be convenient to have it in one place.
As it stands the event handler gets complete information with the Command type. To support non-bungee commands we would have do one of the following:
- Limit the information they get to support both sources (maybe even just a key).
- Create a new union type of bungee (Command) and non-bungee (brigadier node or a new type).
- Add a second collection to the event containing only the brigadier node or a new type.
I don't like any of those options just to get plugin convenience so, unless you can think of another or you disagree, I'm in favour of committing as is but with the removal of the additional assignments of modified.
In migrating from waterfall from bungeecord, this was the only missing API that my network is missing. I've re-implemented it here without directly copying - only the surface API is the same.
We use it to hide commands from tab completion to improve searchability for players, whilst allowing them to have permission to use the command.
Why give them permission if it's hidden? The command is triggered via a button in chat or via
Command.execute; it is never triggered manually but it isn't a problem if they somehow discover it.