Choonster

EnderCore has an implementation of "no spam" chat messages here. Each time a "no spam" message is added to the chat, it removes any previous "no spam" messages.

If the initial state is only based on the neighbouring blocks, you only need to override Block#onBlockAdded . This is called whenever the Block is added to the world, regardless of whether it was done by a player or something else. Are you sure you want to store this information in the metadata and not just calculate it in Block#getActualState ?

You need to override Block#getMetaFromState and Block#getStateFromMeta to allow your block to be serialised/deserialised correctly. You generally shouldn't be calling these methods yourself. When setting a block in the world, you do need to use IBlockState#withProperty to set each property to the appropriate value.

PropertyEnum doesn't support null values. I think the best option is to create a new enum with the required values. You'll probably want to include a method to get the corresponding EnumFacing for each enum value. Either mark it as @Nullable and use null for the "no direction" value or use Optional<YourEnum> as the return type and Optional.absent() (Guava) or Optional.empty() (Java for the "no direction" value. Edit: Automatic smileys are annoying when talking about Java 8 in parentheses.

You should create and store the instance in a separate class in preInit instead of in the class itself. Java doesn't load a class and run its static field initialisers until it's referenced somewhere. With your current code, the instance will never be created and inserted into the array until the ApocalypseWorldType class is referenced.

This code worked for me. Are you definitely using your BlockEnderium class? As for the bucket, try debugging it yourself.

You didn't post your code, but this issue is very common. The ItemAxe(ToolMaterial) constructor only works for vanilla ToolMaterial s, you need to use the ItemAxe(ToolMaterial, float, float) constructor. This may or may not exist in 1.9, which is outdated. You should update to 1.10.2.

You need to subscribe to FillBucketEvent like UniversalBucket does. Why not just use the universal bucket, though? In your constructor, add Blocks.PORTAL to the BlockFluidBase#displacements map.

BlockHelper was renamed to BlockMatcher .

Fields and methods added by vanilla have three names: The MCP (deobfuscated) name, the SRG (semi-obfuscated) name and the Notch (obfuscated) name. When writing normal Forge code, you only need to use MCP names and your code will be obfuscated to SRG names when you build it. When accessing a vanilla field/method via reflection, you need to check for both the MCP and SRG names since ForgeGradle's obfuscation process doesn't change field/method names in strings. Use ReflectionHelper.findField to access a vanilla field or ReflectionHelper.findMethod to access a vanilla method (the instance argument is unused, so you can just pass null ). These iterate through the provided names until they find a matching field/method. This lookup process is expensive, so you should do it once and store the Field / Method object in a private static final field.

MobEffects stores the vanilla Potion instances, yes. The PotionEffect constructor takes the Potion instance directly instead of taking the numeric ID. There's also the new concept of a PotionType , which is a collection of PotionEffect s. These are mainly used for potion items.

There aren't many examples of the new registry system, but you can search GitHub for net.minecraftforge.fml.common.registry.RegistryBuilder to find mods that use it.

If they're metadata values with complex effects, create a separate Card class with the required methods and extend this for each card type. Don't create Item instances/classes that are never registered. In your ItemCard class, store an array of Card objects. Use the ItemStack 's metadata value to look up the Card in this array and call the required methods on it. If you want the card system to be extensible by other mods, you can make Card extend IForgeRegistryEntry.Impl and create an IForgeRegistry to store the Card s using RegistryBuilder . To store the Card in the ItemStack , either use NBT (i.e. store the registry name) or a capability (i.e. store the Card object). Edit: I thought this thread seemed familiar. I offered you similar advice a couple of months ago.

Are the cards metadata values of the same Item or are they separate Item s? If they're metadata values, don't create a separate Item class for each one and handle all the effects in one class. If they're separate Item s, you don't need to check the metadata value; just handle each effect in its own class.

Entity#getCollisionBoundingBox returns null unless it's overridden to return something else; only Boats, Minecarts and Shulkers do this. The method you want is Entity#getEntityBoundingBox .

BiomeEvent.CreateDecorator will only ever be fired in postInit unless someone does something weird. It's normal that it's not fired when generating chunks, I was mistaken in my first post. Setting BiomeDecorator#bigMushroomsPerChunk to 0 should prevent any big mushrooms from generating, yes. If you want to stop a feature from generating, I'd recommend subscribing to DecorateBiomeEvent.Decorate , checking for EventType.BIG_SHROOM and setting the result to DENY .

Nobody's going to just give you the code, that's not how this forum works. You need to spend the time to learn Java properly and then fix the code yourself.

The server should be handling the tick events and adding the effect, the client shouldn't be doing anything here. There's no need for packets.

ModelLoader methods have always needed to be called in preInit. ItemModelMesher methods have always needed to be called in init or later.

Are you definitely calling this in preInit? Post the FML log, it should say what went wrong.

Without brackets, yes. ModelLoader.setCustomModelResourceLocation sets the model for a single Item and metadata value. This is the only method you need to call to set the model for an item.

I have an explanation of the model loading process and how model locations are mapped to model files here. If you want the item form to use the same models as the block form use new ModelResourceLocation(item.getRegistryName(), "igneous_type=[type]") as the location for each metadata value, where [type] is the value of the igneous_type property for that metadata value. This will load the models specified by the blockstates file with the item's registry name (which should be the same blockstates file used for the block models), using the igneous_type=[type] variant. You can see how I do this for my coloured rotatable blocks here ( registerBlockItemModelForMeta is just a wrapper around ModelLoader.setCustomModelResourceLocation ). The blockstates files can be found here and here.

Which version of Minecraft are you using? Always specify this in the thread title. You should also wrap your code in [nobbc] [/nobbc] tags so it's formatted properly.

Most mod authors will have a thread for their mods on Minecraft Forum with the official download links. Many host their mods on CurseForge/Curse.

In that mod, ClientProxy#preInit and ServerProxy#preInit both call the super method ( CommonProxy#preInit ), so the code is run on both sides. This is equivalent to running the code from your @Mod class directly, so there's not much point in using the proxy system for it.