Food that doesn't expire should stack automatically
w3ricardo opened this issue · 5 comments
If you set the option to have foods not expiring, then I think food items should stack no matter the time they were created.
Maybe when creating a food item, check if that option is 0. If it is, then give the items a fake creation time, or a fake expiration time, so that they can stack automatically.
Sorry to revisit this topic for so long, I am running a long-term TFC server, and we want to use the mechanism of TFC to form gameplay, such as daily tasks that require TFC food crops, such as "travel trade" through TFC agricultural products, which need to identify NBT At present, after opening the food not to rot, there is still a rot timer, which makes it impossible to stack, and it also makes it impossible to be recognized by vending machines and NPCs. This is disastrous for us, and I hope the developers can take this into account.
thanks!
Maybe we should have another option. In the default setting, everything works the way it is, and we can enable or disable the food expiring. In the "infinity duration" setting, all food is created with the same date in "infinity", and the expiring option will work the same but it won't make any difference.
There's two ways this can happen:
- The item itself is configured (via craft tweaker) to have an infinite expiry time.
- The config option is set to ignore all decay calculations.
We do already handle the case where if items rot, they will automatically stack (their creation date is set to Long.MIN_VALUE
). However, it's not as simple for the case of the config option, as that's not actually recorded anywhere in the item. For instance:
- If you toggle the config option on and off again, all items will retain their previous creation dates.
- This then begs another question: If you turn the config option on, create a piece of food, then turn the config option off again - what should happen? If we forcibly set the creation date, it will have infinite expiry even without the config option on.
- On the other side, if you have existing food, but turn the config option on, any existing food won't get modified - it will continue to expire (if we only apply a "convert on create" mechanism. So then we need additionally, the existing mechanism to make all foods have infinite decay times regardless of creation date.
Basically this gets really messy once you start to take into account switching the config option, and the effects of storing the data directly as a creation date modification, or as a global factor. I don't think there's a good way to actually execute this.
My opinion on this is: Only foods created while the config is on should have infinity expiration time (and also stack) while foods created prior to the config change should still rot. This infer the creation time being Long.MAX_VALUE
, which would make then stack.