Draco18s

1) Mark dirty says "this needs to be saved to disk" not "send this to the client." 2) I believe the method you want is now called worldObj.markAndNotifyBlock(pos, chunk, iblockstate, newState, flags); 3) The client isn't updating its own values on its end because you did if (worldObj.isRemote) return; (you can safely remove that for the most part)

That AABB is both 0 in size and centered near the origin of the world. You should be using new AxisAlignedBB(playerIn.pos.getX() - 10, playerIn.pos.getY() - 10, playerIn.pos.getZ() - 10, playerIn.pos.getX() + 10, playerIn.pos.getY() + 10, playerIn.pos.getZ() + 10)

Sigh. Why do people subvert the proxy system by putting client side code in a common location that's only called from the client proxy? That common location still needs to contain valid code as far as the server is concerned, which references to non-existent classes is not.

Override getUpdatePacket and getUpdateTag() getUpdatePacket will return a new package with the contents returned from getUpdateTag, where you write all the TE's information in it. You can get away with just using the same nbt that's saved to disk, as long as there isn't a ton of data the client doesn't need.

Then sync the data.

That depends: Does the client ever need to know this information?

JSON is not OBJ so don't call it a "JSON OBJ model." It's a JSON model. You have also posted literally no code.

Hash-tag: no one is surprised.

Its because you set your item's registry name as "Hoja" with a capital (go look at your code).

make sure your file and folder names are in all lower case.

Item Variants. Duh. Did you really think that all 16 wool colors had the same unlocalized name? No, they don't. Also, setUnlocalizedName will not throw an error if an unlocalized name has already been set. setRegistryName absolutely will.

Step 1: Hold the data in your own, native data structure during runtime Step 2: When the chunk saves, loads, or unloads do the appropriate thing with that data to save it into the chunk's nbt. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/util/OreDataHooks.java https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/FlowerEventHandler.java#L71-L97

Something something there will be problems.

The ID value is yours, it will never clash with another mod's. Just make it a fixed value, there's no reason for it to be random.

If you're replacing an item in the hotbar (the currently active item) you should be able to figure out which slot is currently active. Even if not you can loop over the hotbar and compare item stack instances directly (one will return true for stack == otherStack )

From what I understand it has to be called in Init, but before some things and after others and was just prone to problems that if not properly dealt with would cause issues. You might have code that works fine in 1.8, but you should update to using ModelLoader.setCustomModelResourceLocation on newer version of MC anyway.

You need to look at the item's metadata and convert from meta to state.

Yes, because using the ModelMesher directly has issues. Which is why the ModelLoader method exists.

You can just replace the itemstack in the player's inventory.

You should rename that to "lib" or "library."

That depends. Where are you wanting to do this and why?

location is null. This is passing null: changeToIce(par1MovingObjectPosition.getBlockPos(), 5); par1MovingObjectPosition.getBlockPos() is not guaranteed to not be null.

Aren't models suppose to be registered in the pre-initialization phase? The way he was doing it, no. ModelLoader.customModelLocation, yes.

Yes. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L120

Gosh, probably because that's what people told me to do on this forum back when I was trying to figure out how to combine textures....