Choonster

BlockWorkbench.InterfaceCraftingTable opens ContainerWorkbench , which overrides Container#canInteractWith to return false if the block at the specified position isn't a Crafting Table. This is called every tick in EntityPlayer#onUpdate , if it returns false the Container and GUIScreen are closed. You'll need to create your own Container that extends ContainerWorkbench and overrides Container#canInteractWith to return true if the player can interact with it (if there's no restrictions, just return true every time) and your own GuiScreen that extends GuiContainer , creates an instance of your Container class and renders like GuiCrafting . Use FML's IGuiHandler system to open your GUI.

This is what the Ore Dictionary is for, but Blaze Rods aren't registered with it by default. This means vanilla recipes and most mod recipes will just use Items.blaze_rod as an ingredient directly instead of using an ore name. You should add vanilla Blaze Rods and your synthetic Blaze Rods to the Ore Dictionary with the same ore name (e.g. rodBlaze , which is already used by various other mods and modpacks) and then use ore recipes ( ShapedOreRecipe / ShapelessOreRecipe ) in your mod. Use this ore name as an ingredient instead of using an Item instance. I have a 1.7.10 class here that can replace any existing recipes that use the specified ItemStack as an input or output with ore recipes that use the specified ore name as an input and a specified replacement ItemStack as the output.

That's an anonymous class that extends ModelBiped and overrides render . It's what TLHPoE was referring to in this post: If you mean the ModelBiped function, I overrode it so I could put the print in to check if it was rendering. I also called the super so that it would render the model if it did, which it didn't.

As of 1.8.8 MinecraftForge.EVENT_BUS and FMLCommonHandler.instance().bus() are references to the same event bus, so you were registering two handlers for each event.

Every version of Thaumcraft is closed-source.

Like diesieben07 said, read the EAQ. Search for "loading screen" on that page and it will tell you how to disable it.

That server log doesn't show any attempted connections, so the Minecraft server isn't even receiving connections from clients. Post the client log as well.

I'm trying to test the substitution alias system by replacing the minecraft:snow_layer block with a block that has an extra property and sends a chat message to the player when right clicked. You can see my code here. Unfortunately this doesn't seem to work. The F3 debug info doesn't display the value of the extra property and none of my replacement class's methods are being called (except Block#createBlockState , but that's called from the constructor). I added a blockstates JSON that uses the vanilla snow layer models and adds a pillar submodel in the centre, but the submodel isn't displayed in the world or in the inventory. If I uncomment the item alias, it creates a new item instead of replacing the vanilla item. The new item crashes with an ArrayIndexOutOfBoundsException when right clicked because it doesn't have an item ID. Has anyone managed to get this system working?

Yes, a Block and its ItemBlock have the same registry name. Since you're only dealing with items in inventories, you can just ignore the block registry completely and only deal with the item registry.

FMLControlledNamespacedRegistry<Block> blockRegistry = GameData.getBlockRegistry(); for (Block block : blockRegistry.typeSafeIterable()){ String name = blockRegistry.getNameForObject(block).toString(); }

Use GameData.getBlockRegistry and GameData.getItemRegistry to get the block and item registries. Use FMLControlledNamespacedRegistry#typeSafeIterable to get an Iterable that can be used in a for-each loop (a.k.a enhanced for loop). Use RegistryNamespaced#getNameForObject (inherited by FMLControlledNamespacedRegistry ) to get the registry name of an object. This may be a ResourceLocation or a String .

Minecraft assumes every block is an opaque cube by default, so it doesn't render faces that are covered. Override Block#isOpaqueCube to return false so Minecraft always renders the faces adjacent to your block.

Bump. Does anyone know how to do this?

The Render class is now generic: it has a type argument T extends Entity (i.e. the type of entity that it renders). Render#getEntityTexture now takes an argument of type T . You could figure this out for yourself if you looked at the source code using your IDE.

I just wrote my own implementation of this (which you can see here) and it works without issue.

You're trying to use a coremod built for 1.8+ on a 1.7.10 client, this won't work.

Your paste is private, we can't read it. Use an image hosting site like Imgur to host screenshots and post links here. I don't think screenshots are necessary for this problem, though.

Entity#worldObj contains the entity's World ( EntityPlayer is a subclass of Entity ). On the server side, this is an instance of WorldServer .

Item#onUpdate is called every tick for each ItemStack of the Item in a player's inventory. If your inventory is tied to a player/mob rather than an item, you may want to use tick events as diesieben07 suggested. IUpdatePlayerListBox can be implemented by a TileEntity to receive an update every tick. You can also register other implementations of the interface to be updated by the server with MinecraftServer#registerTickable .

Forge and Forge mods only run on specific versions of Minecraft. Forge is available for Minecraft 1.8 and 1.8.8 (as well as earlier versions), but Not Enough Items is only available for 1.8 (as well as earlier versions). You can select the Minecraft version to download Forge for on Forge's download page. Most Forge mods include the Minecraft version they're designed for in their version numbers or on their download pages.

You can store more than 16 combinations of property values if you store values in a TileEntity and override Block#getActualState to return the values from the TileEntity , but this is mainly useful if the block's model depends on data in the TileEntity . You can't use World#setBlockState to set the values of properties that aren't stored in the metadata. In this case, you should just store the heat value in a TileEntity and forget about the blockstate.

Commit 097c0c6 recently added the ability to use a single blockstates JSON for multiple item models, so I thought I'd try and convert my custom bow's models (identical to the vanilla bow's models) into a blockstates JSON. You can see the result here. The model changes as the bow is used like before, but I'm having trouble getting it rotated and scaled properly with the transformation format used by the Forge blockstates format. I tried to convert the vanilla item model transformations to the Forge format using the following code, but it doesn't display like the vanilla model. TRSRTransformation thirdPerson = TRSRTransformation.blockCornerToCenter(new TRSRTransformation(new ItemTransformVec3f(new Vector3f(5, -100, -45), new Vector3f(0.75f, 0, 0.25f), new Vector3f(1, 1, 1)))); TRSRTransformation firstPerson = TRSRTransformation.blockCornerToCenter(new TRSRTransformation(new ItemTransformVec3f(new Vector3f(0, -135, 25), new Vector3f(0, 4, 2), new Vector3f(1.7f, 1.7f, 1.7f)))); This is the "transform" block I ended up with: "transform": { "thirdperson": { "rotation": [ -0.31877723, 0.6963295, 0.21487917, -0.60608023 ], "translation": [ 0.75, 0, 0.25 ], "scale": [ 1, 1, 1 ], "post-rotation": [ 0, 0, 0, 1 ] }, "firstperson": { "rotation": [ 0.19996417, 0.9019799, -0.08282786, -0.37361234 ], "translation": [ 0, 4, 2 ], "scale": [ 1.7, 1.7, 1.7 ], "post-rotation": [ 0, 0, 0, 1 ] } } This is what it looks like with no transformations. This is what it looks like with transformations. How do I properly convert the vanilla transformation format to the Forge format?

You're adding recipes before you instantiate/register your items/blocks. Items/blocks should be instantiated and registered in preInit ( FMLPreInitializationEvent ) and recipes should be added in init ( FMLInitializationEvent ). Models/renderers should only be registered from the client proxy, otherwise you'll crash the dedicated server (the Minecraft class is client-only).

On the client side, Minecraft#thePlayer contains the client player. On the server side, MessageContext#getServerHandler returns the sending player's NetHandlerPlayServer and NetHandlerPlayServer#playerEntity contains the player.

You installed a client-only mod (Resource Loader) on the server.