I'm currently playing FTB Beyond (1.2.1) and I made myself a larger Storage-Room: I have several Storage drawers, who are facing eath other on opposite sides. I connected them with Trim-Blocks (Spruce Trims).

So we have two sides of storage drawers: the left side has the controller, the right side doesn't.

When I inserted the items, everything was fine. Later I saved and quit the game. Today, when I load my world, most Items of the right side were gone. The storage drawers were empty. The items were not just invisible, they were completely gone. The left side anyway was completely fine. Not all items on the right side vanished, however. Th items that vanished were some vanilla items such as iron or gold ingots, redstone, emerald, diamond etc.

At first I suspected the trim-Blocks, so I removed them and tested it with some birch planks. After I quit and reload my world, the right side was totally fine. Well then, I replaced the trim Blocks with some Controller Slaves and tested it again: Without any trims, the issue doesn't seem to happen, but as soon as I connect both side with the trim-Blocks again, the issue occurred. But again, only on the right side.

After that, I tried to reproduce the problem in my test-world: I placed two storage drawers and connected both with the trim-Blocks. Everything works fine. No issues there.

Now things are getting very strange: I came back to my other world and broke all trim-Blocks, all slave-Blocks and the controller (So only the drawers are left) and tested it again: I put some chiseled Stone Blocks (6 blocks) and reload my game: All chiseled stone but one were gone. I had only one block in the drawer left.

Finally I put some Items in the first drawer and some Items alongside in the second drawer. I reload my world: The Items on the first drawer are kept completely, but the Items in the second drawer were gone. Wtf?

tl;dr: The items vanish randomly and I have no clue what causes it. The items inside my chest are fine, the items in my inventory are fine also. At this point I'm not even sure if this is a "Storage Drawers"-Issue or something else. But I'm a little desperate, fearing to loose even more items.

Could you check the chunk boundaries (F3 + G)? Were all of the drawers that had their items vanish, within the same chunk(s) (ie. in a different chunk than those that kept them)? Because I just experienced the same in a test world while testing something else - half of the drawers lost their items on world reload, and they were in a different chunk that the other half. So it seems like there are some markDirty() calls missing from the TileEntities when the inventories are changed.

I've noticed that the problematic drawers were actually at the edge of their chunk, i.e the block in front of them starts in a new chunk. Also, the other storage drawers are not in the same chunk as the problematic ones. This could be maybe the reason.

To me it seems that there is a TileEntity#markDirty() call missing when the inventory changes, which means that if there are no other (block or TileEntity) changes and no entities within the same chunk, then the chunk may not be saved to file when the world saves. So a work-around could be having one active TileEntity doing something within the same chunk (like a Furnace), or placing one entity (like a passive mob) within the same chunk. Although I'm not sure how reliable that would be, and obviously it isn't a proper solution.

What if I keep the chunk via FTB Utilities chunkloaded? Would this work? And does this mean, that this is not a bug, but the way minecraft/java handle such things?

@Diverscope No this is definitely a bug, that is simply related to the way things work in the game. The markDirty() call is exactly meant to mark the TileEntity/chunk as "dirty", so that it will get saved. Without the call, it may or may not save, depending on whether there have been other changes inside that chunk that would cause the chunk to get saved.

Chunk loading will only help for as long as the world/server is running. When you eventually save & exit or the server is shut down, the same issue/situation will be encountered. So for now, make sure there is some type of an entity, or another machine that is actively doing something and marking itself as dirty, within the same chunks as the drawers are in. Or you could place or break or change some blocks within the chunks.

Something that I forgot to mention: One step that I tried was to break one storage drawer, put it back and test if the item is kept: It worked when I replaced only one or two drawers, but as soon as I replaced all drawers at once (On the left side) the issues happened again. So I think this "just break and replace"-thing doesn't work always?

Anyway this issue is very strange. You might be right with your theory. Until this bug is fixed I work with chests on this side.

If your "replace all drawers at once" was done as "break all drawers, then place back all drawers, and finally place items in all drawers", then the issue is that you didn't change any blocks after placing the items in the drawers, and assuming a world save (which happens every 45 seconds) happened before you had time to place the items in the drawers.

So basically, a chunk will get saved to the disk during a world save (which happens every 45 seconds), if it knows that it has been changed since the last time it was saved to disk. This will happen any time there are entities in the chunk, or when some blocks have been set (ie. broken, placed or changed to other blocks), or if there are TileEntities that have been doing something, and have called the markDirty() method on themselves to mark the chunk as having changes. if the TileEntity (which the drawers are) doesn't call markDirty() and there are none of the other mentioned changes in the chunk, then any "changes internal to the TileEntity (like changed items in inventories, or changed machine progressions etc)" will end up disgarded as the chunk doesn't know that it should be saved to disk.

Ah, now I'm getting it. Thanks for clarifying it.

I've been strapped for time recently, but I expect to actually have some time to look at outstanding issues this week. If this can be boiled down to a set of steps that will definitely reproduce the issue, I can get to a solution faster.

But based on my read-through, is it something like this?

• Place one or more drawers in a chunk void of other TEs
• Place items in one or more drawers
• Immediately quit and reload

Pretty much yes. It's best to use for example a new, empty Redstone preset superflat world, so there are no entities etc. anywhere. However the issue still doesn't happen all the time still, which makes it a bit more annoying to debug. I can do a bit more testing to see if I can figure out a reliable way to reproduce it.

Edit: Actually yes, that's exactly it, BUT make sure you are not standing inside the same chunk yourself, as the player entity being inside the same chunk will also cause the chunk to get saved. I did some more testing, and I was able to reproduce the issue 100% of the time, when toggling on the chunk boundaries and making sure to stand in the adjacent chunk when adding or removing items from the drawer, and then saving and exiting and reloading the world. And when I stand inside the same chunk and hit esc to save the world in single player, then the drawers do get saved due to the save happening while there are entities (the player) inside that chunk.

Thanks for compiling all the information. This should be fixed in 3.6.3 / 4.2.1.

It was definitely missing markDirty() calls, and they might have been lost when I was optimizing render performance.