Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RealMangorage opened this issue Apr 6, 2023 · 4 comments
Open
Labels
1.19 To be confirmed Looks like a bug, hasn't been confirmed by a dev

Comments

@RealMangorage
Copy link

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

@pupnewfster pupnewfster added To be confirmed Looks like a bug, hasn't been confirmed by a dev 1.19 labels Apr 7, 2023
@pupnewfster
Copy link
Member

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.

@Tyronadre
Copy link

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

@pupnewfster pupnewfster added this to the 10.4.0 milestone Jul 12, 2023
@kittywitch
Copy link

kittywitch commented Sep 1, 2023

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

@kittywitch
Copy link

kittywitch commented Sep 1, 2023

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.

@pupnewfster pupnewfster removed this from the 10.4.0 milestone Sep 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.19 To be confirmed Looks like a bug, hasn't been confirmed by a dev
Projects
None yet
Development

No branches or pull requests

4 participants