Choonster

You need to use Forge's fluid model. Use the default render type of 3 (model specified by blockstates file). -1 stops the block being rendered at all (used by vanilla TESR blocks). Forge has an example here (blockstates file) and I have an example here (blockstates file).

It still exists, but it probably doesn't have a deobfuscated name in the mappings version you're using. Its SRG name is func_180433_a . To update your mappings version, set the minecraft.mappings field in your build.gradle script to the appropriate version, re-run setupDecompWorkspace and regenerate (for Eclipse) or refresh (for IDEA) your IDE project. You can get the mappings version from the MCPBot website.

Keep in mind that you're limited to 4 bits of data per block unless you use a TileEntity . Redstone wire uses all 4 bits to store the 16 possible strength levels; storing the sign would take up 2 bits, leaving you with 2 bits to store 4 possible strength levels. A non-ticking TileEntity (the default in 1.8 ) probably wouldn't hurt performance too much, but you'll want to do some profiling to confirm that. Edit: Actually, you probably don't need an explicit neutral sign (since that would just be 0 strength); so you can store the sign in 1 bit and use 3 bits to store 7 strength values.

World#getWorldTime returns the current time of day (so it resets to 0 at the start of the in-game day), World#getTotalWorldTime returns the total number of ticks that the world has been active (so it doesn't reset). If you store the time as a long (what it's given to you as), that will last for Long.MAX_VALUE ( 2^63-1 ) ticks; which at 20 ticks per second is equivalent to 1.2810238940076 x 10^14 hours, 5337599558365 days or roughly 14623560433 years. I don't think you need to worry too much about your code running for that long.

To update Forge, change the minecraft.version field (i.e. the version field in the minecraft block) in your build.gradle script to the appropriate version and run gradlew setupDecompWorkspace again. If you're using Eclipse, regenerate your project with gradlew eclipse . If you're using IDEA, refresh the project in the Gradle window. Your repo doesn't have the code for the flying entity in it. If you look at the stacktrace, you'll see that your code is throwing a NullPointerException on line 36 of EntityEoC (in the applyEntityAttributes method).

Why did you post the vanilla class? Why not post your class? As I asked in my previous post, why can't you? What happens when you try? Are you using an old version of Forge? The new egg system was added in 11.14.3.1468.

You're probably using a newer version of the mappings in your workspace than the ones included in the 9.10 release of MCP. You can find the mappings used by your ForgeGradle workspaces (for recent 1.8 versions of ForgeGradle) in ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mcp_type>/<mappings_version> (replace ~ with %USERPROFILE% on Windows). You can also download specific mappings versions from the MCPBot website. In Stable 16, potionRequirements is field_179539_o and potionAmplifiers is field_179540_p .

registerModEntity can add a spawn egg for you without using a global ID, just use the overload with the two additional int parameters (the egg background and foreground colours). There's no reason to use global IDs at all. Why can't you spawn flying entities with commands or eggs? Do you get an error in the log when you attempt to do so? If so, post it.

You need to override getMetaFromState , just ignore the DAMAGE property in it. getStateFromMeta will always return the default state if you don't override it, which is what you want in this case.

"I can't upgrade" is pretty much never a valid statement. I think there's a few older versions of OS X that don't support it, but I'm not entirely sure. The OP should definitely upgrade if possible.

ItemStack#writeToNBT will write an ItemStack to an NBTTagCompound . You should be able to save the EnumChatFormatting as a string (i.e. store the result of the toString method).

The first error is caused by not having NEI installed. The second error is caused by having the wrong version of Chisel Facades installed. You're using Cricket's Chisel 2 but have a Chisel Team version of ChiselFacades installed. Either switch to Chisel Team's Chisel or to a Cricket version of Chisel Facades. I explain which version of Chisel Facades to use for each version of Chisel on the CurseForge page.

You've run out of PermGen memory. You should upgrade to Java 8, which no longer uses PermGen. If you can't upgrade, increase the maximum PermGen with the MaxPermSize command line argument.

Recipes for Dyes and coloured blocks (e.g. Stained Clay) are added by RecipeDyes#addRecipes , which is called from the CraftingManager constructor. They're just standard shaped/shapeless recipes, so your method should remove them without issue. Fireworks recipes are handled by the RecipeFireworks class, which returns null from IRecipe#getRecipeOutput until IRecipe#matches has found a matching recipe; so you can't remove it based on the output Item . You can remove it based on the class instead, though. You can see a working example of this for 1.8 here. This outputs the following to the log:

Gist is a similar site with a much higher limit. It will accept full FML logs.

Look for Item methods that take an ItemStack parameter, you can use this to read the values from the NBT. Attack damage: override getAttributeModifiers(ItemStack stack) (look at ItemSword to see how it adds the attack damage modifier) Durability: override getMaxDamage(ItemStack stack) Enchantability: override getItemEnchantability(ItemStack stack) Repair item: override getIsRepairable(ItemStack p_82789_1_, ItemStack p_82789_2_) (the arguments are the items in the left and right slots of the anvil respectively) Name colour: override getRarity(ItemStack p_77613_1_) (for one of the default rarity colours) or getItemStackDisplayName(ItemStack p_77653_1_) (for custom colours using EnumChatFormatting ) Size: Not entirely sure, but you probably want to implement IItemRenderer

Are you looking at the IDE's console or the log file itself? Messages with a Level less specific than INFO (i.e. DEBUG , TRACE or ALL ) won't be written to the standard output (i.e. the IDE's console), but will be written to the log file.

You're trying to call methods with SRG (obfuscated) names in the deobfuscated environment. The two most likely reasons for this are that it was built for the obfuscated environment or that it was built using an older version of the MCP mappings. To build a mod for the deobfuscated environment, use gradlew jar instead of gradlew build (which reobfuscates the mod). You can change the MCP mappings version using the minecraft.mappings variable in your build.gradle script.

This is the wrong section, but the thread will probably be moved for you. We need the full FML log (logs/fml-server-latest.log) to help you. Upload it to Gist and link it here.

It looks like you're reinventing the command system. You should create a class that implements ICommand (extending CommandBase will handle a lot of stuff for you) for each of your commands and then register them with ClientCommandHandler#registerCommand .

FYI: The OP's code is adapted from an example I provided in their previous thread.

This is just Wuppy's style, it's not required (or used at all) by Forge. He just uses it to store the name passed to GameRegistry.registerBlock .

It's the same as in 1.7.10.

The following advice assumes you're using 1.8. It's pretty similar in 1.7.10. Block#onEntityCollidedWithBlock(World worldIn, BlockPos pos, IBlockState state, Entity entityIn) is called when an Entity collides with the Block . The other overload is only called when an Entity walks on top of the Block . An Entity will only collide with a Block if it has a bounding box smaller than a full cube. An offset of 0.01 on each side is enough to allow collisions.

You need to point it to an MCP conf directory. For 1.7.10, you can find this in ~/.gradle/caches/minecraft/net/minecraftforge/forge/<version>/unpacked/conf (replace ~ with %USERPROFILE% on Windows).