Jay Avery

You are calling a method which requires a ResourceLocation as the second parameter, and passing it a String as the second parameter. Do you understand why this is invalid Java? You shouldn't use all the getUnlocalizedName().substring stuff. Instead use getRegistryName, which returns a ResourceLocation in the correct format for registration. In fact, if you've already set the registry name of your object, you don't need to pass a name parameter because it will be used automatically in the one-parameter register method (the one you are already using for some of your items).

Oh I see! I'd try looking at how the normal model loading system reads blockstates files, and see if you can use or copy some of the code from there.

What do you mean by the default model path for a blockstate? For a normally-rendered block you'd have to write a blockstates file telling it which model(s) to render depending on the state - in this case you're just doing the same thing in Java instead of json. Or did I misunderstand your question?

The easiest way is using the forge blockstates format.

Yes it is! Take a look at the forge blockstate docs. What is EntityWorkbench? You should return your Container in this method. This is the vanilla method which doesn't refer to your GuiHandler at all. You need to use player#openGui(Object modInstance, int guiID, World world, int x, int y, int z). That will call the appropriate-side methods from your GUI handler to get the correct container/GUI.

Post the code you tried and the crash(es) that resulted. It can't really be done in a much easier way. The standard vanilla system bakes all models at start-up, so if you want to do something other than that, you need to alter the model loading and baking steps yourself. But that said, it really isn't as complicated as it might seem. For a simple system (i.e. one that would be simple enough to render using ordinary JSON blockstates), you can do it all within one object which implements ICustomModelLoader, IModel, and IBakedModel: Register your object with ModelLoaderRegistry.registerLoader. accepts should check for your block (probably by checking that the ResourceLocation path contains your block's registry name). loadModel should load all the models you will need from ModelLoaderRegistry.getModel (or one of the variant methods like getModelOrLogError) by passing the ResourceLocations of the json files, and store those in fields to use later. Then it can return itself. bake should do nothing except store the parameters as fields to use later, and return itself. getQuads should do the actual baking as needed. From the IBlockState parameter, decide which model(s) are needed for the block. Use your previously-stored IModel fields, call bake (using your previously-stored parameters) and then getQuads and return the result. You should also have a cache to store models which have already been created. In simple cases it can just be a Map<IBlockState, List<BakedQuad>>. The first step in your getQuads should be to check whether the state has a cached result (and return it if so), and the last step should be to add the result to the cache if it's not already present. For simple cases, a lot of this can be done automatically and the same for every case (rather than needing to write it individually for every block). I have an abstract class which I use for all the stuff that's the same every time here. Then I only have to write loadModel and getQuads individually, which is not really any more complicated than writing a big messy blockstates file.

If you want it to be an event handler method, you can't have multiple arguments. If you need a World object for your code, get it via the event itself.

1.7.10 is no longer supported on this forum, your thread will probably be closed by a mod. That said, the error tells you the problem: You have two arguments in your event handler method, which is an invalid use of @SubscribeEvent. Event handler methods must have just one argument, the Event type.

SlotCrafting#onTake is hardcoded to call getRemainingItems from the vanilla CraftingManager. To use your custom crafting manager, you'll need to make your own crafting slot implementation (it can be mostly the same as vanilla).

What kind of trouble?

Looks like you want BabyEntitySpawnEvent.

No, the block and item rendering is separate, so the ItemBlock problem shouldn't interfere with the placed block. What did your blockstates file look like when you used only textures and said it worked?

By default an ItemBlock (that's the item that places the block, the thing you have in your inventory) looks for either an "inventory" variant in the blockstates file, or a model file in the item folder.

What does your blockstates file look like in this case?

Thanks, that works!

I'm using a cached model system which involves storing a map of IExtendedBlockState keys. But I've realised the map isn't functioning properly, possibly because IUnlistedPropertys are ignored in hashCode()? Or something to do with the way equality is checked. The problem seems to be, the map thinks a key isn't present even when it's a state that has just been added. I just tried manually turning the state into a string which lists the states and values, and that works, but it's hardly elegant. Is there a better solution for using IExtendedBlockState as a map key?

LivingDropsEvent is for living entities that die and drop items (e.g. animals and monsters). For blocks, you can use HarvestDropsEvent. Check for your chosen block, then edit the list of drops however you want.

The vanilla code is your best friend, especially when you already know there's something in vanilla that does exactly what you want. In this case, it's the method getStateForPlacement.

WARNING: coremods are present: EnderCorePlugin (EnderCore-1.10.2-0.4.1.65-beta.jar) IC2core (industrialcraft-2-2.6.142-ex110.jar) Contact their authors BEFORE contacting forge You won't get support for this issue here, it's a problem with a coremod (the crash report also explicitly shows that the error happens in ic2 code).

Post the latest console log, it should give the error.

I've just finished putting together a model caching system (my previous thread is here). I went through the process of making an ICustomModelLoader whose load method returns a new IModel, whose bake method in turn returns a new IBakedModel. But could I implement all these interfaces in one class? The different stages of loading, baking, and caching can be done in the appropriate methods without needing to have everything spread over multiple classes. Is there any reason I shouldn't do this?

Your thread will be locked as soon as a moderator sees it.

Thanks for all the help. I now have a working delayed-baking system! (I just pushed my latest changes here). The model baking bar has dropped from 110,000+ to about 4,000 models, and only takes about 1.5G RAM at the most. And I'm not noticing any performance issues in the game when I place the blocks in question, but all the models are looking as they should. If anyone has feedback on the approach I've taken, please do tell. I've never done anything so complicated with block models before. But it all seems to be working so I'm pretty pleased.

So what exactly tells you that the cool down is not being set to 100?

So look at the code for the vanilla bucket (net.minecraft.item.ItemBucket) to see how it achieves what you want.