[SPIGOT-4327] Can't use plugin commands in /execute command anymore Created: 29/Aug/18 Updated: 04/Mar/20 |
|
| Status: | Open |
| Project: | Spigot |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Phoenix616 | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 7 |
| Labels: | 1.13, commandblock | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Version: | git-Spigot-2440e18-1486c29 (MC: 1.13.1) | ||||||||||||||||
| Guidelines Read: | Yes | ||||||||||||||||
| Description |
|
In 1.12.2 and previously it was possible to use the execute command to run plugin commands as a specific player (with /execute @p ~ ~ ~ <plugincommand>), this is no longer possible with 1.13(.1? Not sure if it was an issue previously too). Tested with the new command format /execute as @p run test outputs [12:39:11] ...as @p run test<–[HERE] in the command block. (test is a command of a test plugin that I made, same issue happens with any other command) |
| Comments |
| Comment by Byron Marohn [ 07/Oct/18 ] |
|
I finally found a good solution to this problem through an external plugin - https://github.com/JorelAli/1.13-Command-API This plugin seems to do pretty much everything I wanted - it gives you a nice way to register commands with Minecraft's Brigadier system, and command registered in this way work everywhere - command blocks, functions, /execute, etc. It's awesome. You also get all the awesome tab-completion and suggestions from the new commands system. Also - finally a way to have all the standard @e, @a, etc. targeting selectors working in plugin commands! So great. However - this system bypasses the Spigot plugin registration entirely by registering commands directly with Brigadier. This requires refactoring your plugin commands. However, in my experience its vastly superior and removes a lot of lines of argument parsing/checking code that was previously needed without it. Hopefully this helps someone else who stumbled across this thread looking for similar features. Maybe someday something like this could be integrated into Spigot - but as md5 says above, it does seem like "rewriting the entire command system" (or at least a totally new API). |
| Comment by Byron Marohn [ 26/Sep/18 ] |
|
Well, crap. We also found this very useful, and much easier to use than parsing target selectors manually (or via library). Is this feature not the entire reason that ProxiedCommandSender exists? Is there even a way to get a ProxiedCommandSender instance without being able to chain a plugin command off of /execute? A quick grep through the spigot source indicates that it still exists but isn't really connected to anything. I spent a little time digging through the obfuscated vanilla code... it looks like at parse time it precompiles the commands using some opaque mojang brigadier library. Perhaps there's a way to make any custom bukkit plugin command "compile" successfully to some bukkit object that will satisfy the parser and can be invoked later to run the command in the way bukkit commands are invoked now? That would avoid a horrific refactor of the bukkit commands system... I'm usually just a spigot consumer, not a developer - so I could be totally off base here. This issue matters a lot to me though, so I'm particularly motivated. Any thoughts would be appreciated. |
| Comment by Doge bogey [ 05/Sep/18 ] |
|
Someone please add this! |
| Comment by md_5 [ 29/Aug/18 ] |
|
Yes, Bukkit should have never allowed mixing of Vanilla and Bukkit things - it completely breaks any map etc written for Vanilla as soon as plugins are added. This is essentially a wontfix for me, I think it is working as designed. If you (or someone else) want to add this as an optional "feature" then feel free, but it almost certainly involves rewriting the entire command system. |
| Comment by Phoenix616 [ 29/Aug/18 ] |
|
How is that not a bug when it worked previously? Oo |