Draco18s

I'll give that a shot. Eventually. (It's not a block I look forward to having to remake)

Doh, that would do it. The things one forgets when one hasn't had to deal with it in ages.

Yes, but that was provided as a reference to show the difference between the Cap<T> and the T.

Sorry, ContainerSifter. I should check the cart.....Cart works fine.

The block isn't actually a fluid. It just displays water running over it as if it was submerged.

Ok, I don't get it. I thought custom inventories were working Fine. Then today I ran into a problem, a problem that exists even using code as far back as 2 months ago before I started doing anything crazy. Why this infinite loop? at net.minecraft.inventory.Container.retrySlotClick(Container.java:549) at net.minecraft.inventory.Container.slotClick(Container.java:284) at net.minecraft.inventory.Container.retrySlotClick(Container.java:549) at net.minecraft.inventory.Container.slotClick(Container.java:284) Git: https://github.com/Draco18s/ReasonableRealism (relies on my 1.10 update of COG to run) Smaller, earlier commit (that does not need COG). This only happens on a custom inventory GUI, not with vanilla (obv.) and it appears via debugging that when you shift-click a slot it is attempting to move the stack from the slot it's in to the slot it's in (resulting in no change, so it tries again).

Don't use ModelMesher. Use ModelLoader.setCustomResourceLocation (during pre-init) Or better yet, make up a class like this one: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java Which will handle all the different ways you might wish to register a block or item.

This would be really nice. I was able to work around the issue in 1.7, as things generally accounted for it except in the TransferStack method, which everyone always supplied a copy-paste from the wiki because It Worked. Now though, I can't. Even the method above isn't sufficient to fix the issues I have trying to make a hopper with a slot stack limit of 16. One problem is that shift-clicking results in an infinite loop: at net.minecraft.inventory.Container.retrySlotClick(Container.java:549) at net.minecraft.inventory.Container.slotClick(Container.java:284) at net.minecraft.inventory.Container.retrySlotClick(Container.java:549) at net.minecraft.inventory.Container.slotClick(Container.java:284) "If I failed, retry with the same parameters, maybe it'll work then." Yeesh. The other is that hopper also doesn't respect is own inventory limits when pulling from other containers. It pulls the item, puts it into its inventory, then checks the stack against the size limits and deletes the extra. "Click, click" works properly (only 16 are put into the slot) as does hopper-push. But shift-clicking and hopper-pull is broken. :\

So in 1.7 I had this block: http://reasonable-realism.wikia.com/wiki/Early_Tech#Sluice http://vignette1.wikia.nocookie.net/reasonable-realism/images/f/f9/2014-11-28_16.38.28.png/revision/latest/scale-to-width-down/220?cb=20150204202209[/img] Even in 1.7 this was a bitch to accomplish, as I wanted the water stream to degrade from "full block" to "1/16th" over the course of 4 blocks (rather than 7) so I had to extract the water rendering code and adjust the values so that the four corners were where I wanted them. I literally have no idea how to make this work with the json model system and in fact cannot find the water/lava block models (assuming there even are any).

Take a look here: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L124-L126 ITEM_HANDLER_CAPABILITY isn't ItemStackHandler

Is this still what your code does? If so, you're not returning T there, you're returning Capability<T>. Cap<T> is like an Enum, it's like saying "PINK" when what you need to return is Blocks.wool (the thing that is pink).

Of course there's a cast involved. The method is a generic. It takes in a Capability<T> and returns T. So in the code there's a return (T) someCap line that sends the capability back to you. If the requested capability<T> doesn't return an object of Type T, then the cast fails.

Ah. In which case, yes, it seems like this was moved inappropriately. As for what you've done: I have no idea. Seems to me like that might be a vanilla bug.

Log file is useless because your issue is not a crash. Post code.

[forge dir]/run/screenshots You need a client proxy in order to register any rendering. Other than that, no you don't need a proxy. I set my registration up via proxies so I could have a one-function-call "do everything" in my main mod class.

Oh. You're trying to add another line of text to the screen that lets you pick a world to play (the "load a save" screen). The not-coremod way of doing this would be to create your own GUI screen and replace it when the vanilla one is invoked (there's events for that). This probably isn't the best way (COG does stuff in a way that's a holdover from when another person was maintaining it, all I did was make sure that it continued to work on 1.10--also that code only adds a button to the "create new world" screen rather than replacing the entire GUI).

Then my Sifter class will be perfect for an example. I has a custom input slot, a generic output slot, a GUI (the Caps method made that confusing), and so on. Take a look at .getCapability(...) too. And trust me, figuring all those things out wasn't easy and there aren't any tutorials (that are any good) yet.

Looks much better, but now your problem is that you're never calling proxy.preInit Things should work at this point, but the idea of the proxy having init/preint/postinit functions is silly. For one, it shouldn't need the init event directly, the only thing that matters is when the registration methods are invoked (which at this point is always pre-init. Sort of yes. There are things that you do during registration that affect missing textures. i.e. ModelMesher isn't preferred because it gets janky if done wrong, hence the recommendation to use ModelLoader Or the registration name being messed up/not matching. The reason I suggest the way I've set up my files is that it doesn't require that you do this in your client proxy: ModelLoader.setCustomModelResourceLocation(ModItems.item1, ...) ModelLoader.setCustomModelResourceLocation(ModItems.item2, ...) ModelLoader.setCustomModelResourceLocation(ModItems.item3, ...) ModelLoader.setCustomModelResourceLocation(ModItems.item4, ...) But rather ModelLoader.setCustomModel is invoked as part of the registration. Like this: item1 = new BlockHardIron(); EasyRegistry.registerItem(item1, "hardiron"); item2 = new BlockHardIron(); EasyRegistry.registerItem(item2, "hardiron"); It also means I don't need a .setRegistryName or .setUnlocalizedName in my item class. Which is very similar to how it was done in 1.7: item1 = new BlockHardIron(); GameRegistry.registerItem(item1, "hardiron"); item2 = new BlockHardIron(); GameRegistry.registerItem(item2, "hardiron"); The various registerItem and registerBlock methods I have all take different paths depending on what the "goal" is (item, item with variants, block (no item), block with item, block with custom ItemBlock...) but all make sure that everything that needs to happen gets done. I don't have to think about it and remember "oh yes, I need to loop through the variants and register an item model for each of these..." it's handled for me. .registerItemWithVariants(...)

There's already an IItemHandler cap. And you don't need to extend it at all. net.minecraftforge.items.ItemStackHandler https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L33 Mind, I did, in order to have "slots" that could only take certain items: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/item/SiftableItemsHandler.java But it's definitely not necessary.

What?

Also, you didn't include your ItemRenderRegister class, which may have been important.

That happens automatically when you create a GUI. Unless you're trying to do something else, in which case, what are you trying to do (no, don't tell me the code you plan on writing, describe the effect).

You register your items before your blocks, so the block field you pass to your item's constructor contains null.

Uh... That's exactly what Jeffy said. https://en.wikipedia.org/wiki/Cartesian_product

A custom furnace, especially a two-output one is not a simple mod for a new beginner.