As in calling Mojang commands and getting called from command blocks? I don’t see why the latter is required (it should just be transparent). The earlier I could agree with, however.
It’s only really an issue if we decide to implement vanilla commands ourselves, which we probably won’t because it’s too much work.
If you’re implementing your own commands, it’s not too hard to do either. Both WorldEdit and CommandBook have supported macros for a long time, particularly with WE since MC Alpha. If you’re parsing arguments yourself, you merely just have to resolve them into whatever object you need. If you use Intake, then you can just bind the Player type to your custom and fancy argument parsing code.
With WorldEdit 6, I bound any numeric types to an expression evaluator, so any command that’s post-Intake will accept math expressions. i.e. /up 3.326*pi
We might want to provide some API to reuse Mojang’s macro resolver so people don’t have to rewrite their own implementation of it.
Mojang’s command block syntax is not generic, the commands themselves have a say in it. In vanilla /msg @a @a sends one message to every player with the contents of the message being every player on the server. In CraftBukkit because we hacked command block syntax support in that sends one message per player to every player with the contents of each messaging being a single player name.
That’s more of our internal problem though. Developers don’t really need to care about handling @a in their own commands if they want to do, and if they do, they can do it generically.
There’s no reason why you can’t do it generically. i.e. don’t return Player when parsing the player argument: return List<Player>, Iterator<Player> or something else.
How exactly does letting the command return a list help? When encountering @a the command can decide if it should run N number of commands or one command with N arguments. This can be different for each argument the command takes.
Because it’s not about letting the command return a list, it’s about letting the command take a list.
As @teozkr said, your command takes the list. By return I meant your argument parser returning a list.
For sake of example:
void teleport(ArgsContext args) {
List<Player> players = args.nextPlayers();
Location loc = args.nextLocation();
players.stream().forEach(p -> p.teleport(loc));
}
teleport() doesn’t need to care at all whether a single player name or @a was given.
It’s how I implemented macros for CommandBook back in early 2011, but the syntax is different (#near, etc.).
There is still some complexity regarding who to send messages to and whatnot, but it’s a surmountable problem.
Shouldn’t
String arguments
be
String[] arugments
?
That’s for command-line arguments. Sponge is free to use its own syntax.
Ah, thanks for the clarification.
Dinnerbone has tweeted a sample for a command registration (gist here), it will be for the Minecraft API
2 Likes