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

Machines stopped recognizing fluid from stocking inputs #18238

Open
1 of 3 tasks
Kyramesh opened this issue Dec 6, 2024 · 1 comment
Open
1 of 3 tasks

Machines stopped recognizing fluid from stocking inputs #18238

Kyramesh opened this issue Dec 6, 2024 · 1 comment
Labels
Bug: Minor Status: Triage Issue awaiting triage. Remove once this issue is processed

Comments

@Kyramesh
Copy link

Kyramesh commented Dec 6, 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

  • 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.
@Kyramesh Kyramesh added Bug: Minor Status: Triage Issue awaiting triage. Remove once this issue is processed labels Dec 6, 2024
@Kyramesh
Copy link
Author

Kyramesh commented Dec 7, 2024

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:
Screenshot 2024-12-07 170125
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:
grafik
But the DTPF is still not finding a craft:
grafik
There is some residual catalyst in the on demand subnet (Position A), because of dtpf fuel discount.
grafik

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.
grafik

@Kyramesh Kyramesh changed the title Machines stoped recognizing fluid from stocking inputs Machines stopped recognizing fluid from stocking inputs Dec 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug: Minor Status: Triage Issue awaiting triage. Remove once this issue is processed
Projects
None yet
Development

No branches or pull requests

1 participant