[1.7.10] Adding items randomly to existing chest

[theCorvid]

I'm creating a mod which adds chests that replenish themselves with items over time, and I would like to know how to go about doing this. I have already figured out what I'm doing as far as actually deciding when they should replenish, but I'm struggling to work out how to actually add the items to the chest at a given coordinate.

 

To clarify, I don't want to generate a new chest with items in it, I want to add items to an existing chest. I'm aware that what I could probably do is add loot to a custom chest and then have the game remove it and re-add it to refresh it, but I'd rather not lose the items that were still remaining in the chest. Any ideas?

[Ernio]

I don't have any experience in actually using 1.8 TE, but question: (everything I know is from 1.6.4 or reading from code straight):

There is IUpdatePlayerListBox with update()

 

Why is there no event (or is there?) in TE updating?

In World class:

Iterator iterator = this.tickableTileEntities.iterator();

        while (iterator.hasNext())
        {
            TileEntity tileentity = (TileEntity)iterator.next();

            if (!tileentity.isInvalid() && tileentity.hasWorldObj())
            {
                BlockPos blockpos = tileentity.getPos();

                if (this.isBlockLoaded(blockpos) && this.worldBorder.contains(blockpos))
                {
                    try
                    {
                        ((IUpdatePlayerListBox)tileentity).update();

 

Yes, we can use WorldTickEvent and re-iterate list again, but isn't that pointless? Unless calling forge event would be less efficient than re-looping ofc.

EDIT: To clarify - is there TileEntityUpdateEvent?

 

------------------

 

As to thread - above kinda answers what you should be looking at.

World has tickableTileEntities, you can get chests from there and operate on their IInventories (using WorldTickEvent).

 

EDIT 2:

Welp, you are on 1.7.10 - namings might be different, but idea is still the same.

 

EDIT 3: (dammit)

When using TickEvents you have 2 phases, START and END - pick one, otherwise your code will run twice.

[theCorvid]

Ah, I hadn't thought of it that way - sorry, I'm still very new to this.

 

Okay, so I stared at the code for a while and tried to figure out how to implement this with my own code, but I failed; I'm fully aware that the reason for this is that I've been impatient and haven't become familiar enough with Java before leaping into this, so obviously everyone reserves the right to refuse to help me further, but if there's anyone who is willing to be more patient with me, I'd really appreciate it:

 

The context for this chest is that it's a chest inside a vault-like structure, which, when closed for long enough, replenishes its stores. I have a (currently blank) RefreshContents() method which accepts a String that tells it what kind of loot to refresh the chest with. (This is a Thaumcraft addon, and there is a vault for each aspect - I want chests inside Ignis vaults to only replenish with Ignis loot, etc.) My initial thinking is, since its the vault door itself which contains the isVaultShut variable, it would be the vault door itself which would replenish loot in the chests. This would also save me from having to make a separate type of chest for each aspect. Could someone give me an example of how I could implement this?

[TmzOS]

For 1.8:

 

> public class TileEntityHeyYou extends TileEntity implements IUpdatePlayerListBox

 

The onUpdate() will loop each tick..

 

---

 

For 1.7: i don't remember... but can be something like 1.6.4, probably (the last mod I make in 1.7 is for 1.7.2, one year ago).

[jabelar]

Hold on guys. I think the original poster was hoping to add to existing (i.e. vanilla) chests.

 

theCorvid -- are you trying to make your own custom chest, or to alter the behavior of vanilla chests?

 

For your own custom chests, most of the advice above is correct -- you just make your tile entity process code in its update method. You could scan through the inventory and if it was empty (or had small amount of items) you could add some.

 

For existing chests, you'd basically have to scan through the chests occasionally and process them, maybe from some other tick event. However, another alternative is to just update the inventory contents at the time the player opens the chest. You could handle the gui opening and check the inventory then.

[theCorvid]

I am creating a custom chest for this, but my issue is that I want the refreshing of the chest to be done by an object other than the chest itself. The chest is only to refresh when the door belonging to its vault has been shut for a certain amount of time, and there are several different vaults. My thinking was that I could do this by actually having the vault door lock block (which controls the opening and closing of the door) actually do the item injecting after it detects it's been shut for long enough. (The chest's position relative to the door lock will always be the same, because neither the door lock nor the chest will be destroyable/moveable/obtainable.)

 

Really what I'm asking, even though I know it's very cheeky, is for someone who has a bit of time for me to assist me in actually implementing this. "Go learn more Java" is a totally valid response and I will not complain if that's what I'm told, but I'm very eager to get this done.

[jabelar]

Okay, it is a lot easier for us to help you now that we know what you're actually trying to accomplish.

 

I think the best way is to refresh from your lock block. Does that have a tile entity? In that block you would have fields with the position of the associated chest. You would also have a int field for the counter. Then, when the lock state changes you can check to see if enough time has passed, and if it has then you could manipulate the tile entity inventory for the associated chest.

[theCorvid]

Right, and that's exactly what I was asking: how do I "manipulate the tile entity inventory for the associated chest"? Like I've said, I already know how I plan on checking whether or not it's time to refresh the chest. What I don't know is how to do that.

[jabelar]

Okay, well you find the tile entity by knowing the position and checking the world for tile entity at that location using World#getTileEntity() method.

 

Then once you have the tile entity instance, there are all sorts of fields and methods (just look at the class) related to the contents of the chest. In particular you could loop through the slot numbers and use getStackInSlot() method to see what is already there. Then if you decide to add something use the setInventorySlotContents() method to place something in a slot.

[theCorvid]

Great, this is very helpful, thanks. And how would I check for a tile entity at a given location relative to the vault lock block? Would I have to make the lock a tile entity to do this?

[jabelar]

Great, this is very helpful, thanks. And how would I check for a tile entity at a given location relative to the vault lock block? Would I have to make the lock a tile entity to do this?

 

Yes, you need the lock block to remember the location of its associated chest and a tile entity is a good way to do that. You can potentially do things with world data instead, storing a map between locks and chests. In programming there is usually multiple ways to accomplish the same or similar results.

[theCorvid]

The thing is though that for all lock blocks of a given type, the chest will always be at the same location relative to it, so couldn't I just put in the lock block's code, "if _____, put _____ in the chest at xyz +/- _____"?

 

I'm also not sure how I'd go about storing information on where the chest was inside a tile entity, anyway. I am very novice.

[jabelar]

The thing is though that for all lock blocks of a given type, the chest will always be at the same location relative to it, so couldn't I just put in the lock block's code, "if _____, put _____ in the chest at xyz +/- _____"?

 

I'm also not sure how I'd go about storing information on where the chest was inside a tile entity, anyway. I am very novice.

 

Yes, if it is in a fixed location then you can get the tile entity at the fixed relative offset. However, you also said you wanted a time delay before the refresh, which would require a counter which would probably require a tile entity.

 

But like I said, there are multiple ways to solve any problem in programming. In this case, the refresh intelligence can all be in the chest tile entity, or a lock tile entity, or combination of both. I think it is logically better and probably bit better performance to have the intelligence in the lock because you should only need to check for refresh when the lock state changes. So player interacts with lock, whenever it is going from locked to unlocked you check the timer to ensure enough time has passed, then check the chest and decide whether it needs to be replenished.

 

But you can also have the check continuously check the lock to see if it changes state and then have timer in the chest and if enough time has passed decide whether to replenish the contents.