Implementing client-only commands with Forge 1.12

[Proxxo]

Hi Forge community,

 

I'm quite new to forge mod development and still searching for the single point of truth tutorial / documentation for Forge 1.12.

 

I would like to implement a mod with various client-only commands (i.e. /realtime - displays the current time in players chat).

Searching for "command" in the Docs section of this site unfortunaly does not display any useful resources for me.

After using Google, I found various sites using a "ClientCommandHandler".

But I can't see if this class is supported in 1.12 and if so, how to use it to register and execute client-only commands.

 

Could anyone post a tutorial or some hints how I could start?

And a last question: does an online java doc existst for the forge classes where I can browse around to explore all possibilities that I have with forge?

 

Hope to be welcomed by forge community

Proxxo

Edited October 21, 2017 by Proxxo

[Draco18s]

  On 10/21/2017 at 4:41 PM, Proxxo said:

After using Google, I found various sites using a "ClientCommandHandler".

But I can't see if this class is supported in 1.12 and if so, how to use it to register and execute client-only commands.

Expand  

So, my question here is, "Why wouldn't it be supported in 1.12?"

Anyway, take a search on these forums and see what you can dig up. It's come up in the past.

  On 10/21/2017 at 4:41 PM, Proxxo said:

And a last question: does an online java doc existst for the forge classes where I can browse around to explore all possibilities that I have with forge?

Expand  

No, because it would be out of date in less than a week. All the javadoc you need is in the code itself. And if there ISN'T javadoc on something that means there's NO javadoc at all for it. All the javadoc is handled via MCPBot, the same way human readable names for methods and field names are handled.

[Proxxo]

Hi Draco,

thanks for your quick post.

 

  On 10/21/2017 at 5:00 PM, Draco18s said:

So, my question here is, "Why wouldn't it be supported in 1.12?"

Expand  

Because of changes in the api. I do not assume that all classes (i.e. ClientCommandHandler) in version 1.7.x are still existing in 1.12. Or they may got renamed. Or deprecated.

 

  On 10/21/2017 at 5:00 PM, Draco18s said:

No, because it would be out of date in less than a week.

Expand  

This sounds crazy to me . Is every build of forge a release version that people use in production? Coming from c# world, I am familiar with apis that update their documentation on every major/minor release. Intermediate work or bugfixes are handled in separate releases / hotfixes etc. Is this not the case with forge? When I look at the github pages, it seems that this may have changed, or am I wrong? https://github.com/MinecraftForge/MinecraftForge/releases

 

  On 10/21/2017 at 5:00 PM, Draco18s said:

Anyway, take a search on these forums and see what you can dig up.

Expand  

Thanks for this tip. If there is no documentation about this, it seems that I have no other choise.  

[Draco18s]

  On 10/21/2017 at 10:19 PM, Proxxo said:

This sounds crazy to me . Is every build of forge a release version that people use in production? Coming from c# world, I am familiar with apis that update their documentation on every major/minor release.

Expand  

Forge doesn't even maintain the Javadoc, that's all on the MCPBot side.

  17 minutes ago, Proxxo said:

Intermediate work or bugfixes are handled in separate releases / hotfixes etc. Is this not the case with forge? When I look at the github pages, it seems that this may have changed, or am I wrong? https://github.com/MinecraftForge/MinecraftForge/releases

Expand  

This would be more accurate:

http://files.minecraftforge.net/

The last build was 05:37 AM this morning (with a new recommended build that has no changes, 10 minutes later), and the previous build was on the 9th.  MCP exports? Those happen daily.

[Proxxo]

Thanks for your clarifications. I guess I first need to get more comfortable with these fast evolving Java ecosystems.

I will post the answer to my own question after I found all code puzzle pieces to get client-only commands up and ready.

[Proxxo]

Implementing client-only commands works like this:

 

1. Implement ICommand

I created an example command that will show the current time to a user like this:

public class GetTimeCommand implements ICommand {

	@Override
	public int compareTo(ICommand arg0) {
		return 0;
	}

	@Override
	public String getName() {
		return "realtime";
	}

	@Override
	public String getUsage(ICommandSender sender) {
		return "/realtime";
	}

	@Override
	public List<String> getAliases() {
		List<String> aliases = Lists.<String>newArrayList();
		aliases.add("/realtime");
		return aliases;
	}

	@Override
	public void execute(MinecraftServer server, ICommandSender sender, String[] args) throws CommandException {
		DateFormat dateFormat = new SimpleDateFormat("HH:mm:ss");
		String time = dateFormat.format(new Date(System.currentTimeMillis()));
		sender.sendMessage(format(net.minecraft.util.text.TextFormatting.DARK_GREEN, time));
	}

	@Override
	public boolean checkPermission(MinecraftServer server, ICommandSender sender) {
		return true;
	}

	@Override
	public List<String> getTabCompletions(MinecraftServer server, ICommandSender sender, String[] args,
			BlockPos targetPos) {
		return null;
	}

	@Override
	public boolean isUsernameIndex(String[] args, int index) {
		return false;
	}
	
	private TextComponentTranslation format(TextFormatting color, String str, Object... args)
    {
        TextComponentTranslation ret = new TextComponentTranslation(str, args);
        ret.getStyle().setColor(color);
        return ret;
    }
}

 

2. Register your command

Find a good place to register your command(s) at mod start up. I decided to first implement proxies for server and client like described in the Docs: https://mcforge.readthedocs.io/en/latest/concepts/sides/.

Then, in my ClientProxy class, I put command registrations into the preInit event handler:

public class ClientProxy extends CommonProxy {

	@Override
	public void preInit(FMLPreInitializationEvent e) {
		ClientCommandHandler.instance.registerCommand(new GetTimeCommand());
    }

	...
}

 

Thats it. In game, I can now input "/realtime" in chat and get the current time displayed.

[jabelar]

  On 10/21/2017 at 10:19 PM, Proxxo said:

This sounds crazy to me . Is every build of forge a release version that people use in production? Coming from c# world, I am familiar with apis that update their documentation on every major/minor release. Intermediate work or bugfixes are handled in separate releases / hotfixes etc. Is this not the case with forge?

Expand  

 

If you're coming from a professional coding environment, yes both Minecraft code itself and Forge's API are pretty "crazy". This is because Minecraft wasn't originally developed by professional programmers and furthermore was developed incrementally so there is a lot of inconsistency and a lot of stuff that would be frowned upon by software or engineering organizations. For example, the scope of fields and methods is really inconsistent with no proper encapsulation --  so you can reach into the code and change key values without any validation or synchronization. There are also often two methods which might do the same things. There is also abandoned code, code which does the same thing in multiple places (especially since without encapsulation the data validation is sprinkled throughout the code) and such.

 

Forge is done by good quality programmers, but it has been an incremental effort with lots of different contributors. It is also limited in that it tries to minimize the patching of vanilla Minecraft. Because it is incremental, every now and then the API gets entirely overhauled (for example the move to JSON format to control a number of features, the new registry event system, and so forth). Because there are lots of different contributors there are inconsistencies in style, for example the use of functional programming is creeping into the code but isn't consistently used throughout. And because they're trying to minimize the patching it is really constraining -- for example I'm trying to submit my first contribution related to custom fluids acting more like water but because Material.WATER is hard-coded throughout the vanilla code it is somewhat dubious to try to take this on as it creates a lot of patches.

 

I do find it wearing that the APIs change constantly -- keeping old mods up to date is a full time job and the modding community is getting fractured (you'll see on Minecraft Forum that majority of modders have stayed with 1.7.10 or 1.8.9). However, it is also the interesting part of the modding hobby and frankly has made me a much better coder by trying to keep up as it teaches a lot about the benefits of different approaches.

 

Sorry for the long essay, but I understand the surprise you might feel when you hear an API is constantly changing...

[Proxxo]

Hi jabelar,

 

thank you very much for this insights into the development process of Forge and Minecraft. Constantly working on my mod to keep it up to date with the latest Forge version was something that came into my mind when I read @Draco18s post. I will do my best.

 

However, Forge is a great project and it's exciting to learn some fundamental different concepts compared to what I used in the past.