Choonster

Vanilla doesn't use the baked model system for its liquids, but Forge provides the forge:fluid model for modded Fluid s. Using Forge's blockstates format, set the model to forge:fluid and then pass the name of the Fluid to use the properties of in the "fluid" property of the "custom" object. Forge has an example of this here (code). My mod has an example of this here (code).

Yes, it's the same system.

If it's your own Item , override Item#addInformation to add the tooltip. If it's an Item added by vanilla or another mod, subscribe to ItemTooltipEvent to add the tooltip. Forge's documentation has an introduction to events here.

Are you sure you want to create an event yourself rather than subscribe to an event that's already fired by Forge? If creating an event is really what you want, you need to figure out where to fire it from, who's going to subscribe to it and what you're going to do with the results.

You need to specify a tint index for each element of the model that you want coloured at runtime and then register an IBlockColor for the Block by calling BlockColors#registerBlockColorHandler in init from your client proxy (or a client-only class called from it). If you want to colour the item model, you also need to register an IItemColor with ItemColors#registerItemColorHandler . The wiki explains the model format here. For examples of IBlockColor , look at the vanilla implementations in BlockColors or my mod's implementations here.

Like I said, you can't use your own packets if your mod isn't on the server. When you use the integrated server (for single player/LAN), the server has the same mods as the host client (because it's being run by the host client). When you use the dedicated server, the server has its own set of mods (or none at all). PositionMessageHandler is reaching across logical sides by setting a field in CommandGetPlayerPosition (a class only used by the client) from the server; this is incorrect and will break in a multiplayer session (even if it's LAN). It's also doing this from the server's network thread instead of the server's main thread, which will cause even more problems. Your IMessageHandler must schedule a task to run on the main thread before it can safely interact with normal Minecraft classes, Forge's documentation explains this here. You're also using the client-only I18n class from a server-side IMessageHandler , which would crash the dedicated server.

If recompileMC is failing with "GC overhead limit exceeded", you need to give Gradle more memory. Forge's documentation explains this here. If it's failing with a different error, post the full output from Gradle.

You can use the forge:multi-layer model to combine other models that are rendered in different layers. I explain this in more detail here.

but it was so beautiful.... if (!playerIn.capabilities.isCreativeMode) { --itemStackIn.stackSize; } ItemStack#func_190918_g decrements the stack size by the specified amount.

Yes, ItemStack s are no loner allowed to be null , the default value is now ItemStack#field_190927_a (the empty/invalid ItemStack ). ItemStack#func_190916_E checks the validity of the ItemStack for you, so you don't have to check it yourself.

This isn't working for me, and I have no code errors (and I went back through and changed the entities accordingly to 1.11) (I can share src if need be): What exactly isn't working? Forge hasn't yet added the ability to register entities in 1.11, so it's unlikely that any modded entity will work.

Don't modify the Minecraft JAR at all. Leave the META-INF directory alone. Use the Forge installer to install Forge.

ItemStack#func_190916_E returns the stack size if the stack is valid (see ItemStack#func_190926_b , which returns true if the stack is invalid/empty) or 0 if it's not.

A NullPointerException is thrown when you try to access a field or call a method of a null value. Look at line 61 of IceBall , which values could be null ? If you're not sure which one is null , set a breakpoint on that line and run Minecraft in debug mode. When the breakpoint is hit, look at the values used on line 61 and see which one is null .

Are you sure you posted the right crash report? The one you posted is an unresolved compilation problem, not a NullPointerException .

That looks correct apart from the fact that you're using Minecraft#thePlayer . Minecraft is a client-only class and can't be used in common code. If this code is meant to run on the server, you need to figure out which player you're running it for. If it's only meant to run on the client, using the client player is acceptable. Use EnchantmentHelper.getModifierForCreature to get the bonus damage against a specific EnumCreatureAttribute provided by the player's held item.

What does the PlayerPositionHandler packet do if your mod isn't on the server? You can't use MinecraftServer in a client command. The MinecraftServer argument of ICommand#getTabCompletionOptions will be null for client commands if there's no integrated server running. If your mod isn't on the server, you can't create your own packets; you can only send vanilla ones. On the client, you can use NetHandlerPlayClient#getPlayerInfoMap to get a list of players currently on the server. Use Minecraft#getConnection to get the NetHandlerPlayClient instance, but make sure it's not null before you try to use it.

Only use AttachCapabilitiesEvent to attach capabilities to external objects. For your own objects, simply store the capability instance in a field and override the ICapabilityProvider methods. Let's say your TileEntity has a fluid tank, so it stores an instance of FluidTank in a field. If you want to expose that tank as a capability (so other mods can interact with it), override the following methods: hasCapability : Return true if the Capability argument is CapabilityFluidHandler.FLUID_HANDLER_CAPABILITY and the EnumFacing is correct. getCapability : Return the FluidTank instance if the Capability argument is CapabilityFluidHandler.FLUID_HANDLER_CAPABILITY and the EnumFacing is correct. Use Capability#cast to cast the object you return from this method to the correct type (this is to work around the limitations of generics, Java doesn't know that the object you're returning is an instance of the generic return type). For both methods, return the result of the super method if the Capability or EnumFacing isn't one that you handle. If the tank can be accessed from all sides, you can ignore the EnumFacing argument entirely. Some of the main advantages of the capability system are the ability to attach your own capabilities to external objects (e.g. give a vanilla item a fluid tank or inventory) and the ability to split up your code into multiple classes and use existing classes (e.g. you create a TileEntity that uses the existing FluidTank and ItemStackHandler classes instead of a TileEntity that implements IFluidHandler and IItemHandler itself).

Always post the crash report and/or FML log (logs/fml-client-latest.log or logs/fml-server-latest.log) when asking for help with a crash. It's not safe to use MinecraftServer in a client command, all interaction between the client and server must be handled through packets. Forge's documentation explains sides here and networking here. Why is this even a client command? If you need data from the server and your mod is on the server, use a server command.

My mod adds Waila as a deobfuscated dependency (here). I just updated my mod's MCP mappings to snapshot_20161115 (which renames Minecraft#theWorld to world and Minecraft#thePlayer to player ), ran setupDecompWorkspace and refreshed my IDE project, but Waila was still deobfuscated to the old mappings. Are deobfuscated dependencies meant to be automatically refreshed? Is there a Gradle task to refresh them or should I just delete the cached JARs manually?

Capabilities aren't automatically synced, do you ever sync the mana value from the server to the client?

Your EventHooks.onItemTooltip method is static, but you registered an instance of EventHooks with the event bus. For static @SubscribeEvent methods to work, you need to register the Class ( EventHooks.class ) with the event bus. For instance @SubscribeEvent methods to work, you need to register an instance of the class ( new EventHooks() ) with the event bus. You can also annotate a class with @Mod.EventBusSubscriber to automatically register the Class with the Forge event bus at loading time.

That page is incorrect, the event is always fired when an item tooltip is displayed; regardless of the advanced tooltip setting. The doc comments in the event class explain this.

It's not directly related to your question, but you're using IFluidHandler incorrectly. The whole point of the Capability system is that you don't implement interfaces on your TileEntity , instead you store the objects in the TileEntity and override the ICapabilityProvider methods to return them. Forge's documentation explains this in more detail here.

Use ItemTooltipEvent .