Choonster

That's strange. I can't see any obvious problems with your blockstates file, so I'm not sure why the variants aren't being found. You could try setting some breakpoints in the model loading code to see if you notice anything going wrong. Could you create a Git repository for your mod (if you haven't already done so) and link it here? I'll try to do some debugging and find the source of the issue.

ItemStack#getOrCreateSubCompound has the SRG name func_190925_c , so that's probably the method name you'll need to use. I suggest you update your MCP mappings so this is deobfuscated for you.

Aww for fuck's sake, haven't you see anything on these forums about Capabilities? To expand on this slightly: The whole point of the Capability System is that you don't implement every interface on your Entity / TileEntity / Item , instead you store an instance of the interface and provide it from the ICapabilityProvider methods. The Capability System is documented here.

World#setBlockState sets the IBlockState at the specified position, which includes the Block and any properties that are saved to metadata. You can read more on this here. Use Block#getStateForPlacement(World, BlockPos, EnumFacing, float, float, float, int, EntityLivingBase, EnumHand) to get the IBlockState that would be placed by an entity's held item.

Not until it's fixed, no. I've reported it here.

Biome#getSpawnableList (used by EntityRegistry.addSpawn ) returns the empty list for non-vanilla EnumCreatureType values, which throws an UnsupportedOperationException if you try to modify it. This will happen any time EntityRegistry.addSpawn is called with a non-vanilla EnumCreatureType . I'm working on a mod to reproduce this error so I can report it on GitHub.

This is correct. Your NetherExModels#registerModel(Object, String) method hides this error by using instanceof checks and not checking for null . I would recommend replacing these instanceof checks with separate overloads taking Block and Item arguments respectively.

You're dividing two integers, so Java is using integer division and then converting the result to a double . You need to cast one of the numbers to a double so Java converts the other one to a double and uses floating-point division.

ChunkDataEvent.Load is only fired on the server side, so you need to subscribe to ChunkEvent.Load to create a default IVoidEnergy for any chunk that doesn't have one (i.e. client-side chunks). To render the current energy value of a chunk on screen, you'll need to sync it from the server to the client using a packet. Do this when a player starts watching a chunk ( ChunkWatchEvent.Watch ) and when the energy value changes. Use WorldServer#getPlayerChunkMap , PlayerChunkMap#getEntry and PlayerChunkMapEntry#sendPacket to send a packet to all players watching a chunk and SimpleNetworkWrapper#getPacketFrom to get a Packet from an IMessage .

To do this for your own block, override Block#getBlockHardness to return -1 (if it's unbreakable for all players) or Block#getPlayerRelativeBlockHardness to return 0 (if it's unbreakable for some players). This can't be done for vanilla blocks.

You don't need to explicitly specify the value property of an annotation, just pass the values directly to the annotation. e.g. @Mod.EventBusSubscriber(Side.CLIENT) .

Events that extend FMLEvent (e.g. FMLPreInitializationEvent ) still need to be handled by instance @Mod.EventHandler methods in your @Mod class. You should instantiate your Item s in a static initialiser and register them in response to RegistryEvent.Register<Item> . The same applies to all other IForgeRegistryEntry implementations. You can see how I do this here and in the other classes in the init package.

Create an implementation of ICapabilitySerializable that stores an IItemHandler instance (e.g. an ItemStackHandler ), provides it from the ICapabilityProvider methods and reads it from/writes it to NBT in the INBTSerializable methods. Override Item#initCapabilities to return a new instance of this class.

Use the capability system to attach an IItemHandler inventory to an ItemStack . Specifically, override Item#initCapabilities to return an ICapabilityProvider that provides the IItemHandler capability. The ICapabilityProvider also needs to implement INBTSerializable to read the data from and write the data to NBT. Forge provides the ICapabilitySerializable interface for this purpose: it's simply a shorter way to implement both ICapabilityProvider and INBTSerializable .

ModelRegistryEvent is fired before preInit, so it needs to be handled by a static @SubscribeEvent method in a class annotated with @Mod.EventBusSubscriber . You should also be registering all of your IForgeRegistryEntry implementations (e.g. Item , Block , SoundEvent ) in response to RegistryEvent.Register<T> , where T is the registry's type. You can read more about events here.

The smoke particles are spawned by EntityDragon#onDeathUpdate , the beams are rendered by LayerEnderDragonDeath .

I don't know why that's happening, my code doesn't have that issue. I suggest stepping through your code in the debugger to see what's going on.

Post the FML log (logs/fml-client-latest.log), there's almost certainly an error in it telling you what's wrong.

For a JSON model, you need an Armatures file to specify the joints and clips for the model. For a B3D model, the joints and clips are specified in the model itself. It looks like OBJ models aren't supported by Forge's animation system. You also need an Animation State Machine file to specify how the model should be animated. For a block model, your TileEntity needs to provide CapabilityAnimation.ANIMATION_CAPABILITY and have an instance of AnimationTESR registered as its TESR . Your Block needs to have the Properties.AnimationProperty unlisted property and it can optionally have the Properties.StaticProperty property, which will be set to false when the model is being rendered by AnimationTESR . For an entity model, your Entity needs to provide CapabilityAnimation.ANIMATION_CAPABILITY and use a ModelBase that renders the animated model (like AnimationModelBase ). For an item model, your Item needs to provide CapabilityAnimation.ANIMATION_CAPABILITY (from the provider returned by Item#initCapabilities ).

You can see the animation test mod here and its assets here. The Mana Pump and Coporea Crystal Cube from Botania both use the animation system. You can see the assets here. Edit: There's also an explanation of the Animation State Machine format here. Edit 2: Updated Botania links.

There's no need to create a separate parent interface ( IVoidStorage ) if you're copying IEnergyStorage instead of extending it. Just use the one interface with all the methods from IEnergyStorage in it. If you want a default energy value for each chunk, change the NBT deserialisation method (the ChunkDataEvent.Load handler) to use that default value when a chunk doesn't have a stored value. My code uses 0 for the default value.

I don't think you do need to send a packet here. You can create a method in your @Mod class that takes (Map<String, String>, Side) as arguments and returns a boolean and then annotate it with @NetworkCheckHandler . This will be called when connecting to the remote client/server to check if the mods on that side are acceptable. The Map<String, String> arguments contains the mods on the remote side, with mod ID keys and mod version values. The Side argument is the remote side, so it will be SERVER if the method is being called on the logical client or CLIENT if the method is being called on the logical server. Return true to accept the connection or false to reject it. You can check if your mod ID is in the Map (i.e. if your mod is on the remote side) and then store this as a boolean somewhere to use it outside this method. JEI does this here and here.

You need a way to store a per-dimension, per-side Map<ChunkPos, YourData> . There are other ways to do this, but capabilities are probably the easiest. I made a system similar to this last night, it stores a single energy value for each chunk. You can see the implementation here. To the OP: If you're going to use my code, please try to understand how it works and re-implement it yourself rather than copy/pasting it.

To do what Choonster said you cant use a world Capability. Instead use just the events he suggested. Mainly the ChunkDataEvent ones. They will allow you to save specifically to a chunk. Through the usage of the ChunkDataEvent.Load/Save#getData which returns an NBTTagCompound. I didn't know these events existed and glossed over the ChunkDataEvent in Choonsters post. You can use a World capability to store the Map at runtime, it just won't save the data to NBT itself; that will be handled with ChunkDataEvent.Load / Save .

I don't know what you're talking about. ChunkPos is simply a class that stores the x and z coordinates of a single chunk. When ChunkDataEvent.Load fires, read the data for that Chunk from the NBT and store it in the Map . When ChunkDataEvent.Save fires, write the data for that Chunk from the Map to the NBT. When ChunkEvent.Unload fires, remove the data for that Chunk from the Map . Use the Chunk 's ChunkPos as the key for the Map .