Daeruin

I am currently using capabilities to store a simple thirst value for the player. I would like to start storing more data, like a set of booleans, for the player. I'm not sure how to go about it. All of the examples of capabilities I've seen only store a single value, like a single float or boolean. Can I use the same capability (interface, implementation, storage, provider) to store multiple values? How? I've been searching for a while now, but haven't come up with anything.

It's now working correctly. In my registerItemModel method in the block class, I was only registering an item model for one of the variants. So I looped through each of the variants in my enum and registered an item model for each one, and it finally worked as expected. Problem method: @Override public void registerItemModel(Item item) { Primalcraft.proxy.registerItemRenderer(item, 0, blockName); } Fixed method: @Override public void registerItemModel(Item item) { for (PrimalBlockLog.EnumAxis axis : EnumAxis.values()) { Primalcraft.proxy.registerItemRenderer(item, axis.getMeta(), blockName); } } To be honest, I'm still not sure why this fixed the problem. I was only registering an item model for one variant before, because I only need one variant for the item version of my block.

Where should I even look to try to debug this problem with missing textures when the block is broken? One variant is fine, the other two are not. I suspected that perhaps damageDropped was getting the wrong meta somehow, but it seems to be fine. Any ideas?

Oh. Embarrassingly copied from another class (an old attempt at custom logs) without realizing. Thanks for the reminder. Second problem is the textures. The two untextured variants I saw in the creative inventory are following me around in the world. Everything is fine until I break the blocks. Those on the X axis are fine, but those on the Y and Z axis drop with no texture. As soon as I pick them up, they are fine.

Why is it that when I register the item for my block, I get three copies of it in the creative inventory? My block has three variants for different orientations (like a log). It seems like it's registering an item for each variant. Only one has the right texture in inventory. The other two are untextured cubes. public final class PrimalBlockRegistry { public static Block logStrippedOak = new PrimalBlockLog("log_stripped_oak"); public static void createBlocks() { register(logStrippedOak); } private static <T extends Block> T register(T block) { GameRegistry.register(block); ItemBlock itemBlock = new ItemBlock(block); itemBlock.setRegistryName(block.getRegistryName()); if (itemBlock != null) { GameRegistry.register(itemBlock); } return block; } My block class:

Nice job figuring it out, and thanks for posting the solution. I wish more people would do that. It's very helpful to the community.

I think there are those who would argue with you. One advantage of Minecraft's implementation is that it limits the number of blocks you have to register, and that helps with large modpacks. If rewriting my log classes is what it takes, I may just have to go that direction. Sigh.

Anyone? I've been wrestling this for hours. Apparently I don't understand what Forge wants from me. When I print the unlocalized name to the console as I register each item model, it appears correct as, for example, "primalcraft:log_oak_stripped". But when I run the game, it appears as "primalcraft:log_stripped_old". And there's all these extra untextured items with the same name in the creative inventory. Here's a screen shot of what it looks like. http://screencast.com/t/Q0QFvdqa

Make your own post and include the code for your block, block state, model, etc.

Not sure if it matters, but in my item json files, it's lowercase "layer0", not "Layer0". Also make sure you have a file named "gooseberry.png" in src/main/resources/assets/[modid]/textures/items and that it actually has colored pixels somewhere in it.

I have created some custom logs (in my mod, you can harvest bark from logs, leaving a stripped log). I'm updated to 1.10.2 and trying to register the item models for the log variants. I know I'm doing something wrong, but can't figure out what it is. I have two log classes that mimic the old and new log classes from vanilla, and I have my own enum that specifies the log types. I need to register both log blocks, and all the variants for the items. Here's what I have so far. My block registry: public final class PrimalBlockRegistry { public static Block logStrippedOld = new PrimalBlockStrippedLogOld("log_stripped_old"); public static Block logStrippedNew = new PrimalBlockStrippedLogNew("log_stripped_new"); } public static void createBlocks() { registerBlockLogs(logStrippedOld, logStrippedNew); } private static void registerBlockLogs(Block block1, Block block2) { GameRegistry.register(block1); GameRegistry.register(block2); for (EnumWoodType woodType : EnumWoodType.values()) { // System.out.println("woodType: " + itemBlock); if (woodType.getMetadata() <= 3) { ItemBlock itemBlock = new ItemBlock(block1); itemBlock.setRegistryName(woodType.getName()); GameRegistry.register(itemBlock); ModelLoader.setCustomModelResourceLocation(itemBlock, woodType.getMetadata(), new ModelResourceLocation(block1.getRegistryName(), "axis=y,variant=" + woodType.getName())); } if (woodType.getMetadata() >= 4) { ItemBlock itemBlock2 = new ItemBlock(block2); itemBlock2.setRegistryName(woodType.getName()); GameRegistry.register(itemBlock2); ModelLoader.setCustomModelResourceLocation(itemBlock2, woodType.getMetadata(), new ModelResourceLocation(block2.getRegistryName(), "axis=y,variant=" + woodType.getName())); } } } The problem is I'm seeing only the four old log variants in my creative inventory, plus about 20 additional untextured items, and they are all named "tile.primalcraft:log_stripped_old:name" or "tile.primalcraft:log_stripped_new:name", and they all use the default texture (oak for old logs, acacia for new logs). My wood type enum: My old log block class: My blockstate json for the old log (the new log is essentially the same, but for dark oak and acacia): Each type of wood has three block models (for the three axes) and one item model. Examples: Block model log_oak_stripped: Block model log_oak_stripped_bare: Block model log_oak_stripped_side: Item model for oak:

To get it to work even while holding something in the left hand, I had to use PlayerInteractEvent. It seems to be working smoothly now. In PlayerInteract, I check if the player is sneaking and if the target is an instance of my container. Then I do event.setUseBlock(Result.ALLOW) which calls onBlockActivated.

After a bit more research, I found this page: https://gist.github.com/williewillus/c781d9824df3ae723bff ...which explains that onBlockActivated is indeed called when sneaking, but only if both hands are empty. That's why it was working for me before, and it actually still works that way now.

The idea is that it's a small block that the player should just be able to "pick up" whenever they want, without "breaking" it. But I also want them to be able to break it, if they really want to destroy the block. It was definitely working before, but I remember now that I had to tweak some of the other methods as well. I wonder what changed. I guess I'll try PlayerIntractEvent.

In 1.8.9, I had a container that, when shift-right-clicked, would drop the item version of the block as if it had been broken and save the inventory. I achieved this by using the onBlockActivated method. In 1.10.2, this no longer works, as it seems onBlockActivated is no longer called when shift-right-clicking the block. What changed? How can I get this to behave like it used to? Here's my onBlockActivated method, if it matters:

So in my update to 1.10.2 I finally have my items rendering, but I have run into a question that I want to understand better. The first version of my mod was for 1.8.9. I had a class for registering my item renderers which was called from my ClientProxy's pre-init method. I had understood that item renderers are only used on the client side. My items themselves were registered from CommonProxy. Now, after following some recommendations for updating to 1.10.2, I have a single method that's called from CommonProxy, and it both registers the items and the item renderers. It's definitely simpler this way. What is the difference between registering the item renderers from CommonProxy versus ClientProxy? Would it be somehow better to separate out the item renderers and call them from ClientProxy, like I used to do?

Thank you! That did it. I knew it would be something simple. Now it's crashing for a different reason. Something to do with block rendering. But I'll post on that later if I can't figure it out.

I wondered about that. I didn't see any examples with a constructor. Without it, how would I get access to the player in order to send my packets? I need to notify the client when the player's thirst changes, in order to update the GUI.

I am trying to update my mod from 1.8.9 to 1.10.2. I was using IExtendedEntityProperty to give players a thirst property. I'm trying to implement this functionality using Capabilities, but I can't get it to work. I am getting an InstantiationException when my mod tries to attach the capability to the player upon login. My interface class: My implementation class: My provider class: My storage class: My handler class: Edited to add my CommonProxy class where I register stuff: The error: http://pastebin.com/64bfYYkd

I got it to work after a couple hours. It wasn't "GC overhead limit exceeded." I finally fixed it by replacing my entire gradle properties file with a fresh copy from a new download of Forge. So now begins the laborious process of updating all my code. In the meantime, I still need an answer to the original question. I can't figure out why onUsingTick is never called.

Can't get gradle setupdecompworkspace to work. It keeps failing on recompileMc. This crap is why I hadn't tried updating yet. I have precious little free time for this little modding hobby as it is.

Will do. I still have this problem either way, so additional comments are welcome.

I'm trying to create an item where if the player holds right-click on a specific block for a certain amount of time, the block spawns an item. After some searching, I figured I could use onUsingTick to achieve this. However, onUsingTick never gets called. I have a PlayerInteractEvent set up that does get called every time I right click. Is it perhaps interrupting or preventing onUsingTick? Or am I doing something else wrong? @Override public void onUsingTick(ItemStack stack, EntityPlayer player, int tick) { System.out.println("onUsingTick started!"); MovingObjectPosition mop = this.getMovingObjectPositionFromPlayer(player.worldObj, player, true); if (mop != null && mop.typeOfHit == MovingObjectType.BLOCK) { World world = player.worldObj; BlockPos pos = mop.getBlockPos(); if (world.getBlockState(pos) != null) { if (!world.isRemote && tick ==1) { System.out.println("onUsingTick successful!"); } } } } @Override public ItemStack onItemRightClick(ItemStack itemStack, World world, EntityPlayer player) { System.out.println("onItemRightClick started!"); player.setItemInUse(itemStack, this.getMaxItemUseDuration(itemStack)); return itemStack; } @Override public int getMaxItemUseDuration(ItemStack itemStack) { return 20; }

I see. So if I used a setter, when and where would I invoke it?

That's actually the first thing I tried. I assumed I could add a new field to my tile entity and pass the parameter into the constructor when returning a new tile entity in createNewTileEntity (in my container's block class). Why can't the constructor have any parameters? If I used a setter, when and where would I invoke it?