Machine Crash due to Stocking Input Bus/Hatch

[OlliedeLeeuw]

Your GTNH Discord Username

ollie_de_leeuw

Your Pack Version

2.5.1, same issue in 2.5.0

Your Server

private server

Java Version

Java 19

Type of Server

Vanilla Forge

Your Expectation

The stocking input bus/hatch to continue working and the machine to not crash.

The Reality

the machine shuts off with a crash


-version: 2.5.1 , ignore the maintenance issue it does not affect the result. 3 stocking input busses (1 without auto-pull, 2 with auto-pull)

-version: 2.5.0 (image from NotAPenguin), 1 stocking input hatch (without auto-pull)

Your Proposal

When failing to extract happens it should proceed to do the next recipe check instead of staying on the failed extraction and crashing.

Don't have steps to reproduce it, first time happening to me, NotAPenguin has had it happen a few times in his mega naqline.
(similar to #15172 but different error)

Final Checklist

• I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
• I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
• I have asked other people and they confirm they also have this problem by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.

[NotAPenguin0]

To elaborate on this, I found this to happen the most when there are multiple very fast machines (MCR, MDT, MBF) contesting the same fluid. The issue is not exclusive to this case though (see large naquadah reactor)

[miozune]

• Issue with having multiple stocking buses/hatches with the same configured ingredient included in the same machine (maceration stack one), can be mitigated by restoring Fix the shadow ItemStack bug of multi-InputBus_ME GT5-Unofficial#2104. However, it has one downside; Stocking buses from different network with the same configuration will lose the ability to have parallel of two hatches combined, but limited to either of them instead.
• Issue with attaching stocking buses to different machines from the same ME source (what @NotAPenguin0 brought up) cannot be fixed without extra work on feature to get it running because of the way stocking bus/hatch currently work.
  • The "proper" fix is pulling actual ingredients from the network. It will permanently remove the chance of having accidental attempt to dupe ingredients. However, I got massive nay from players when I implemented it, since it means they need to re-configure all the stocking buses to fix load balance issue. (Rework Stocking Bus GT5-Unofficial#2324)
  • Another way comes to my mind is telling other buses in the same network that it consumed ingredients and others should also decrease stored ingredients. However, this might lead to massive lag caused by traversing ME network each time ingredients are consumed.
  • Or we can simply allow duping ingredients since they're infinite at this point
  • Anyways, these two have major caveats and need good amount of time for implementation. Or if you have another idea please share that.

[lordIcocain]

@miozune Just dont turn off machine when this error, update stocking and go next recipe check. its will work?

[bombcar]

The "proper" fix is pulling actual ingredients from the network.

could this fix be implemented as a “high speed parallel stocking bus” (maybe even similar price) that utilizes this code but leaves the existing as is?

[miozune]

Just dont turn off machine when this error, update stocking and go next recipe check. its will work?

Doesn't it mean the machine might void all the ingredients that are consumed along with problematic ingredient failed extraction in the network until you notice something is wrong with setup?

could this fix be implemented as a “high speed parallel stocking bus” (maybe even similar price) that utilizes this code but leaves the existing as is?

I'm not sure if people would use it honestly. Current way might be easier to use since it doesn't need extra configuration for load balancing.

[lordIcocain]

Doesn't it mean you might lose all the ingredients that are consumed along with problematic ingredient failed extraction in the network?

Return consumed ingredients back to network would be perfect solution.

[miozune]

Return consumed ingredients back to network would be perfect solution.

Maybe, but it still voids certain ingredients and refuses to process them without warning, which is not great imo.

[NotAPenguin0]

That wouldn't be ideal, but machines with stocking buses/hatches randomly turning off every few hours is also not a great experience.

[lordIcocain]

oh, so its impossible prevent void? sad

[miozune]

I might work on this feature tomorrow to see how it could affect performance; telling other buses in the same network that it consumed ingredients and others should also decrease stored ingredients

What do you think about this one? it has one downside; Stocking buses from different network with the same configuration will lose the ability to have parallel of two hatches combined, but limited to either of them instead.

[lordIcocain]

@miozune What about add quick and dirty fix for now? add min stack size to non auto pull mode and in error write "increase min stack size for prevent error"

[boubou19]

it's useless as it won't be pushed in a potential 2.5.2. Dirt hacks like this should be avoided.

[lordIcocain]

I might work on this feature tomorrow to see how it could affect performance; telling other buses in the same network that it consumed ingredients and others should also decrease stored ingredients

What do you think about this one? it has one downside; Stocking buses from different network with the same configuration will lose the ability to have parallel of two hatches combined, but limited to either of them instead.

This will not working for situation when one stocking shared between several machines.

What if you take your rework and add stocking input bus/hatch slave (similar as with crafting input buffer). ofc still need re-configure setup. but it's much easier and perfect load balance. what do you think?

[miozune]

Now I'm confused... Reading code makes me think the second issue is impossible to happen, unless items/fluids visible from buses/hatches are actually duplicated... Or maybe my brain is sleeping... Another pair of eyes for investigating this issue would be appreciated.

[NotAPenguin0]

it has one downside; Stocking buses from different network with the same configuration will lose the ability to have parallel of two hatches combined, but limited to either of them instead.

This sounds fine tbh, I've never ran into a case where this would be useful.

[NotAPenguin0]

Now I'm confused... Reading code makes me think the second issue is impossible to happen, unless items/fluids visible from buses/hatches are actually duplicated... Or maybe my brain is sleeping... Another pair of eyes for investigating this issue would be appreciated.

I never got this issue on 2.4.0, so I'd imagine this is indeed a bug that has snuck in somehow.

[miozune]

I never got this issue on 2.4.0, so I'd imagine this is indeed a bug that has snuck in somehow.

This anti-dupe feature was introduced after 2.4.1

[lordIcocain]

[2.5.1] Getting this error twice today with only 1 stocking hatch in subnet shared between 4 LPF, so solution "let stocking speaking between each other" not working at all.

So allow dupe or rework. My opinion that rework should be, but with 2 changes:

1. Add stocking input slave (should work as with crafting input buffer)
2. Add ghost mode that let stocking work like it work now. This need for automation where you have non consumed items which should be in network constantly. Or just ability set list of items that should be stocked in as ghost.

edit. oh, that will totally broke automation system that based on read if cell still contain items. So number used bytes on cell where items/fluid come from should didnt change until items/fluids in stocking will be consumed.

now my solution looks really nuisance. :(

[lordIcocain]

what if
machine found recipe -> stocking pull items from ME inside and if all ok -> start recipe. if no go next check. this prevent voiding other ingredients? or its just impossible?

[lordIcocain]

I think its happen because sometimes slot updating happen before end recipe check, storedFluids[i] already null and cant be checked, that explain why happen only in auto pull mode, also explain why you can get wrong positive check for "failed extract from storage" error. Also idk why, but sometimes its just cant happen on current game load, i need restart game and then it start happen.
I have world save where can easy reproduce error, so i can run gt5 with extra console outputs for get more information.

[Riverness]

I believe there's a third issue: When the current recipe has insufficient of the stocked input material(s), the machine shuts down with this error. That should not crash the machine, there is just not enough input, it's not that the system "couldn't extract from ME".. It doesn't happen if the last run of the recipe completely finishes the input material.

[Riverness]

Just happened with an input I'm 100% sure it isn't being requested by anywhere else. Not autopull, using the basic stocking input bus. When I have time later I will try replicating in a fresh world.

[RitumsC]

Additional observations on the issue reported by Penguin in the comments:

This only seems to happen with the advanced stocking hatches.

I had a setup of 4 compact mk III fusion reactors and 1 mk IV; all mk III had regular stocking hatches with whitelisted fluids, and mk IV the advanced stocking hatch. When running recipes they properly pulled from the subnet without any problems.

Then I switched all compacts to use advanced stocking hatch, and now I constantly get this error and voided materials.

ETA: It seems that when i disable the auto-pull feature and just whitelist the fluids, it seems to no longer crash and properly produces all expected products.

[Riverness]

Something is making the stocking input bus think the system has double the amount of the stuff.

I checked a few other buses, all of them exhibit this behaviour. The dusts are stored in a subnet drive, and these stocking input buses are all through p2p networks.

Edit: Also happens without p2p.

Edit Edit: I tried by requesting something that isn't in a subnet, and it's not doubled. I think it's only happening with items in a subnet. I will now try doing a subnet from the subnet and see if it triples (or quadruples)

[Riverness]

Okay. I determined the cause of the doubling in my case. I have multiple storage buses from the main net going to interfaces in the subnet, and all of them are bi-directional. The stocking input bus is reading the contents of the subnet from both storage buses separately, and this results in the stocking bus thinking it has double the items. In my case, this should be the root cause of the machines crashing.

I should be able to solve it by adding an unfiltered storage bus (extract only) to the subnet interface, and put the filtered ones to insert only.