Choonster

You can fix this by registering an IStateMapper that returns an empty Map. I'm not too sure about this.

The crash looks like this issue, which was fixed in Forge 1.11.2-13.20.0.2235. Update to the latest of version of Forge and it will either crash with a clearer message or not crash at all. However the root cause of the issue is the fact that your Block is being rendered as the missing model. The FML log will have an error in it stating exactly why this is, but I suspect it's because your Block has two properties that aren't accounted for in the blockstates file. To fix this, either register an IStateMapper for your Block to ignore those properties (recommended) or include them in your blockstates file (not recommended).

Entity#getEntityBoundingBox is the method you want, not Entity#getBoundingBox.

Override Block#getComparatorInputOverride to return the comparator output level stored in your TileEntity. When this level changes, call TileEntity#markDirty to notify Minecraft that the TileEntity's data has changed (so the chunk containing it won't be skipped when saving the world) and update the output level of adjacent comparators. The client shouldn't be involved in this, it will simply return 0 (the default value of an int) from Block#getComparatorInputOverride if the TileEntity's output level isn't synced (which is fine, since the server's level will be the one used by the comparator).

You cannot use Thread.sleep, that will pause the client or server thread completely and stop the game from running for the duration of the sleep. If you want to delay an action by a certain amount of time, you need to schedule a block update or count ticks in a ticking TileEntity or tick event handler. Why is the client telling the server to run a command? The server should be in charge of the game state (e.g. running commands) and send any data necessary for display purposes to the appropriate clients. The client doesn't need to know the comparator output level, it can simply return 0 while the server returns the actual value. You can't store mutable data in fields of your Block class, it's a singleton shared between all occurrences of the block. Mutable data must be stored in the block state or TileEntity.

World#spawnParticle(EnumParticleTypes, double, double, double, double, double, double, int...) does nothing on the server, it only spawns particles when called on the client. You need to use one of the spawnParticle overloads from WorldServer instead.

You can't delay the return statement, but you can just send the response packet from the SimpleNetworkWrapper as you would a regular packet.

That's correct. When you have a method that does if (some_boolean_expression) return true; else return false;, you can simplify it to return some_boolean_expression;.

You need to render the quads for all EnumFacings (and null), not just null.

Don't return false when the Block changes, otherwise your Block's TileEntity will remain after the IBlockState at its position was replaced with another.

By default, mod TileEntities are replaced any time the block state changes. To change this, override TileEntity#shouldRefresh to return true when the Blocks of the old and the new IBlockStates are different.

I meant EntityCamera, yes. It's actually the EntityHanging#facingDirection field that's null rather than EntityHanging#hangingPosition as I initially suspected; this is because the EntityCamera(World, BlockPos, EnumFacing) constructor doesn't call EntityHanging#updateFacingWithBoundingBox.

You called EntityHanging#onValidSurface without setting EntityHanging#hangingPosition to a non-null value. which probably means that you're calling the EntityHanging(World) constructor instead of the EntityHanging(World, BlockPos) constructor. If this isn't the case, post the ModSecurityCamera class.

You do need your own implementation of IRecipe, though it can extend an existing implementation like ShapedOreRecipe. You need to implement IRecipe#getRemainingItems to return a list containing the container item (ForgeHooks.getContainerItem) for every slot except the shears. For the shears, copy the stack and then damage the copy with ItemStack#attemptDamageItem. If the shears were broken (ItemStack#attemptDamageItem returned true), call ForgeEventFactory.onPlayerDestroyItem with the player returned by ForgeHooks.getCraftingPlayer as the first argument to fire PlayerDestroyItemEvent and then use ItemStack.EMPTY (null in 1.10.2) as the remaining item for the slot. If the shears weren't broken, use the damaged stack as the remaining item for the slot.

Did you try using the debugger?

I recommend handling it in an override of Item#itemInteractionForEntity, which is called when a player right clicks your item on an entity.

No, LootEntryTable takes the ResourceLocation of a LootTable and loads it from the LootTableManager when loot is generated from the containing LootTable. I use LootEntryTable to add one LootTable to another here.

ItemStack capability syncing has been discussed quite a lot in GitHub issues (e,g, here and the issues/PRs linked by it), but there's no real resolution yet. One method of syncing that works fairly well is a custom IContainerListener, as described in this thread. I recently implemented this for my mod's item capabilities here. One issue with this is that an item's capability data is completely reset when taking it out of the creative menu.

It doesn't look you have access to the LootTableManager from LootTableLoadEvent. Since the event gives you the option of replacing the LootTable with another one, it probably should give you access to the LootTableManager. You could suggest this be changed, but in the mean time you can remove the LootTable's existing LootPools and then add a new one with a LootEntryTable in it that references the replacement LootTable.

I can't see any obvious issues from a quick skim of your code, so I suggest you set some breakpoints and step through the code in the debugger to figure out exactly what's happening and where and why it's failing.

The ForgeData tag has never been automatically synced. If you want the data available on the client, you need to sync it yourself. That said, you shouldn't need it on the client. Cancelling EntityJoinWorldEvent on the server will prevent the entity from being sent to the client at all.

The type argument of your IStorage implementation must be the interface you register the capability for (IThirst), not an implementation of it (Thirst).

Minecraft doesn't really have the concept of books, it just has several items that are called books and are indirectly related to each other. The only way to achieve this is with a whitelist of book items and an API to add items to the whitelist.

You can get an entity's bounding box with Entity#getEntityBoundingBox and then use AxisAlignedBB#intersects(double, double, double, double, double, double) to check if it intersects with the region's coordinates. This is essentially what World#getEntitiesWithinAABB does for every entity in the chunks covered by the AABB.