Choonster

TileEntity#shouldRefresh has nothing to with whether Block#onBlockPlaced or Block#onBlockAdded are called, so I'm not sure why that's happening. The default behaviour of TileEntity#shouldRefresh for non-vanilla TileEntities is actually the same as what you had in FruityTileEntity(return true when the IBlockState changes), so removing the override shouldn't have changed anything.

FruityTileEntity overrides TileEntity#shouldRefresh to return true when the IBlockState has changed, not when the Block has changed. If you put a breakpoint in BlockBoiler#createNewTileEntity with the condition worldIn.isRemote (i.e. the method is being called on the logical client), can you see what's causing the new TileEntity to be created? Side note: Don't use ITileEntityProvider, override Block#hasTileEntity(IBlockState) and Block#createTileEntity instead.

Most of the deprecated methods in the Block class are deprecated because they should be overridden, but not called. Call the equivalent methods in IBlockProperties (which IBlockState extends) instead. Don't include block/ in the blockstates file's model locations, Minecraft automatically adds that. I explain how model locations are mapped to model files here. I believe BlockTorch only does its sate/metadata conversions in that way to maintain compatibility with the original metadata values, which aren't the same as the facing indexes uses in other parts of the game. For your own block, use EnumFacing#getIndex and EnumFacing.getFront instead. See BlockObserver for a simple example of this. To create a PropertyDirection that accepts all EnumFacing values, you can use the overload of PropertyDirection.create without a Predicate argument. If you say that it doesn't work even without the block/ prefixes in the blockstates file, I'm not sure exactly what the problem is here. Could you create a Git repository of your mod (if you haven't already) and link it here? See my mod and its .gitignore file for an example of the repository structure and which files to include.

You're still using 1.7.10, which isn't supported here.

Upload the FML log (logs/fml-client-latest.log in the game directory) to Gist or Pastebin and link it here.

Play on a newer version (recommended) or ask for help somewhere else (e.g. Minecraft Forum).

1.7.10 is no longer supported on this forum. Update if you want help.

Post the full stacktrace. I suspect it's being thrown because the channel name of your SimpleNetworkWrapper is too long. When you send a client-to-server IMessage, it's converted to a CPacketCustomPayload with your SimpleNetworkWrapper's channel name. This channel name is limited to 20 characters by CPacketCustomPayload#readPacketData. Server-to-client IMessages are converted to SPacketCustomPayload, which also has this restriction.

This model has a syntax error. This blockstates file has a syntax error. This item model doesn't exist.

I said to create a method to get the client World, i.e. Minecraft#world. You can only reference Minecraft in the client proxy, you can throw an exception from the server proxy. I have an example of this in my mod's proxy classes.

Upload the FML log (logs/fml-client-latest.log in the game directory) to Gist or Pastebin and link it here.

From where? If you're talking about the methods where you were using the client World, I already explained how to get the proper World.

Any World on the logical server (when World#isRemote is false) will be a WorldServer. World#getMinecraftServer will return the MinecraftServer instance (if it's a server-side World).

1.7.10 is no longer supported on this forum, update if you want help.

Upload the FML log (logs/fml-client-latest.log in the game directory) to Gist or Pastebin and link it here.

Tinkers' Construct requires Mantle, you don't have it installed. I'm not sure why FML reached the mod construction phase, it should have stopped loading as soon it saw that a dependency (Mantle) was missing and displayed the missing mods GUI.

WorldRenderer was renamed to VertexBuffer in 1.9 and then to BufferBuilder in 1.12. AxisAlignedBB was moved to the net.minecraft.util.math package in 1.9. BlockPos was moved to the net.minecraft.util.math package in 1.9. MovingObjectPosition and MovingObjectPosition.MovingObjectType were renamed to RayTraceResult and RayTraceResult.Type in 1.9.

You can still use OreDictionary.WILDCARD_VALUE (32767) as the metadata of an ingredient to match any metadata value. You can create custom IRecipe and Ingredient implementations by creating an IRecipeFactory or IIngredientFactory and specifying them in your _factories.json file. You can see some examples here and here.

I don't fully understand your code, but could it be that the IBlockState at that position is changing, triggering a refresh of the TileEntity (as determined by FruityTileEntity#shouldRefresh)?

In future, you can use Gist or Pastebin to post large log files.

Upload the FML log (logs/fml-client-latest.log in the game directory) to Gist or Pastebin and link it here.

You must set the registry name of an IForgeRegistryEntry with IForgeRegistryEntry#setRegistryName before registering it. For ItemBlocks, use the Block's registry name.

I feel like there may have been a misunderstanding here, since TileEntities seem like the ideal tool for this job. Could you link this reaction? I'd like to see the reasoning behind it. I don't really get what nested Maps have to do with packet size. You need to send all three coordinates in the packet regardless of how the position is stored. There shouldn't be any major difference in memory consumption between an array of ints and an array of objects, if anything you're probably increasing the memory overhead by storing arrays of primitive wrapper classes (Integers). I'm not an expert on this, you should profile it if you want actual numbers. Storing object references rather than IDs shouldn't affect CraftTweaker, just convert from the ID to the Material object.

You should be using IItemHandler, Forge's replacement for IInventory. You can use or extend ItemStackHandler, the standard IItemHandler implementation. ItemStackHandler implements INBTSerializable, you should use those methods to read it from/write it to NBT. Alternatively, use the IItemHandler capability's IStorage instance. I'm not sure exactly why your code isn't working, but I noticed that you're comparing the ItemStack to ItemStack.EMPTY directly; don't do this. Use ItemStack#isEmpty to check if an ItemStack is empty, ItemStack.EMPTY is just one possible empty ItemStack.

I'm glad you figured it out.