Jump to content

How to make simple forge command?


zcarl

Recommended Posts

Create class for command:

public class Command extends CommandBase {
    @Override
    public String getCommandName() {
        return "commandName";
    }

    @Override
    public String getCommandUsage(ICommandSender sender) {
        return "commandUsage";
    }

    @Override
    public void execute(MinecraftServer server, ICommandSender sender, String[] args) throws CommandException {
        //Do what you want
    }
}

 

Register in main mod file:

 

@EventHandler
public void serverStarting(FMLServerStartingEvent event) {
event.registerServerCommand(new Command());
}

Link to comment
Share on other sites

Some advice...

 

1) Read the source code docs. It's harder to get to them now than the javadoc link. I think I'll change my mod's gradle "build.gradle" to have a javadoc task for generating javadoc of the forge and deobf minecraft libs. 

 

2) Where the annotations are (e.g. @Mod) is the magic, so use the code completion in eclipse to see options like acceptedMinecraftVersions. These necessary aren't automatically in the example nor are they populated.

If it's an annotation, you have to (or should) read about it and read the code. Understanding the annotations is the first step.

 

@Mod(modid = YourMod.MODID, version = YourMod.VERSION, acceptedMinecraftVersions = YourMod.ACCEPTEDVERSIONS)

 

Yes, accepted versions should be a static string of (Maven) version strings. (e.g. public static final String YourMod.ACCEPTEDVERSIONS="1.9,1.9.4";)

 

BTW: The forge example and the MCCreator generator should possibly include a note on this in the example, since the forge developer team says PLEASE use this in CAPITAL LETTERS. 

 

3) Assume you are going to code it wrong the first time. Decide if you are OK with that. You are probably not going to write using the best choices. This is a principle of architectural recoverability. (Design code so that refactoring from mistakes is easy.) There is probably a method that you won't find as a newbie that would do something for you, you'll code a kludge for. Unless you have a version control system, clean up code late. Even from 1.8 to 1.9, there is refactoring (e.g. my major mod difference from 1.8 to 1.9 is getting the server from event.getServer() instead of MineCraftServer.getServer()).

Write one to throw away. Your first mod will probably not work well. Copy to a new forge version. CommandRunnerMod is still in the one to throw away stage. Useful but not perfect.

 

4) You might start with a Block Mod. (Where I should have started). Things become clearer with a Block Mod behind you. My biggest error in command runner mod was not starting in forge with a block mod. I looked for a rotation type (e.g. that would tell me how a block will rotate directions in datavalues and NBT tags (e.g. I'm still looking for a Orientation_Type = STAIR_ROTATION) and it's probably there somewhere, but I haven't found how to use it. So I reused code from old libraries for schematic editors. I'd have probably done better starting with a block mod. Not a great idea but livable for vanilla blocks. I'm redoing a block mod for that reason for the CommandRunnerMod. 

 

5) Release early and often. Evolve in small steps. Fix early and often.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.