GotoLink

You'll probably need to clone the branch and build it, then, to apply locally: buildscript { //other Forge stuff dependencies { classpath fileTree(dir: '/path/to/folder/that/contains/the/jar', includes: ['local-built-git-dependencies-plugin.jar']) } } apply plugin 'forge' apply plugin 'git-dependencies'

Hum...maybe try version 0.1 instead ?

Use this gradle plugin ? https://github.com/bat-cha/gradle-plugin-git-dependencies Note: Untested. Seems pretty straight-forward according to their docs, though.

You actually mean all of them ? All the blocks and all the inventories related to them. Probably also mob AI, redstone logic, world saves... And who is going to maintain all those changes between Minecraft updates ? You'd also break all mods related to TileEntity. Aggregating is not a bad design idea. I apply it from time to time. Just don't make it into the TileEntity. Make a ForgeTileEntity. Then you could probably suggest it.

I'd say an over-looked feature. The tool classes system is relatively new... though i have to assume that change was suggested by someone, so there should be at least a few people that use it. (one of my mod adds "drill" tool class, and i didn't propose this system)

You need to do gradlew build. Export from IDE won't obfuscate the mod, and Forge will be unable to read it.

Did you register this entity class ? this.itemIcon = iconRegister.registerIcon(Reference.MODID.toLowerCase() + ":" + (this.getUnlocalizedName().substring(5))); And did you put your item texture in the correct lowercase folder ? Or is this unlocalized name set ? Is your entity supposed to reduce another entity item stacksize if close-by ?

Send to server: C0APacketAnimation(entityPlayer, 1) Send to other players: S0BPacketAnimation(entityPlayer, 0)

You are using ServerTickEvent to update a TileEntity ? Why ? I'd say a TileEntity was partially unloaded, but your WarpedNetwork tried to tick it anyways. That would crash Minecraft for sure.

I'd recommend the crafting event. This will prevent collision with other axe recipes.

You are missing a character in your recipe. (fistsoffury.java line 58)

Then Item#setFull3D()

You don't use any GUI then ? As long as you keep stuff server-side, I don't see the need for packets there. There is ByteBufUtil class you might want to look into.

If it is only ItemStack you need to pass, you can use FML InterModCom messages. Or make custom child classes of fml.Event for your containers to post ?

Your code is running on client-side. Should be server-side.

Extend ItemBow and remove stolen Mojang code.

Well, generating ores is a decoration step. Chunks "base" (stone) look is already calculated by then. There are also basic concurrency fail-fast protections. For example in BiomeDecorator.

If you used GuiContainer/Container, the inventory content is automatically synced between client and server.

If you want to be technical, this is probably compiler-level stuff. Your original #handleClientMessage was probably given a signature with EntityClientPlayerMP by the compiler, then type-erasure and/or binary compatibility triggered, making you unable to change that signature in more recent compilations. (the bytecode would be needed to confirm this assumption) @Kwibble It would be nicer if you didn't try to compare codes that don't produce the same result.

Put your client-only methods under @SideOnly(Side.CLIENT) ? The stuff should be stripped. Or hide the call into your proxy. //In client proxy @Override public EntityPlayer getClientPlayer(){ return Minecraft.getMinecraft().thePlayer; } //In packet handler if(messageContext.side.isClient()){ handleClientMessage(MyMod.proxy.getClientPlayer(), message); }

Coremod has a different meaning in Forge that shouldn't be confused. Modifying Minecraft classes by runtime patches. But yeah, to make a "main mod" and submodules, that is one way of going about it.

You need to use the message in your IMessageHandler#onMessage(....

Was the api under src/api/java ?

The recommended way is to not type cast when it is not needed. Type casting means you made some methods in ItemModSoup that you plan to use later on this instance. Otherwise, you can let Item#setUnlocalizedName(String) type-shadow your instance. FML also prefers you initialize and register items and blocks into FMLPreInitializationEvent, as a safe mod-cycle. You can cache the instances wherever you want at the same time.

Check your imports, they count too. Try registering network stuff on ServerStarting rather than PreInit, just in case.