Choonster

It looks you're using a deobfuscated build of your mod in the obfuscated environment. Make sure you build your mod by running the build Gradle task, this reobfuscates it.

Subscribe to PlayerInteractEvent.RightClickItem and do the following: Check if the item is a slimeball Decrement the stack size If the stack size is 0, set the player's held item to null and call ForgeEventFactory#onPlayerDestroyItem to fire PlayerDestroyItemEvent . Spawn your entity Cancel the event to prevent Item#onItemRightClick and other handlers from being called Note that even if you cancel the event, processing will still continue to the other hand until this PR is merged and you set the result to EnumActionResult.SUCCESS .

Jabelar has a tutorial here. It looks like it was written for 1.7.10/1.8, but it should still be mostly relevant. There may be other tutorials out there, I don't really keep track of them myself.

If you want Javadocs, read the code or generate it yourself. Forge no longer offers a Javadoc JAR for download. If you want written documentation on various parts of Minecraft and Forge, you can find Forge's official documentation here. If you want tutorials, use your search engine of choice to find them. Shadowfacts has some 1.9.4 tutorials here. The Grey Ghost has some useful articles for 1.8+ here.

The whole point of Forge is that you don't modify vanilla code, Forge provides the necessary hooks and events for you. If you want to make a mob, create a class that extends the appropriate Entity subclass (e.g. EntityMob ) and register it with EntityRegistry.registerModEntity . You can then create a renderer extending the appropriate Render subclass (e.g. RenderBiped ) and register it with RenderingRegistry.registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) . There are more detailed tutorials out there, this is just a basic overview.

Why do you need to do this? Forge will load your mod from your IDE's build output directory, you don't need to build a full JAR with Gradle and put it in the mods folder.

Your IItemColor#getColorFromItemstack implementation receives a tint index argument telling it which part of the model is being coloured. This also applies to IBlockColor , which is used to colour blocks. For regular models, the tint index is specified per face of each element. For models that extend builtin/generated (or item/generated , which extends builtin/generated ), the tint index is the texture's layer number (0 for the layer0 texture).

That looks correct, though I'd recommend using texture references like #ore and #ore_vein in the base model instead of texture paths. You can then specify the actual paths of these references in the derived models or blockstates file (if you're using Forge's blockstates format).

His example has two: the ore color (blue) and the stone color (white). The stone isn't dynamically coloured, it would just be a regular texture.

This exception is thrown when Minecraft attempts to render an ItemStack with a null Item . Ensure all of your Item s have been properly initialised.

Where do I find out whether I have that or not? (I will remind you of my extreme noob alert) Environment variables are a part of your operating system. There should be various sites out there that explain how to view and edit environment variables on your OS, use your search engine of choice to find them.

Do you have the JAVA_OPTS environment variable set? If so, delete it.

The workspace directory with build.gradle and your code can be anywhere, but the gradle.properties file with the JVM arguments needs to be in the ~/.gradle directory (or %USERPROFILE%\.gradle on Windows).

The block/grass model already does something like this: It has one full cube with only the top coloured and another cube without a top or bottom and each side coloured. The cubes are the same size, but the second cube's texture is overlayed on the first. What you need is a cube with the stone texture on all sides and another cube with the ore texture on all sides and each side coloured. For a face to be coloured, specify the tint index in the model and then register an IBlockColour and IItemColour for the Block and ItemBlock . These will receive the tint index as an argument, telling them which part of the model is being coloured (though you don't need to worry about that if the model only has a single dynamic colour).

BON2 can already do this for arbitrary JARs and ForgeGradle can do it for dependencies. BON2 can use any MCP mappings in the Gradle cache (as downloaded by ForgeGradle), ForgeGradle will use the current project's mappings.

IMessage classes must have a zero-argument constructor. This means that you can't implement IMessage with a non-static nested class (a.k.a an inner class) because Java adds the enclosing class as a parameter to all constructors, so it's not possible to have a zero-argument constructor. You can implement with a static nested class, since Java doesn't interfere with your constructors.

Single player is just a server with one player logged in. If you write your code properly, you don't need to care about which type of server is running.

The client and server will both run from the working directory set in the run configurations. If you're using the run configurations generated by ForgeGradle, this will be the directory you've set as the minecraft.runDir property in build.gradle (the default is run). To log into the server, you'll either need to disable online mode in server.properties or add the --username <email> --password <password> program arguments to your client run configuration so it logs in with your Mojang account. Disabling online mode will allow you to log in with clients that aren't authenticated, this allows you test a multiplayer scenario while only owning a single account.

1.10 is a Minecraft version, not a Forge version. There are many versions of Forge for each version of Minecraft, so you need to tell us which version of Forge you're using. You're using OptiFine to load your shaders pack. OptiFine isn't supported by Forge because it messes with a lot of things internally. Post the crash report and someone may or may not be able to help you.

If a TileEntity value is required for rendering purposes, you need to sync it to the client in the update packet. In 1.7.10, override TileEntity#getDescriptionPacket to write the data that needs syncing to a compound tag and then create and return an S35PacketUpdateTileEntity . In 1.9.4/1.10, override TileEntity#getUpdateTag to write the data that needs syncing to a compound tag and return it. Override TileEntity#getUpdatePacket to create and return an SPacketUpdateTileEntity with the tag returned by TileEntity#getUpdateTag . 1.7.10 is very outdated and no longer supported. You should update to 1.9.4/1.10.

WorldRenderer was renamed to VertexBuffer . Most renames in 1.9.x/1.10 are documented in this issue tracker.

MovingObjectPosition was renamed to RayTraceResult .

Either create an attribute or capability for your money, you don't need both. My max health capability only exists because I need to manage an attribute modifier for an existing attribute. If you're using an attribute, call AbstractAttributeMap#registerAttribute once when an entity first joins the world to create the attribute instance. You can then use AbstractAttributeMap#getAttributeInstance to get the attribute instance and set its current value. You don't need to use attribute modifiers. If you're using a capability, just store the money value in the capability instance and sync it to the client when necessary. Don't mess around with attributes.

That's the console output rather than the FML log. The FML log can be found in logs/fml-client-latest.log. There aren't any errors in the log, so I suspect that ModItems.initModels is never being called. Put a breakpoint in the method and run Minecraft in debug mode, is the breakpoint hit?

Forge mods can be universal (required on both the client and server), client-only (only required on the client, may or may not work on the server) or server-only (only required on the server). Single player and LAN both run a server in the background, so you can use most server-only mods on the host client without having to install them on the other clients. Things like minimaps and HUDs are usually only required on the client, though some can optionally be installed on the server. Admin tools like backups and permission management are usually server-only. Any mod that adds content (blocks, items, entities, etc.) must be installed on both the client and server. Most Forge mods are universal, so the download page will usually explicitly say if the mod is client-only or server-only.