Choonster

You should a Capability to store an IItemHandler inventory instead of using the old-style IInventory loaded from and saved to the ItemStack 's compound tag. This will store the inventory contents as objects and only write to NBT when the ItemStack is being saved. The Bit Bag from Chisels and Bits uses IItemHandler for its inventory, you can see its implementation here and here. I have a vanilla-style chest that uses IItemHandler here (all related classes are in the same repository). I have some custom capabilities here: API, implementation

You can try Trust Is Nice, But...; it seems to log blocks.

Tough As Nails does something like this, but I'm not sure how detailed the simulations are.

The interface is actually called IForgeRegistryEntry and the method to register it is GameRegistry.register .

I explain how to make a fullbright model here.

Working with offline players is tricky, but it should be possible. You can use ServerConfigurationManager#getAvailablePlayerDat to get an array of player UUID s that the server has data for. To load an offline player: Create a GameProfile with their UUID Create a FakePlayer with this GameProfile Call MinecraftServer#getConfigurationManager to get the ServerConfigurationManager . Call ServerConfigurationManager#readPlayerDataFromFile to read the player from NBT. You should then be able to get your IEEP from the FakePlayer like you would a normal player. I haven't tested this myself, so I can't guarantee that it works. Side note: 1.8.9 is outdated and IEEP is deprecated. You should update to 1.10.2 and switch to Capabilities.

Now that I've actually tested it, my previous code was incorrect. The correct code can be found here. This returns the first invalid position (so it can be displayed to the player) rather than just whether the pattern is valid.

Forge introduced the registry name system to stop people from using unlocalised names as registry names. Registry names are unique and must not change, unlocalised names aren't unique and can change at any time. If the registry and unlocalised names of an object are the same, set the registry name first and then set the unlocalised name from the registry name. You can change the unlocalised name at a later date if needed, but the registry name must remain the same.

I'd personally recommend this implementation: /** * Checks that the player is standing on obsidian and surrounded by the following pattern of blocks: * <p> * A A A A A * A R R R A * A R P R A * A R R R A * A A A A A * <p> * Where A is air, R is redstone and P is the player. * * @param player The player * @return Is the player surrounded by the correct pattern? */ public static boolean isValid(EntityPlayer player) { final World world = player.getEntityWorld(); final BlockPos playerPos = new BlockPos(player); // The block under the player must be obsidian if (!(world.getBlockState(playerPos.down()).getBlock() == Blocks.OBSIDIAN)) return false; // Iterate from -2,0,-2 to +2,0,+2 for (int x = -2; x <= 2; x++) { for (int z = -2; z <= 2; z++) { final BlockPos pos = playerPos.add(x, 0, z); final IBlockState state = world.getBlockState(pos); // If this is the outer layer, the block must be air if ((Math.abs(x) == 2 || Math.abs(z) == 2) && state.getBlock() != Blocks.AIR) return false; // If this is the inner layer, the block must be redstone if ((x != 0 && z != 0) && state.getBlock() != Blocks.REDSTONE_WIRE) return false; } } // All blocks are correct, the pattern is valid return true; } Edit: This code is incorrect. I've linked the correct code below.

When your IMessage is received, an instance is created using the no-arguments constructor and IMessage#fromBytes is called on it. Your no-arguments constructor doesn't initialise the Data or ID array fields, so they're both null when you try to access them in fromBytes . You need to send the array length in the message, then initialise the arrays with this length in fromBytes before you access them.

Post the full error, it looks like your message handler threw a NullPointerException .

There are two options: Loop from -2 to +2 on both the x and z axes and use BlockPos#add(int, int, int) to add the x and z offsets to the starting position Call BlockPos#getAllInBoxMutable with -2,0,-2 and +2,0,+2 as the arguments and iterate through the returned value

That's exactly what I was telling you how to do, though like I said it only works for JSON models.

HQM's data is corrupt. Delete its data from your save and restore it from a backup (if you have one).

You installed a coremod built for 1.7.10 or earlier on 1.10.2, this doesn't work. Always pay attention to which version of Minecraft your mods are built for, they'll usually only work in that version. An exception to this rule is that mods built for 1.9.4 will usually work in 1.10.2. To find out which mod it is, either look at your mods folder and find the one with "1.7.10" in its file name or post the FML log (logs/fml-client-latest.log in your game directory) in a spoiler (click the Sp button).

Look for usages of one in your IDE, then look for usages of the method you find. This will lead you to GuiIngameForge#renderGameOverlay , which calls the methods that fire RenderGameOverlayEvent .

If you're using a JSON model, you can specify the tint index of each face of each element in the model itself (see the wiki). This will allow that face's texture to be coloured at runtime. There's not currently any way to specify tint indexes in OBJ or B3D models (see this issue).

Look at RenderEntityItem to see how it renders items on the ground.

The installer generates a log file with the same name in the same folder as itself.

The forge:fluid model uses the textures you pass to the Fluid constructor, yes.

I think you mean builtin/generated or item/generated . builtin/generated is the base 2D-style model, item/generated extends this and defines the standard display transformations. Most basic item models extend item/generated . item/handheld extends item/generated and redefines the first/third-person display transformations to change how the item renders when held by an entity. Vanilla tool models extend this.

There are various tutorials linked here.

The model locations in blockstates files are relative to assets/<domain>/models/block, you don't have a model located at assets/morethingsmod/models/block/blocks/industrializedWood.json. Use morethingsmod:industrializedWood as the model location in your blockstates file. I have an explanation of the model loading process and how model locations are mapped to model files here.

GameRegistry.registerBlock registers an ItemBlock for you, unless you use an overload with a Class<? extends ItemBlock> argument and pass null . It's also deprecated, you should use GameRegistry.register instead. This registers any IForgeRegistryEntry implementation (including Block ) and doesn't automatically register an ItemBlock (you need to create and register this yourself).

RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) must be called in preInit. You should also use ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition in preInit to register your item models instead of using ItemModelMesher#register .