Wireless / Cloud Computation Inconsitent

[Ruling-0]

Your GTNH Discord Username

ruling_

Your Pack Version

2.7 RC1

Your Server

Private Server

Java Version

Java 21

Type of Server

Vanilla Forge

Your Expectation

When turning on QCs, their computation data should be consistently put in the network (summed) so that clients can pull the amount that they are producing.

The Reality

In one instance, computation in the network is dominated by these two values (occasionally one much lower, and occasionally one much higher at around 3M). This is turning two on manually (some delay) and 2 on with wireless redstone covers (should be instant)

This is turning all four on with the switch

Turning all four on at the same time means that only half of the computation is actually available. This isn't a scanner bug - the research station will consistently fail when trying to draw the 600k computation that I should be producing

Turning all four on at random times will produce values that alternate between 300k and 600k. Even if 600k is showing as the computation, the research station will still computation fail, possibly because when it tries to pull from the network is when the network is not actually holding 600k. This doesn't always mean I need to tie it to the minimum - in the 300k-600k case, 450k client setting seemed to work.

Speaking on the discord at least one other person has had issues with their QCs producing 50%.

Your Proposal

I should always be able to pull my full computation production out of the network, not have to get lucky with ticks or whatever magic is happening on the backend.

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.

[Ruling-0]

After a server restart the research station can now pull more than the scanner readout is showing. Even though the scanner shows values of 0/150k/300k RS reliably pulled 450k.