Jay Avery

I need to revisit this question. I can't use Minecraft.getMinecraft().world because it's client-side only. Where should I get a world object from in initCapabilities?

I have an ItemStack capability which makes an item decay over time, by storing the 'birth time' of the item to use for checks (discussed a bit more here). I'm struggling with syncing though, because ItemStack capabilities seem to be a nightmare. When an ItemStack of my decaying item is first created, the server and client both make their new capability with the current world time which matches up as expected. But when an ItemStack is split or changed in some way, the server keeps its information but the client makes a new capability with a new 'birth time' of the current world time. I'm assuming this is related to all the weirdness about how Forge sends vanilla packets when capabilities change but doesn't actually update the capability (unless my information is outdated, and this problem has been solved?). Anyway, my question is: where (when) should I sync my ItemStack capabilities from server to client, and how? They only need to sync when they're actually created - the 'birth time' of the stack is set when it's born and then never changes, so they don't need to be updated every tick or anything. But ItemStacks are created in so many different places, during copying, splitting, etc - I don't know how to make sure I am syncing at every possible time when it might be required. I thought about sending a packet in initCapabilities, but that method doesn't have any information about where the stack is located (inventory slot etc), so there's no way of knowing where it needs to be synced to. Can anyone advise?

As soon as the item is first created, either from a crafting recipe, furnace recipe, or drop from a block or entity. I'm saving information about the age to NBT, so it should persist through splitting etc - i.e. if a stack is split in two then both new stacks will have the same 'birth time' as the original stack did.

I want the timer to start as soon as the item starts to exist. With my previous method using a tick counter, starting it in initCapabilities has worked in the way I wanted it to.

Because initCapabilities is where I add the capability to my decaying items. Where else would I do it?

Follow-up question - where should I get the world from? The initCapabilities method only takes an ItemStack and NBTTagCompound as parameters. Should I just do Minecraft.getMinecraft().world?

Fair enough. I'll give this a try. I just realised I could maybe get away with keeping the ItemStack unchanged, but add a predicate to the model so that it uses a different texture when it's fully decayed (like with broken elytra). Thanks for the ideas.

I'm using the durability bar to represent the decay level when the item is in a GUI, so it will often be called every tick for rendering purposes anyway - will it still make a significant performance difference to use the total world time instead of a counter? Edit: also, I want the item to turn into a different item (representing rot) when it reaches the end of its shelf life. That can only be achieved using a tick update though, right? Otherwise the item won't turn into rot until its age is checked some other way.

I have food items which decay over time, so they have a tick counter that tracks their decay level.

I have some ItemStack capabilities that need to be updated every tick. Is there any way I can add tick updates to the vanilla chest, with events or capabilities or something? I'd like to avoid having to completely re-create chests just to add this one change.

You are returning super.getContainerItem, which is null.

Hmm, I see. It seems strange because mergeItemStack (as called by most transferStackInSlot implementations) has a loop in itself, and keeps trying until the stack is empty. Is it probably safe to override it to do nothing, as long as I'm aware of that? It seems that the worst possible outcome is that a stack might sometimes not fully merge when shift-clicked, if it needs to spread between multiple slots in order to transfer - unless I'm missing some other worse implication/s?

I just spent hours tracking down a weird bug in a custom Container and eventually realised it was to do with retrySlotClick. (I have a set of slots which automatically sort themselves when items are added or removed, and shift-clicking resulted in the whole set of slots being transferred if the items were the same, because retrySlotClick was called after the sorting). I've experimentally overridden retrySlotClick to do nothing, and it seems to have fixed the problem. So what is the point of that method in the first place? It seems to be only called in one place in vanilla and I don't really understand why. Except for an unusual modded case (like my self-sorting Container), when will a slot click fail the first time but succeed the second time? Doesn't the method just introduce a big risk of stack overflow if the slot click fails repeatedly?

You can simply call getActualState yourself - the getBoundingBox method comes with all the parameters you need.

Finally got it working! I had to use TextureStitchEvent.Pre to register the sprite, like so: @SubscribeEvent public void textureStich(TextureStitchEvent.Pre event) { event.getMap().registerSprite(new ResourceLocation("jjmod:gui/backpack_slot")); } And also set the background name to the same string in the Slot constructor: this.backgroundName = "jjmod:gui/backpack_slot";

I've already done that. The vanilla armour slots override Slot#getSlotTexture and return a string with the path to the texture. Doing that in my slots also resulted in the missing image texture. I've read through the Slot class but it seems to use a convoluted mixture of strings and ResourceLocations, and something to do with TextureAtlasSprites - I have no idea what those are.

I want to give some of my slots custom background icons (like the vanilla armour slots have). I tried setting the backgroundName or backgroundLocation in the constructor - when I do the first, it renders as the missing image texture, when I do the second it has the usual blank background. Am I missing something obvious?

You don't have a nested "textures" inside your "false" variant. It should be like this: "active": { "true": { "textures": { "front": "#active" } }, "false": { "textures": { "front": "#active" } } }

Thanks for the tips. I'm not planning for external modders, and I think it'll be easier for me to understand and organise by keeping everything together - so I think I'll settle on combining it all into one. Does more performant mean better performance or worse?

I'm working on a mod that's got a lot of different features. In the process of writing it, I've added several different Capabilities to the player, for storing different types of information and functionality. Now I'm trying to tidy up my code and wondering if it would be better to have just a single player Capability, to store all the various information I need. In quite a lot of cases, I need to use information from multiple Capabilities in the same place anyway, so keeping it all together seems more efficient. Is there any particular reason to prefer multiple simple Capabilities over fewer, larger Capabilities - or vice versa?

Post your whole Container class. From what you describe, you're probably using the wrong index numbers in the mergeItemStack calls. Try adding a println to the transferStackInSlot method and print the slot index (par2). Then when you test it, you can check whether the index for a particular slot is what you expect it to be.

Bump - can anyone help? My next idea is to just start randomly altering numbers in the GlStateManager and vertexbuffer methods to see what happens...

How do you update mappings?

It's a NullPointerException - something is null where it shouldn't be. The full crash report will give a class and line number, so go to that place in your code and look for the problem. If you need more help to find it, post the full console log and your whole Container class.

I've created a spear item which, when used, throws a custom arrow entity. I've set up a renderer which is basically copied from the vanilla arrow renderers, and it does nearly what I want. The only problem is that I've used a custom texture which is based on the format of the arrow texture but longer than the vanilla arrow (here is the image file). But when the entity renders, it cuts off the longer part and shortens it to the length of a vanilla arrow. Here is my render class, (all the code is on github): So, all I want to know is, where in the rendering code does it define the length of the rendered entity and the section of the image that it uses. I am completely confused by the way most rendering code works, and it's not documented well enough for me to figure it out by reading. Can anyone point me in the right direction?