Description

ME IO Port should accept inputs into the "input" side and allow extraction from the "output" side via hoppers, pipes, etc. (At least I believe this feature used to exist--if not, this is a suggestion, not a bug!) Currently neither works.

Environment

Tested on a multiplayer server.

Minecraft Version: 1.12.1
AE2 Version: rv5-alpha-4
Forge Version: 14.22.0.2475

To be clear, you used the right input (top or bottom face) and output (sides faces) side as described in http://ae-mod.info/ME-IO-Port ?

Never mind. It was a larger (unrelated) bug that corrupted all the Tile Entities in that chunk. This ticket can be closed.

I, for one, would be interested in hearing more about TE-corrupting bug, if you happen to have a link available. If it finally puts away the weird block-state exceptions that have been popping up since 1.10.2, I would quite like to be able to pass the details on to others.

It is a forge feature going back to 1.9.4 or even earlier. I talked with some other devs and it seems more or less all encountered it. AE2 is simply more noticable as losing all cells is way more obvious than some furnaces losing a few leftover coal, you do not even remember leaving there.

Currently I suspect it is some race condition in their asynchronous chunk loading. Which is just a stupid idea in a non threadsafe environment like minecraft and also does not exist in vanilla. No idea what approach forge uses, but I really do not intend to look into forge itself. It is their job to fix it.

A event loop based approach is pretty much useless for minecraft. In this case some pipe/hopper/machine loading a different chunk would be put it to sleep until the chunk is fully loaded, while other things can continue to work. Which means once the hopper gets woken up, minecraft might already haved ticked a few time more thus the old state would no longer be valid.

Which pretty much leaves a multithreaded approach. Which is just a nightmare to get right without designing the whole application around it. E.g. having everything immutable etc. Especially as the chunkloading causes some really strange behaviour for tile entities. If a hopper (or something else) loads a different chunk during their update tick, it will cause the normal tileEntitity.onLoad -> tileEnitity.validate as part of the hopper, but then queue an additional tileEntity.validate during the normal world tick. But for whatever reason also calls a tileEntity.invalidate before the second validate. Which basically indicates this one was just broken by a player (or machine, whaterver). And this happens for the whole chunk. Should it now happen that something causes the chunk to be saved and that happens to run in a different thread, it can easily cause the save to drop all tileentites as they are no longer valid for the tiny fraction of time they are invalid. Or just saving a half loaded chunk and if nothing then marks the chunk as dirty to queue a new save, then it will just load the unfinished save next time. It might be something which gets never fixed due to the complexity and nearly being impossible to reproduce in a reliable way.