Choonster

Yes, that will work. The doc comment of the @Mod annotation does show a brief example using required-after, but doesn't specify the exact format of the dependencies string (the field's doc comment references ModLoader's "priorities" string, so it probably hasn't been updated in a few years).

In the dependencies field of your @Mod annotation, you can list dependencies as before / after (optional dependency) or required-before / required-after (required dependency).

Only spawn the grenade entity and play the sound if you successfully consumed the reagent (in the if (player.inventory.consumeItem(...)) block). Item#setMaxStackSize should only be called once (in the constructor or wherever you instantiate the class). There's no reason to call it every time the item is right clicked.

Do you need to handle the cooldown in that manner? One alternative would be to store its last use time ( World#getTotalWorldTime ) in the NBT and just compare that to the current time when the player tries to use it. I do something like this here. If you have to handle the cooldown like this, override Item#shouldCauseReequipAnimation to ignore the NBT of the stacks.

That is the correct way to get the client player, but you probably shouldn't be changing this on the client side unless it's a client-only mechanic. If other players need to know about the change, you should send a packet to the server to tell it that the key was pressed and then handle the change there. You shouldn't be using block or item IDs at all unless you have a very good reason to (which is almost never the case). To get the Block form of an Item , use Block.getBlockFromItem .

1.8 is slightly different, but it's still possible to do. Look at the WorldGenMinable(IBlockState, int, Predicate) constructor and how it's called by the two-argument constructor.

For reference, I'm also trying to help the OP in their thread on Minecraft Forum.

Yes, you can have as many states as you want; it's just that you can only store 16 possible states in the metadata. Beyond that you have to use a TileEntity and one of the two methods I mentioned. Most Forge and vanilla code uses Block#getActualState , Block#getExtendedState is only used for rendering ISmartBlockModel s and returns the result of Block#getActualState by default.

The furnace only uses a single model rotated around the y axis different amounts depending on the facing property. Is there a reason you have to use an unlisted property? It's entirely possible to use a normal property whose value is set from a TileEntity in Block#getActualState or Block#getExtendedState , look at BlockFlowerPot for an example.

You don't. TileEntities are only written to NBT when the world is being saved, at runtime you should use the TileEntity 's fields directly. Treat it like a normal Java object. Get the TileEntity at the Block 's position ( World#getTileEntity ), cast it to TileEntityMimicBlock and call the getState method on it to get the IBlockState that particular instance is mimicing.

You should probably review the basics of Java before you try to mod. A class can only extend a single class. Just extend BlockLog instead of Block . You don't need to override Block#getRenderType unless you want to use a different renderer to the super class. Block uses 3 (JSON model) and BlockLog doesn't override it. Your addInformation method won't do anything unless you're calling it yourself. It doesn't override any super method.

TileEntity#getTileData isn't meant to be used for your own TileEntities , it's meant to be used with TileEntities from vanilla or other mods. It returns an NBT tag completely separate from the NBT you read from/write to in TileEntity#readFromNBT and TileEntity#writeToNBT . Your Block#getExtendedState override should be calling TileEntityMimicBlock#getState on the TileEntity at the Block 's position.

You'll need to be a bit more specific than that. What are you trying to do, how is it not working, what errors are you getting?

Waila calls IWailaDataProvider#getNBTData on the server, so you can just write the appropriate values from the TileEntity to the NBT. If you don't register an NBT provider for the Block or TileEntity, Waila will simply call TileEntity#wrtieToNBT for you. You should use the IWailaDataAccessor 's NBT directly rather than the TileEntity in getWailaStack , getWailaHead , getWailaBody and getWailaTail methods.

BlockLog overrides onBlockPlaced to set the rotation of the log from the side of the other Block that the player clicked on. If you extend BlockLog , this will be done for you. The log models use block/cube_column and block/column_side as the parent models for the regular and side models, respectively. Look at the blockstates file for any log type to see how it selects the model to use.

ChunkProviderHell and ChunkProviderEnd in the net.minecraft.world.gen package. In IDEA, you can press Ctrl-N and start typing a class name to search your project and libraries for matching classes. Eclipse probably has a similar feature.

Are you not aware that 1.8 uses JSON models for most blocks and items?

I see, thanks for that explanation then. That makes me curious how the entitydata command works, perhaps it calls the readfromNBT function again. If you look at its implementation in 1.8, you'll see that it tells the Entity to write itself to NBT, merges that with the NBT specified in the command and then tells the Entity to read from the merged NBT. To address your initial confusion of ThrownPotion vs. EntityPotion : every Entity class is registered with a unique name. ThrownPotion is the name that the EntityPotion class is registered with.

Use World#getBlockState to get the current block state at the specified position, then use IBlockState#getValue to get the value of each property. Some blocks have properties that aren't stored in the metadata (e.g. connection state of panes), you can use Block#getExtendedState to get an IBlockState with the actual values of these properties.

You should pass the actual state ( World#getBlockState ) rather than the default state ( Block#getDefaultState ) to harvestBlock . At the time of removedByPlayer being called, the Block is still in the world.

You can also download exports of the mappings from the MCPBot site. Alternatively, you can view the mappings used by your ForgeGradle workspaces in the ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<channel>/<version> directory (replace ~ with %USERPROFILE% on Windows).

Override the BiomeGenBase#getGrassColorAtPos method that Failender mentioned.

Not unless you create your own wire, vanilla redstone can only store power levels 0-15.

Try overriding Block#removedByPlayer to call Block#harvestBlock if the player that destroyed the block is in creative mode.

Simply returning true from Block#onBlockActivated should prevent the Eye of Ender from spawning. I just wrote this simple example and it works without issue.