Leaderboard

Look at the jump boost potion and the slowness potion.

The Axis would be axis the bullet goes when first fired. The shulker uses the side it's attached to.

There is this method you can use also. Just check what int it returns and if it's on the range of inventory slots you want (Because I don't know if it would also return armor slots as empty slots) player.inventory.getFirstEmptyStack() Depending on what number you get, you will know that the player has a free slot.

And again.. There must be something wrong with my Modding environment. I restarted the game 10 times to verify that update() worked.. Only to find out it stopped working after a while...

[IGNORE THIS POST!!]] Finally! It seems i've found the issue in my code. @diesieben07 was right stating that the tile entity didn't register properly Se comments below // I think the registered tile entity excluded ITickable when writing <?extends TileEntity> public static void registerTileEntity(final Class<?extends TileEntity> tileEntityClass, final String name) { GameRegistry.registerTileEntity(tileEntityClass, name); } // when I removed it, it seems to run as I want. I assume it just takes whatever the class extends and implements. public static void registerTileEntity(final Class tileEntityClass, final String name) { GameRegistry.registerTileEntity(tileEntityClass, name); }

That's some nice info jabelar, but it's not working like that. The list loaded during chunk loading does not appear to be realized until after certain events occur, one such event is GUI interaction. I am hoping someone can track down why this is the case, but for now scheduling infrequent tick updates is the only thing that works 100% of the time in all cases. Basically when the block is placed or the entity is loaded. onLoad for the entity, onBlockPlacedBy for the block class just because all you need is the block instance since you do have to extract the entity from the world. Which is why I wish the update calling was more reliable. This does explain a lot about Mekanisms and why that mod breaks so much, especially during multiplayer. Thankfully most of what I am doing doesn't require constant tick checks.

world = player.getWorld(); //now you have everything you need

Awesome, thanks! My main package is in src/main/java and when I put my recipe in src/main/resources/assets/<modname>/recipes it worked!

Put the assets folder in the <projectroot>/resources folder if it's for Eclipse. I don't know about IntelliJ, but it should be the same. So it looks like this <projectroot>/resources/assets/<modname>/*

create an invisible entity with the correct location and rotation, then have the player mount it (sit on top of it). that's how "sitting" works (there are mods that allow you to sit on solid blocks or just stars). don't forget to remove your entity.

No that's not required, you can use ItemStack.EMPTY safely.

state = world.getBlockState(pos); //this gets you the IBlockState (Block + Metadata combination) block = state.getBlock(); //this gets the Block (no metadata)

A stack of size 0 (but still with some other item) won't == ItemStack.EMPTY but it will still resolve .isEmpty() as true.

A folder called recipes in your assets.

World#updateEntities() runs every tick and iterates through the entire tickableTileEntitiesList and calls their update() method. So the update() method should be called EVERY tick for any ITickable tile entity (provided it is in the tickableTileEntitiesList). To get on the tickableTileEntitiesList, that happens in the World#addTileEntity() method so long as it is in the loadedTileEntityList and also instanceof ITickable. I suppose it is possilble that there is some cases where the loadedTileEntity list isn't updated by the time the addTileEntity() method is called. The updateEntities() method goes through these general steps in this exact order: 1. Iterates through tileEntitiesToBeRemovedList and runs onChunkUnload() method, removes them from the tickableTileEntitiesList and then removes them from the loadedTileEntitiesList. 2. Iterates through tickableTileEntitiesList and if the tile entity is valid and hasWorld() are true, checks that the block in that position is loaded and inside the world border. If the tile entity is invalid it is removed from the loadeTileEntitiesList and also from the chunk's tile entity association to that BlockPos. Interestingly it is not removed from the tickableTileEntitiesList at this time. 3. Iterates through the addedTileEntitiesList. I find it interesting that it does the adding at the end, but probably an attempt to make sure all these lists are in sync. But it means that there is one tick between adding the tile entity and the first time it is ticked. Basically the tile entity is checked to be valid and then added to the loadedTileEntitiesList. Then it separately checks if the block is loaded and associates it to the chunk's block position including calling a notifyBlockUpdate(). Basically, there are a lot of things that need to be synced and in common Minecraft fashion the coding isn't super organized leaving suspicion related to logical holes. In fact there are comments already in this code such as: //Forge: Bugfix: If we set the tile entity it immediately sets it in the chunk, so we could be desynced That's about all the effort I'm interested in putting into investigating at this time, but hopefully gives you some ideas on how to debug. I would use the debugger and set breakpoints throughout the World#UpdateEntities() method and watch the order in which your tile entity is added to each list, and when it gets the update() calls. However, my main point is that the intention seems to be that within one tick from a block with tile entity being added, it should be on the loadedTileEntitiesList and if it is also ITickable should run update() every tick from then on. If yours is not, then it is a bug somewhere.

It isn't that bad compared to what was a couple of years ago. Now there is plenty of open source code to look at if you can't find documentation. People contribute to Forge for free, so don't expect it to be professional-grade project.

From what I see, the problem is that the vanilla engine is not recognizing the modded tickable blocks until they are effected by certain events. The ITickable interface isn't checked until chunk loading, and then added to a special list. But those changes do not seem to take effect immediately after chunk loading for the version I am compiling against either. The only work around I can see is by using scheduleBlockUpdate. If the delay is high enough though, I see no issues that could hurt the mod in any way.

In the package root folder. I'd say in "source", in this case. Though you can probably put it in another folder and link it as external files, depending on your IDE.