Making an item which is both stackable and damageable

[Jay Avery]

I want to make food items which can spoil over time while in a stack. It seems logical to use the vanilla item damage/durability for the spoilage, but damaged items can't be stacked. My first instinct would be to make a subclass of ItemStack and implement my own functionality for combining damage and stack sizes, but since ItemStack is final I can't do that. Does anyone have any ideas for how I could achieve something like this? Or will it be painfully difficult/unachieveable?

 

Edit: update in post #5

[Draco18s]

A couple things:

 

1) any item stored in a chest (or other non-entityliving inventory) will not tick and thus not rot.

2) any item in an unloaded chunk (or in a player that is not connected to the server's inventory) will not tick and thus not rot.

3) how do you plan to handle combining a stack of "damage:1" meat with "damage:10" meat?

[Jay Avery]

1) I'm planning to create custom chest TileEntities, so I will be able to add ticking for that anyway.

2) I understand that, and I'll either introduce workarounds (instant rot when a chunk becomes re-loaded, perhaps) or just let it go.

3) Some sort of averaging process - something like how spoilage levels are combined in the game Don't Starve.

 

I know it's a big job and I might end up dropping it, but I'd like to give it a try if I can.

[TheGreyGhost]

Hi

 

I think it shouldn't be too difficult.  Just add a few custom methods to your Item class (not the ItemStack) and Item renderer to implement the effects of rotting.  For example, instead of using the ItemStack durability bar to indicate rotting, draw a durability bar yourself when rendering the item; or alternatively change the item's appearance another way (eg its colour or a degraded texture).

 

You can work around the ticking problem by storing a timestamp in the Item NBT (or perhaps - as a Capability).

I.e. you have a master clock for the world, when an item is created, you copy the value of your master clock as "creation time".  Later, whenever you render the item or do something with it, check the clock against the saved "creation time" and calculate the amount of rotting.

 

-TGG

[Jay Avery]

Since I posted, I've found a way to hijack the vanilla durability rendering without needing to use actual item durability - and made a capability to handle my decay process. The problem I'm stuck with now is how to enable combining stacks of the same item that have different levels of decay - I'd really like to be able to make that possible by some kind of averaging process. But the ability to combine stacks seems to mostly rely on

ItemStack.areItemStackTagsEqual

which checks the capabilities. So if I'm storing my decay capability then vanilla will automatically prevent stacks with different decay levels from being combined.

 

I could override all the various stack-combining methods in my inventory containers (I've already got custom containers anyway so that's easily possible), to manually check whether stacks can combine, and then update the stack capability accordingly, but that would be a lot of hassle and probably not totally reliable.

 

Another option is to somehow cheat the NBT check by making my own subclass of

NBTTagCompound

to override the

equals

method and prevent it from checking the values which I want to be irrelevant. But I'm pretty sure that overriding an

equals

method so that it tells an outright lie about whether two objects are equal is some kind of cardinal sin and will probably cause all kinds of problems I haven't thought of.

 

And even if I use one of those workarounds to make sure combining stacks is allowed, I still have the problem of how and where I combine the information from their capabilities to make the new one. It looks like

gatherCapabilities

in the

ForgeEventFactory

is the method that takes the capabilities of two stacks and combines them into one set. But that method uses the

CapabilityDispatcher

constructor which seems to always add the capabilities separately and doesn't have any ability to combine them in some other way.

 

Maybe the ability to combine differently-decayed stacks is just a lost cause. It's still pretty good that I've got damageable stacks at all, so perhaps I should just let it go. If anyone else has any ideas or suggestions though, please tell me!

[Animefan8888]

  On 11/18/2016 at 3:00 PM, Jazzable said:

Since I posted, I've found a way to hijack the vanilla durability rendering without needing to use actual item durability - and made a capability to handle my decay process. The problem I'm stuck with now is how to enable combining stacks of the same item that have different levels of decay - I'd really like to be able to make that possible by some kind of averaging process. But the ability to combine stacks seems to mostly rely on

ItemStack.areItemStackTagsEqual

which checks the capabilities. So if I'm storing my decay capability then vanilla will automatically prevent stacks with different decay levels from being combined.

 

I could override all the various stack-combining methods in my inventory containers (I've already got custom containers anyway so that's easily possible), to manually check whether stacks can combine, and then update the stack capability accordingly, but that would be a lot of hassle and probably not totally reliable.

 

Another option is to somehow cheat the NBT check by making my own subclass of

NBTTagCompound

to override the

equals

method and prevent it from checking the values which I want to be irrelevant. But I'm pretty sure that overriding an

equals

method so that it tells an outright lie about whether two objects are equal is some kind of cardinal sin and will probably cause all kinds of problems I haven't thought of.

 

And even if I use one of those workarounds to make sure combining stacks is allowed, I still have the problem of how and where I combine the information from their capabilities to make the new one. It looks like

gatherCapabilities

in the

ForgeEventFactory

is the method that takes the capabilities of two stacks and combines them into one set. But that method uses the

CapabilityDispatcher

constructor which seems to always add the capabilities separately and doesn't have any ability to combine them in some other way.

 

Maybe the ability to combine differently-decayed stacks is just a lost cause. It's still pretty good that I've got damageable stacks at all, so perhaps I should just let it go. If anyone else has any ideas or suggestions though, please tell me!

You could put in a PR for slot click? Then when a slot is clicked handle averaging.

[Jay Avery]

PR?

[Animefan8888]

  On 11/18/2016 at 3:08 PM, Jazzable said:

PR?

Pull Request

[Guest]

Little warning: You cannot by any means extend the ItemStack class as it is final!

[Jay Avery]

  On 11/18/2016 at 3:08 PM, Animefan8888 said:

  Quote

PR?

Pull Request

 

I don't understand what you mean by pull request here, isn't that a github thing?

[Animefan8888]

  On 11/18/2016 at 3:11 PM, Jazzable said:

  Quote

  Quote

PR?

Pull Request

 

I don't understand what you mean by pull request here, isn't that a github thing?

Forge uses github and accepts pull requests, when they deem them useful.

[Jay Avery]

  On 11/18/2016 at 3:10 PM, XFactHD said:

Little warning: You cannot by any means extend the ItemStack class as it is final!

 

Yes, I acknowledged this in my original post!

 

  Quote

I want to make food items which can spoil over time while in a stack. It seems logical to use the vanilla item damage/durability for the spoilage, but damaged items can't be stacked. My first instinct would be to make a subclass of ItemStack and implement my own functionality for combining damage and stack sizes, but since ItemStack is final I can't do that. Does anyone have any ideas for how I could achieve something like this? Or will it be painfully difficult/unachieveable?

[Jay Avery]

  On 11/18/2016 at 3:12 PM, Animefan8888 said:

  Quote

I don't understand what you mean by pull request here, isn't that a github thing?

Forge uses github and accepts pull requests, when they deem them useful.

 

Ohh, so you mean suggest a change to Forge that would make it easier for me to do this?

[Animefan8888]

  On 11/18/2016 at 3:14 PM, Jazzable said:

  Quote

  Quote

I don't understand what you mean by pull request here, isn't that a github thing?

Forge uses github and accepts pull requests, when they deem them useful.

 

Ohh, so you mean suggest a change to Forge that would make it easier for me to do this?

Not a change an addition, you will suggest the event OnSlotClickEvent or some name similar.

[jeffryfisher]

Or you could reduce the number of stages of rot to the point that you don't mind having separate stacks. For instance, have only fresh and tainted before something turns completely into rotting flesh or its vegetable equivalent (dirt?).

 

Along the way, decide if/what will be durable for long journeys, and whether an enchantment (e.g. refrigeration) on a chest (or new device) might stop the rot.

 

And after all that, figure out if the game would still be playable. What if you go on vacation for two weeks while your baked chicken sits in a multiplayer world. Will your character starve to death the next time he logs in?

[Jay Avery]

This is actually the decision I've come to! I'm going to have only three stages of spoiling, so that stacks can be combined if they're in the same stage but not if they're in different stages. As for the rate of spoiling, that'll need plenty of testing to get it calibrated right, but the aim of my mod is a harder survival game anyway.