You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DTPF should run if all inputs are present in stocking inputs
The Reality
My DTPF stopped running after using up it's prestacked catalyst and would not resume it's craft after refilling the catalyst. I had to brake and replaced all inputs. I also broke the controller, but not last, so not sure if that was necessary. I used advanced stocking bus and hatch, while trying to craft raw tesseracts.
I initially assume the cause is that the DTPF tried to pull fluid from the same stocking input, even after that one ran out it won't accept other hatch for the same fluid for some reason. The catalyst was initally kept in a different subnet from the one i later refilled.
The same thing happened to my PCB fab. My pcb fab only ever had 1 stocking input bus + hatch, so it can't really be related to using mutliple inputs, and i was initially using regluar stocking hatch, so it would affect both version of the block.
I tried replicating this behaviour with a LCR making HCl from 2 seperate stocking hatches in 2 subnets, but could get the bug to reappear. And then with a dual recipe, but i can't reproduce the bug yet.
Your Proposal
Fix.
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.
The text was updated successfully, but these errors were encountered:
managed to trigger this bug consistently with the following setup:
My DTPF Setup, trying to maintain a passive production of Hypogen while also allowing on demand crafting tasks:
The passive stocking (Position B) hatch is being disconnected from it's subnet via toggle bus/level emitter combo, to force the dtpf to stop using the hypogen recipe.
After finishing the the on demand tasks the level emmiters allow the hypogen hatch to be reconnected again, which should resume the passive hypogen.
As you can see the hypogen hatch is online and can see fluids:
But the DTPF is still not finding a craft:
There is some residual catalyst in the on demand subnet (Position A), because of dtpf fuel discount.
After breaking and replacing the Hatch in Position A i could get the DTPF to start 1 craft, but then it got stuck again.
I then tried to move the on demand hatch to a new Position C, which for the moment got the dtpf to resume it's passive hypogen craft without issues.
Kyramesh
changed the title
Machines stoped recognizing fluid from stocking inputs
Machines stopped recognizing fluid from stocking inputs
Dec 7, 2024
Your GTNH Discord Username
Kyramesh
Your Pack Version
2.7 RC-3
Your Server
SP
Java Version
Java 21
Type of Server
None
Your Expectation
DTPF should run if all inputs are present in stocking inputs
The Reality
My DTPF stopped running after using up it's prestacked catalyst and would not resume it's craft after refilling the catalyst. I had to brake and replaced all inputs. I also broke the controller, but not last, so not sure if that was necessary. I used advanced stocking bus and hatch, while trying to craft raw tesseracts.
I initially assume the cause is that the DTPF tried to pull fluid from the same stocking input, even after that one ran out it won't accept other hatch for the same fluid for some reason. The catalyst was initally kept in a different subnet from the one i later refilled.
The same thing happened to my PCB fab. My pcb fab only ever had 1 stocking input bus + hatch, so it can't really be related to using mutliple inputs, and i was initially using regluar stocking hatch, so it would affect both version of the block.
I tried replicating this behaviour with a LCR making HCl from 2 seperate stocking hatches in 2 subnets, but could get the bug to reappear. And then with a dual recipe, but i can't reproduce the bug yet.
Your Proposal
Fix.
Final Checklist
The text was updated successfully, but these errors were encountered: