-
-
Notifications
You must be signed in to change notification settings - Fork 532
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
Comments
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. |
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) This only seems to occure when changing dimensions or joining the server. |
Can confirm, have been running into this issue myself since yesterday night... |
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. |
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
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
The text was updated successfully, but these errors were encountered: