Simple Storage Network

Simple Storage Network

57M Downloads

Linking Simple Storage Network and AE2 together

Sorbe opened this issue ยท 9 comments

commented

SevTech 3.0.8 / Java 8u172 x64

First of all, I just love Simple Storage Network and our whole house uses SSN on SevTech for our primary storage needs. It awesome that it's infinite range, transdimensional and does not require power. It's helped us get all the way to "Creative mode" in that mod pack.

I'm also starting a new AE2 network for auto crafting and doing some complex P2P stuff. I've tried linking to link AE2 and SSN without success. I was hoping to have bi-direction inventory access. Or at least SSN inventory access for AE2. Normally an ME Storage Bus just needs to see an inventory on the adjacent block. So far, nothing has worked.

  1. ME Storage Bus <=> Storage Network Master
  2. ME Storage Bus <=> Storage Link Cable
  3. ME Storage Bus <=> Storage Request Table

Am I missing something or has this never been made to work? If this scenario is not yet supported, please consider this a feature request. I would really like to keep SSN if at all possible.

commented

I think the issue is how the inventory and cables/busses work.
The storage bus is looking for an attached inventory, which simply doesn't exist in the SSN (other than as the attached inventories).
Likewise the link cable is also looking for an attached inventory.
The only one I have been able to get to work for AE (other than seeing the disks), is the ME interface. This allows you to put some items in the interface which a link cable can see and which you can take out from the SSN, and allows items to be put into the AE system from the SSN.
However you can't see any of the SSN items from the AE system other than those residing in the AE system.

Refined storage is a lot better, but still not completely bi-directional.
You can use an interface from refined storage and then see all the items in the refined storage network in the SSN, take items out and put items in (although the insert speed is limited by the speed of the interface), but you can't see any items that are just in the SSN from the refined storage system.

Also, with the way it works, I'm not sure how wise it would be to have full bidirectional support without significant mod integration.
As an example, say you have a single item in the SSN. AE then sees this item in the SSN and updates what it has.
The SSN then sees that the AE system has this item and updates its total to say it has 2.
This loop continues, adding the amount of items actually there each step.

Refined storage doesn't have this problem with itself as I think the cable connects through the storage bus so it gets combined into a single network.

commented

What I would like to do, in theory is

  1. Connect one of SN's cables to the refined storage main master block or grid and have it work both ways. If RS exposes item interface / capabilities this might be an easy way.. OR
  2. create a custom interface block in this mod ( like an RS bridge ) that handles things. this would be more work but might be cleaner
  3. In SN's master block, if RS could hook up one of their import/export busses to that, we could connect it that opposite way
commented

I think #2 would be ideal because it would allow for interactions beyond just interfacing with AE and RS, and it probably wouldn't have to be as complicated as it might seem. In order to allow for interfacing with other inventory systems it would only need to achieve 2 things: displaying the entire contents of the network as an inventory to connected blocks, and importing anything inserted into it to the network.
I believe such a block would be better than a cable that interfaces with AE and RS because it would simply be more versatile with broader functionality, as it would just work with stuff like projectred transportation or any other mod, rather than having to add specific cases for whatever we want it to work with, which would possibly even end up being more work as additional desired use cases arise.

commented

how come you can connect an AE2 "ME Storage Bus" to a Storage Drawers "Drawer Controller" and it works as expected (you can see all the storage that's connected to the Drawer Controller) ? Can't the "Storage Network Master" implement whatever interface the Drawer Conrtoller is implementing that allows this to work?

commented

One update is that RS no longer does that. Now it works like AE2.

A key distinction between the drawer controller and the storage network master is what mods the interact with.
With the drawer controller it is entirely self contained (i.e. within its mod) and the only issue comes from compacting drawers reporting all types of items.

But this mod interacts with other mod inventories and vanilla inventories and this can cause a loop which rapidly goes out of control.

As an example, lets say you have an AE2 network and a SSN. You hook them up to each other so from the AE2 network you can see the entirety of the SSN inventory, and vice versa.
You now put a single item (say a steak) into a chest connected to the SSN.
It now reports it has 1 steak to AE2.
AE2 now reports that it has 1 steak to SSN.
SSN now thinks it has 2 steaks, one in the chest and 1 in the AE2 system. So it now reports 2 to the AE2 system.
Now the AE2 system reports that 2 back to SSN, which make it think it has 3, and so on.
This number keeps building until you reach the integer limit. (I notice this is what I had already said).

Another issue comes from putting an item in.
In order for it to work properly you would want to be able to put items back in. So if you go to the AE2 network and put a steak in it should be able to some inventory connected to the SSN. And the same applies the other way so you can put an item in the SSN and have it go into the AE2 system. This would also include things from automation.
Now lets say you go to the interface (which wasn't set up to avoid this issue) and put a steak in. It sees the AE2 network and puts the steak in there. The AE2 system then sees the SSN at puts the steak in there.
So now the steak rapidly cycles between the 2 systems, again likely causing a crash.

These are 2 significant issues that need to be thought of when trying to connect 2 different storage mods which interact with other mods.

I think the best option is a storage network inter-converter block (possibly as an entirely separate mod), which will properly connect between the mods and prevent these infinite loops.

commented

but these method calls are synchronous and single-threaded, right? avoiding recursion is trivial this in this case.

commented

Remember, it isn't necessarily all happening in one tick, and I don't know how much of the storage content is cached rather than rebuilt every tick.
And you would also want it to be able to handle not just the simple case of 2, but also 3 or 4 or more different storage mods; as well as multiple connection points between these mods (unless the mod detects it and just refuses to connect) So not just this trivial case but also more complex cases.

How would SSN know if the steak reported by AE 2 is a steak from SSN or from some other storage?
Especially if we add in RS as well.
Now RS sees the steak in SSN, AE sees the steak in RS, and SSN sees the steak in RS.
How does SSN know if that is the same steak, or if it is a steak stored elsewhere that it should be reporting?
We can even stick a chest or drive on all three storage systems and add a steak to each of them.
Now how does each network know that they should report 3 steaks rather than just 1?

What about if instead of a complete triangle, we just have AE and RS connected to SSN, with no direct communication at all between RS and AE?
Again, how does each network know that they should report 3 steaks?
If SSN is the sole go-between, then it needs to report 2 steaks to each network and know that 2 of the three steaks the network reports back are its own.

Assuming each mod builds its inventory at the same time (i.e. in the same tick) then one potential solution would be to set a flag when it starts to build its inventory, and then clear it when done. If it tries to build its inventory when the flag is set it just returns nothing.
Now SSN starts building its inventory. It sees AE2 and requests its inventory, AE2 then builds its inventory, sees SSN and requests its inventory, SSN sees the flag is set and returns nothing, so AE2 just returns its own inventory and thus SSN gets the correct inventory.
Assuming AE2 then does the same it also gets it correct.
If either cache the inventory then bad things happen.

But throw in RS and what happens?
SSN starts, and requests AE2. AE2 sees SSN and gets nothing. AE2 also sees RS and requests it. RS sees AE2 and SSN and gets nothing just returning itself, importantly, it also clears the flag saying it is done. AE2 now returns both itself and RS and clears its flag.
Now SSN also sees RS and requests it. RS sees AE2 and SSN, SSN returns nothing but AE2 returns its inventory (and nothing from RS and SSN). Then RS returns both itself and AE2.
So now SSN sees its own inventory correctly, but it sees the inventory of AE2 and RS twice.

If we try to prevent that with a global tick flag, which only gets cleared at the end of a tick, then, assuming SSN goes first, followed by AE2, then RS. SSN will have the correct inventory, while the others would report nothing. So it would also need to clear its flag for when it generates its own inventory rather than when another calls it. This also means each mod generates its inventory several times, and requires changes in all the mods.

Hence why I think the best way to handle it is via a separate mod which can interact with all three.

commented

So what is the result of this idea now?

commented

@b3z good question. bumping to 1.16+ for consideration. 1.12 is too late in lifespan for any big sweeping changes like this, dependent modpacks etc.