Mekanism

Mekanism

111M Downloads

Backstuffing causes chunk to get overloaded (NBT too large, etc)

RealMangorage opened this issue ยท 4 comments

commented

Issue description

It would do what Title suggests. I suggest making it so if a Transporter has items that failed to be sent to destination that it would not continue to extract at source

Steps to reproduce

image
Do this and have both drawers be full.

Minecraft version

1.19.2 (Latest)

Forge version

43.2.8

Mekanism version

10.3.8 (Latest)

Other relevant versions

No response

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

No response

commented

I will try to look into this more when I am working on #7748 as I believe what may be happening is our checks are happening in the wrong order and it might be attempting to extract before validating the currently idling stacks. I am not sure what the most performant way to handle this will be, it might end up being that it will be an intermediary approach of checking if any idling stacks are the same as one of the stacks that would be pulled and if so just redirect that stack instead of pulling, and otherwise if it is a different type do so and allow the previous one to continue idling.

A potential workaround might be to run the transporters one level higher and have them all just pull from the drawers, as then they shouldn't pull any extra items that the final destination can't accept as at the moment what is happening is they pull to try and insert, but then I presume the block below the drawers inserts into the drawer and causes it to fill up.

commented

I do have the same problem, but i can not say with accuracy which pipes give me the error. (The pipe in the crashlog is not always the same)
Sometimes it leads to a server crash and sometimes its only a client disconnect.
I run a lot of logistic pipes in a compact machine. Some of them are pulling out of sifters (create) and into chests (there is always space in at least one chest). Some of them are getting items pushed into by machines (Diamond hammer) and then distributing the gravel to the sifters.

This only seems to occure when changing dimensions or joining the server.

crash-2023-05-02_17.32.23-server.txt

commented

Moving positional values away from the chunk containing those pipes resolves the issue, the only way to get away from the issue as an actual user/server-host appears to be to not use Mekanism's pipes. This is what I am likely to do. Otherwise, I face losing weeks of progress and effort on my server. It is likely the intersection in my case between an RFTools Builder outputting through Mekanism transporters into a set of Storage Drawers via a Storage Controller, where Cobbled Deepslate is being sent to a full bucket and failing in perpituity.

commented

Can confirm, have been running into this issue myself since yesterday night...