Tracking issue: complete command support

[caelunshun]

#209 added initial support for commands using lieutenant and implemented /tp and /gamemode. What's left to do:

• Implement all commands in Vanilla (only those present in Java Edition)
• Ensure that messages are consistent with Vanilla (this is certainly not the case right now)
• Implement target selector arguments
• Send the command node graph to players upon joining

For newcomers to the project, implementing a command is a good way to start. The basic process is:

• Locate the Minecraft Wiki page for the command and read through it, so you understand the command well (skip any Bedrock-specific sections).
• Go into server/commands/src/impls.rs and implement the command.
  • The tp implementation is a good example of how a command could be implemented.
  • If you need a new argument type (for example, a parsed gamemode or a UUID), implement it in server/commands/src/arguments.rs. EntitySelector and ParsedGamemode are useful examples to see how this is done.

If you need any help, you are welcome to ask as many questions as you need on our Discord server :)

[ambeeeeee]

I'm currently working on the tell command.

[onbjerg]

Java Edition vanilla commands list:

• /attribute
• /locatebiome
• /advancement
• /ban
• /ban-ip
• /banlist
• /bossbar
• /clear
• /clone
• /data
• /datapack
• /debug
• /defaultgamemode
• /deop
• /difficulty
• /effect
• /enchant
• /execute
• /experience
• /fill
• /forceload
• /function
• /gamemode
• /gamerule
• /give
• /help
• /kick
• /kill
• /list
• /locate
• /loot
• /me
• /op
• /pardon
• /particle
• /playsound
• /publish
• /recipe
• /reload
• /replaceitem
• /save-all
• /save-off
• /save-on
• /say
• /schedule
• /scoreboard
• /seed
• /setblock
• /setidletime
• /setworldspawn
• /spawnpoint
• /spectate
• /spreadplayers
• /stop
• /stopsound
• /summon
• /tag
• /team
• /teammsg
• /teleport
• /tell
• /tellraw
• /time
• /title
• /tp
• /trigger
• /w
• /weather
• /whitelist
• /worldborder
• /xp

[BuggStream]

I think I will start working on the /weather command.

[Miro-Andrin]

I have written some python code to parse the commands.json file that you can generate from the server jar. Using this i have generated (almost) all the functions one would need to implement to reach 99% vanilla command support.

The included file commands.txt contains (almost) all the functions that one would eventually need to implement. As an example here is one of the xp commands. For now i have them returning a "not implemented msg", but we would have to implement their functionality here.

#[command(usage="xp add <targets> <amount> points")]
pub fn xp2(
    targets : MultiplePlayers, amount : IntegerArgument
) -> anyhow::Result<()>{
    if let Some(mut sender_message_receiver) = ctx.world.try_get_mut::<MessageReceiver>(ctx.sender)
    {
        let return_text = Text::from("This command \"xp add <targets> <amount> points\" is not implemented in this version of feather.").gray().italic();
        sender_message_receiver.send(return_text);
    }
    return Ok(())
}

The included file parsers.txt has a list of the 50 to 60 ish parsers that the commands in commands.rs assume we have implemented.
As an example here is the parser for BlockPos.

#[derive(Debug, Error)]
pub enum BlockPosParseError {}

#[derive(Clone, Debug)]
pub struct BlockPos(pub String);

impl ArgumentKind<CommandCtx> for BlockPos {
    type ParseError = BlockPosParseError;

    fn satisfies<'a>(_ctx: &CommandCtx, input: &mut Input<'a>) -> bool {
        input.advance_until(" ");
        //TODO 
        true
    }

    fn parse<'a>(_ctx: &CommandCtx, input: &mut Input<'a>) -> Result<Self, Self::ParseError> {
        let text = input.advance_until(" ");
        //TODO
        Ok(BlockPos(text.to_owned()))
    }
}

With my scripts i am able to load two different versions of minecrafts commands.json file and see what changes have been made. This would make it possible to track changes in vanilla commands, and get a "diff" for every release, stating what rust code needs to be added/removed. I want to know if the maintainers would be interested in including the generated files. I am not suggesting we add python as part of the build process, just the generated code. If you want to include the generated code, then i am going to spend some time improving the script and release it, and also spend the time creating a pull request.

parsers.txt

commands.txt

[caelunshun]

@Miro-Andrin Wow, that's impressive, thanks for this! I'd be happy to include these generated files as part of the commands crate. Including the generator script in this repo seems like a good idea, in case we want to regenerate the code for some reason, but it doesn't have to be a mandatory build dependency.

[CDFN]

stop command is already implemented (#260), mark it as done please :)
Same with clear.