AE2 [fluid]storage bus doesn't work with subnetted interface

SKProCH commented 2 weeks ago

Your GTNH Discord Username

skproch

Your Pack Version

2.7.0-beta3

Your Server

private

Java Version

Java 21

Type of Server

Ultramine

Your Expectation

Fluid storage bus connected to dual interface should send fluids to subnet as item storage bus does.

The Reality

When i place fluid storage bus, set the filtered fluids near the dual interface (subnet), storage bus doesnt' send all this fluids to this subnet.

Your Proposal

Fluid interface should send fluids to subnet.

Final Checklist

[X] 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.
[X] I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
[X] 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 commented 2 weeks ago

Tested to work on a simple setup on Nightly 727 (filter storage to water, net has fluid terminal, dual interface net has storage, put water in terminal > water stored in dual interface net storage). Can you share more about your setup? Is there storage on the subnet the fluids could be going to instead? Is there storage available on the dual-interface side for the fluid to go to?

lordIcocain commented 2 weeks ago

idk if its related, but i noticed that fluid storage bus with pririty 1 and 0 sometimes swap recived fluid. It is in AL, bus with priority 1 got fluid for bus with 0, bus 0 got fluid for bus 1.

SKProCH commented 2 weeks ago

Tested to work on a simple setup on Nightly 727

Hmm, seems like this is also works in my SP test world. But doesn't work on server either with item storage buses.

Can you share more about your setup?

Just usual subnet which trying to store items in mainnet.

Is there storage on the subnet the fluids could be going to instead?

No, there is a sticky card on storage bus going to mainnet, so mainnet is the only options for fluids listed in storage bus.

Is there storage available on the dual-interface side for the fluid to go to?

Yeah, there is plenty of storage.

Btw, Items from AE2 output bus also don't pushed to mainnet (but if i place import bus in a subnet, it will send items to mainnet properly). So, i suspect there is some weirdness with my AE2 setup, but currently i've can't figure out exact conditions. If i can figure out this, i'll reopen this PR (or if someone else also experience that - let me know)

SKProCH commented 1 week ago

After a day of sitting with debugger, i figured out 2 main reasons for that:

AE2 has user uuids cache file, and for my case there was ids 0 and 1, which are unknown uuids, we don't have this players in server username cache, this ids missing from namemc (and apparently minecraft). Server runs on online mode, and we have license accounts. For some reason my subnet storage busses has owner id 0 (guid from missing player), and security manager rejects attempts to interact with the mainnet. This is resolved by editing biometric cards with /nbtedit and putting these cards in security manager.

There were also cases when I lost access to my AE system when I entered the server. Server in online mode, i've using my license account, so apparently my uuid don't changed.

Missing storagebusses handler. I've want briefly explain how this works. Every net has a GridCache object, which tracks all the inventories (cells, interfaces, storagebusses, crafting, etc). In my case it holds all subnet storagebusses, cells, etc, but storagebusses which linked to mainnet doesn't have handlers (objects represent an link to inventory kinda). So, apparently seems like when server starts subnet storage busses tries to create a handler, but mainnet interfaces doesn't yet ready, so it creates a null and marks it cached. After that this storage bus doesn't considered as storage variant.
After i break and place mainnet interfaces this starts working.

This is explains however, why this issue can't be reproduced: to reproduce it we need a really big mainnet which takes a lot of time to fully initialize, or some bugged player ids in cache.

Probably 2 case can be fixed. I'll try to look at that, but reopening the issue if anyone want's to take a look. Also, i can share my backup if anyone needs it.

SKProCH commented 1 week ago

Seems like there is some nbt saving problem.

Block owner id was saved to "proxyname/p" in nbt data, e.g.:

This is a newly placed security manager.

But sometimes this data was lost, this is my mainnet security manager (which was placed by me, my id is 2):

And after that i've lost access to my mainnet (since owner changed from me to user with id 0). This happens a couple times, seems like after server restart.

If somebody also have this problem (what occasionally security manager refuses to work with owner), please describe your case here.

GTNewHorizons / GT-New-Horizons-Modpack