[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: PNG File 2018-08-29_12.40.17.png    
Issue Links:
Duplicate
is duplicated by SPIGOT-5611 /execute [...] run plugincommand Resolved
Relates
relates to SPIGOT-4295 Allow Spigot Command Block Selectors Open
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

Generated at Thu Dec 18 10:06:44 UTC 2025 using Jira 10.3.15#10030015-sha1:909cc43d292ca09e774c1a243d9819be3f2628cd.