Choonster

It's no longer necessary to create a custom ItemBlock class for this, just override Block#addInformation .

A lot of fields and methods were renamed in the last few MCP mappings versions for 1.10.2. Minecraft#thePlayer and Minecraft#theWorld were renamed to Minecraft#player and Minecraft#world . Entity#worldObj was renamed to Entity#world . MCPBot can tell you the history of a field/method name. Most renamings are documented on this issue tracker. You can also find the new name of a field/method by looking at the class that contains it and any other code that used it.

I suggest you look at AnimationModelBase , which is designed to render an entity using an animated baked model.

The latest version of IDEA will automatically show the name of any parameter you pass a literal value to, which would help with those methods.

I helped someone create a similar block for entity spawn prevention here. Instead of using LivingSpawnEvent.CheckSpawn , you'd use BlockEvent.PlaceEvent , BlockEvent.BreakEvent , etc. You can also use World Capabilities instead of World Saved Data.

Is there any downside to using MethodHandle s instead of Method s/ Field s?

Thanks, item.ingotIron.name=Iron Bar worked well. I'd like to ask where can I get the list of all items? Vanilla creates and registers all of its Item instances in the Item class and stores them in fields of the Items class. Vanilla specifies all of its translations (for Items and everything else) in its lang files.

You can override any vanilla translation by providing the new translation in your mod's lang file (e.g. item.ingotIron.name=Iron Bar ). You can add furnace recipes using the FurnaceRecipes class.

final means the field is read-only, i.e. you can get its value but you can't set a new value. There are ways around this (see FinalFieldHelper and EnumHelper ), but you generally shouldn't do this unless it's absolutely necessary.

I don't want to download a random ZIP file, upload your FML log (logs/fml-client-latest.log) to Gist and link it here instead. Which launcher are you using? Have you entered the correct username and password?

Jabelar has a brief explanation of reflection here. What he doesn't explain there is that each vanilla method/field has multiple names depending on the environment and that you need to check for these when accessing them via reflection. There are three types of names: Notch - Fully Obfuscated - These are the names produced by Mojang's obfuscation process, the vanilla JARs use these names. They change with each Minecraft version. They're usually a few letters long, e.g. a , bb or ff . SRG/Searge - Semi-obfuscated - These are auto-generated by MCP and FML deobfuscates to them at runtime outside of the development environment. ForgeGradle reobfuscates your code to these names when you run the build task. They remain stable between Minecraft versions. Examples include func_110121_a (a method), field_110285_bP (a field) and p_110121_0_ (a parameter). MCP - Deobfuscated - These are contributed by the community using MCPBot. They're the names you see in the development environment. Examples include isNullOrEmpty ( func_110121_a ), gallopTime ( field_110285_bP ) and str ( p_110121_0_ ). Instead of using Class#getDeclaredField or Class#getDeclaredMethod , use ReflectionHelper.findField or ReflectionHelper.findMethod to get the Field / Method object before unreflecting it into a MethodHandle (as Jabelar explains). You need to pass both the MCP and SRG names when accessing a vanilla field/method. I have a class that does this here. You can see it in use here, here, here and here.

Did you try looking at the BiomeForest class? There's a field called type that stores the BiomeForest.Type value. There's no public getter method, so you'll need to access it with reflection. If you don't know whether a Biome is a BiomeForest , check with instanceof .

I suspect the issue is with your pack.mcmeta file specifying pack_format as 1. 1.11 requires all resource file names to be lowercase, but if a resource pack specifies pack_format as 2 then lang files will still be loaded with mixed-case names (e.g. en_US.lang). If a mod doesn't include a pack.mcmeta file, Forge will provide a default one that specifies pack_format as 2 (allowing mixed-case lang file names). Because your pack_format is 1, this doesn't apply and your resource pack is treated as pack_format 3 (requiring all file names to be lowercase). Either change pack_format to 2 and leave the lang files as-is (e.g. en_US.lang) or change pack_format to 3 and convert their names to lowercase (e.g. en_us.lang).

The vanilla blockstates format is documented (including some examples) on the wiki. Forge's documentation has an introduction to blockstates files here and an explanation of Forge's blockstates format here. There are also lots of examples in the vanilla code.

An Item is just the item type, e.g. Stone Sword, Gold Ingot. Any additional information like metadata/damage and NBT is stored on the ItemStack . As I said in your other thread, you need to override Block#getDrops if you want to drop ItemStack s with NBT.

You can't convert an ItemStack to an Entity as they're completely separate types. You can create an EntityItem from an ItemStack , but that's not what you should be doing here. Block#getItemDropped is meant to return the Item dropped by the Block , not spawn an EntityItem in the world. If you need to drop an ItemStack with NBT (e.g. enchantments) or drop multiple types of item, override Block#getDrops to return a List<ItemStack> containing the ItemStack s you want to drop.

Because your Block has an IProperty , Minecraft is looking for the explode=true and explode=false variants in your blockstates file instead of looking the normal variant. Either use these variants in your blockstates file or register an IStateMapper to ignore the property. Your items have invalid registry names, they should have the tm prefix instead of minecraft .

Post the full FML log as well, you didn't include the full error message.

Don't use numeric IDs, they're not guaranteed to be the same for every save and they're a lot less descriptive than using fields or registry names. The vanilla Potion instances are now stored in the MobEffects class.

Your IBlockColor#colorMultiplier implementation calls IBlockAccess#getBiomeGenForCoords on the IBlockAccess argument but your IItemColor#getColorFromItemstack passes null for this argument, causing a NullPointerException . Both the IBlockAccess and BlockPos arguments of IBlockColor#colorMultiplier are marked as @Nullable , so your implementation needs to account for them being null . The vanilla implementations do this. If you copy the package-info.java file added by MCP from a vanilla package into your own packages, all of your method parameters and return values will be marked @Nonnull by default. This will ensure that your IDE warns you about using @Nullable values without null -checking or overriding a method (or parameter) marked as @Nullable without including @Nullable in your override.

You've added the Maven repository for The One Probe in the wrong place. The buildscript block is only for dependencies of the buildscript, you need to create a repositories block in the main body for dependencies of the project. You can see an example here.

If you want to modify the values of existing attributes on entities that aren't your own, use attribute modifiers. The wiki has an explanation of attributes and modifiers here. If you want to store custom data on entities that aren't your own, use capabilities. I have a capability that manages an attribute modifier for SharedMonsterAttributes.MAX_HEALTH here: API, implementation. It's also used by the following classes: [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/command/CommandMaxHealthBase.java]CommandMaxHealthBase[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/command/CommandMaxHealthAdd.java]CommandMaxHealthAdd[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/command/CommandMaxHealthGet.java]CommandMaxHealthGet[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/command/CommandMaxHealthSet.java]CommandMaxHealthSet[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/block/BlockMaxHealthGetter.java]BlockMaxHealthGetter[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/block/BlockMaxHealthSetter.java]BlockMaxHealthSetter[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/item/ItemMaxHealthGetter.java]ItemMaxHealthGetter[/url] [url=https://github.com/Choonster/TestMod3/blob/f2476600a276d8a95280078e61049b709ba90466/src/main/java/choonster/testmod3/item/ItemMaxHealthSetter.java]ItemMaxHealthSetter[/url]

Note that by default, the TileEntity is removed from the world before Block#getDrops is called. You need to delay its removal like Forge's patch to BlockFlowerPot does.

Make sure you're looking at the right branch. The 1.10 branch was committed to 3 hours ago.

Forge's blockstates format assumes that all non-array values of "variants" are objects with at least one property. The "snowy=false,variant=dirt" variant is an object without any properties, so the deserialiser (ForgeBlockStateV1.Deserializer#deserialize) calls Iterator#next on the object's entry set iterator and causes a NoSuchElementException to be thrown. To fix this, add a property to the variant (even a dummy value not used by the format will work). Forge's blockstates format also assumes that any object values of "variants" with an object as their first value aren't fully-defined variants. All of the variants in your blockstates file that specify custom textures have an object as their first value, so the deserialiser condenses them together instead of treating them as fully-defined variants. To fix this, add a property before the "textures" property in each of the variants (again, dummy values will work here). These assumptions aren't really documented anywhere (except a comment in the deserialiser mentioning the second) and I didn't know about them before this. Both the Forge and Vanilla blockstates formats expect models to be specified in the format "[domain]:[path]", which will be converted to assets/[domain]/models/block/[path].json. You have an extra block/ prefix for the default model. You can see these fixes applied to your blockstates file here.