[1.7.10] Tracking ItemStacks

[weckar]

So, here's the thing. I have a list of ItemStacks. I need to somehow figure out for every one of these whether it is

a) Currently stored in an EntityItem

b) In the inventory of an Entity

c) In the inventory of a TileEntity

 

I don't need to know which, I just need to basically know whether the ItemStack still has a physical representation SOMEWHERE in the world.

Luckily, I have already managed to limit the ways this representation could be removed from the world, as it is immune to fire, despawning, damage, the void and explosions. The only things that could still destroy it that I am aware of are Creative Mode stuff, crafting, and certain mods that hard-remove items from inventories. So having an event trigger for any of these would work for me as well....

 

Thus far, I've had little luck finding any existing mechanics that track ItemStacks or that hard-delete them, because it seems minecraft is happy to just let them sit there unmanaged and unedited until the garbage collector gets to them. Unfortunately, because I do have them listed that will never happen. So, I need to know when it is safe to de-list them - hence the above question.

[Cerandior]

This is not possible in the way you described. Why do you need this? What are you trying to achieve?

 

That's a good question. Why would you need an item that is immune to everything that minecraft has.

[Ernio]

Probably on-per-game legendary item or something.

 

Anyway - not really possible without tons of specific tracking which can obviously fail at some point.

 

Let's say that you store some world-or-server-global boolean somewhere on server thread.

Call it "B".

 

1. I don't think EntityItem fires any events in per-existance manner (onUpdate), BUT!

* You can easily extend EntityItem with your custom one and override its update methods that could set "B". Then in your Item class to spawn custom EntityItem you use:

- Item#hasCustomEntity(ItemStack stack)

- Item#Entity createEntity(World world, Entity location, ItemStack itemstack)

So now you have Your check for EntityItem.

 

2. Well, Forge events only allow tracking updates (onUpdate) of living entities. Happily - I don't think that there is a non-living entity that can have inventory. So you use:

- LivingUpdateEvent, check for entity, check if it has inventory and loop through items, if item was found - you set "B".

So now you have entities (that can include players).

 

3. But wait - what about non-livng entities with inventory - sadly, I don't think there is a way. Only thing you could track are Minecarts, but if other mods have e.g backpacks - forget about it.

 

4. TileEntity - welp, again hard one, not every TE has onUpdate() method (since it is in interface).

 

Other approach would be not tracking existance but only creation and destruction. Which again - is not really possible for all cases (creative-destruction or command spawn).

 

Verdict: It is quite impossible to catch all cases, I'd forget about it.

[weckar]

Hitting the nail on the head there, Ernio. In the end, I am accepting of the fact that I can't catch ALL cases of destruction and prevent them, but I would like to achieve a way in which even if they are destroyed somehow I can free up their 'slot' in the world again.

For the record, though: an Item's onUpdate will only happen if it is in the inventory of a living Entity, yes? No way to get a similar thing to happen if it is in a chest or the like? Because if I could I could have it send regular information pulses to a central controller who would assume a cease of existance if it has missed 3 pulses in a row or something... Although that does carry the problem with it of chunks unloading...

[Ernio]

I actually tried doing similar thing few times in the past. I can honestly tell that there is no good way of making what you need - and I used probably all my knowledge about Forge/Vanilla. The only thing I didn't try (because it is kinda ridiculus and even harder to track) is java-based object tracking.

 

Theoretically you could do this with ASM (would need few insertions to ItemStack.class) and some "bad" coding (I am talking about using finalize() method - which is always bad to use to modify any data).

 

I must say - when you think about it - you could actually make sure that game has only ever one instance of ItemStack.class with given specific data. Any other creation would be simply auto-removed. This + one boolean could work (boolean would be set to true if given "specific" stack would be saved to disk (which can be detected, easily with events), so then you can use it to know it there is this itemstack in HDD when it's not in JVM). I could explain more of this mess, and i honestly belive it would work, but 1st you would need to learn ASM.

 

Disclaimer: This is totally out-of-box thinking. And it's probably bad in long run.

[Draco18s]

an Item's onUpdate will only happen if it is in the inventory of a living Entity, yes? No way to get a similar thing to happen if it is in a chest or the like?

 

Correct, only when its in the inventory of a living entity (may even only be the player).  There's also onEntityItemUpdate which is what the item is when it is dropped into the world.

 

Containers do not call onUpdate for their contents and there's no real way to make them do so.

 

As a completely impossible form of item destruction that cannot be detected:

Item in a chest in a Mystcraft age when the age is destroyed (future mechanic).

[weckar]

I must say - when you think about it - you could actually make sure that game has only ever one instance of ItemStack.class with given specific data. Any other creation would be simply auto-removed.

I see what you're saying, but I am already capable of removing duplicate items from the world, and am also canceling the crafting of any possible duplicates. The real problem comes in, as mentioned, when they get somehow destroyed anyway - at which point I want to make it possible to obtain a new one.

 

But the point has been made abundantly clear that such cannot be done. It's a pity. Thank you all anyway.