Implement Quantum Storage Controller Network

[ghzdude]

What

Implements the Quantum Storage Controller, a block which combines the inventories of connected Super/Quantum Tanks/Chests to allow I/O from attached storages. This PR continues the work of the ds-quantum-storage-improved branch.

Implementation Details

• Quantum Storage MTEs use IDs 1757 - 1760
• Implements interfaces IQuantumStorage and IQuantumController.
• Implements abstract class MetaTileEntityQuantumStorage with logic to handle dis/connecting from the Quantum Controller.
• Quantum Controller has logic to rebuild it's network and a handler to handle I/O from attached storages
• Item I/O from the Quantum Controller handler is working, but could be improved I think.
• Rendering of the Quantum Controller should be discussed, if current rendering is not desired.
• Creative Quantum Tank/Chest works with the storage controller as well
• Creative Tank/Chest will only output from the storage controller if it is active
• Normal Creative Tank/Chest behavior (auto-output to the output face) is disabled if connected to a storage controller

To-do

• Implement MTEs
  • Quantum Storage Controller
  • Quantum Storage Extender
  • Quantum Storage Proxy
• Add textures for...
  • Quantum Storage Controller
  • Quantum Storage Extender
  • Quantum Storage Proxy
• add recipes for...
  • Quantum Storage Controller
  • Quantum Storage Extender
  • Quantum Storage Proxy
• change the connection icon to the GT logo and put it in the bottom right corner
• add energy usage
  • TOP
  • Hwyla
• add indicator overlay
• add controller highlight rendering to connected qchests/qtanks

Outcome

Players can connect several super/quantum chests/tanks together and I/O from them all.

Additional Information

8mb.video-Tmh-Y5Mci6p6.mp4

Potential Compatibility Issues

Existing instances of super/quantum tanks/chests should not be affected, otherwise no other compatibility issues afaik.

[IntegerLimit]

Completely rendering fluid drawers (and by extension, storage drawers) useless. Yes!

[ghzdude]

this pr will be ready for review once the 2.8 branch is merged into master and I rebase it if need be

[ALongStringOfNumbers]

The controller the tank/chest is connected to in the GUI is a nice touch, but if possible, it might be even nicer to have it as a clickable button that highlights the controller in world.

Also, I am having thoughts about the Controller having a GUI that lists all the fluids/items that are stored via connected tanks/chests.

Also, thoughts on the controller having a power upkeep requirement?

In addition, I think that the parts should be gated differently, but that is just me, we will have to see what everyone else thinks

Also, I am not sure about the need for the ULV super tanks/chests. The super chest 1 is available extremely early (basically only needs 4 LV circuits), so I think relying on our crates is fine until this point.
If it is decided to keep these, then they need recipes.

I encounter a slight error in linking, detailed more in discord.

Could this PR make use of the Neighbor cache with MTE.getNeighbor, instead of calling GTUtility.getMTE

[ghzdude]

The controller the tank/chest is connected to in the GUI is a nice touch, but if possible, it might be even nicer to have it as a clickable button that highlights the controller in world.

:servernotforrendering: (Honestly not a bad idea, but i'd have to figure out rendering to do that)

Also, I am having thoughts about the Controller having a GUI that lists all the fluids/items that are stored via connected tanks/chests.

I don't know about this, you could just as easily slap an AE2 storage bus on the controller or proxy to see all the items or fluids.
I feel like trying to implement this will result in duping crafting station 2.0, and this could maybe wait for new MUI to be implemented.

Also, thoughts on the controller having a power upkeep requirement?

Hmm, this could be interesting. I'd probably add an "energy acceptor" type block to power the quantum controller network (to keep the sides of the controller or proxy open for I/O)

Also, I am not sure about the need for the ULV super tanks/chests. The super chest 1 is available extremely early (basically only needs 4 LV circuits), so I think relying on our crates is fine until this point. If it is decided to keep these, then they need recipes.

The idea behind the ULV chests/tanks is that they can compete with drawers from Storage Drawers, which mostly need wood to craft. Though, it does seem that LV super chests are much cheaper compared to LV super tanks. Maybe the ULV chest isn't that much more cheaper, but a ULV tank certainly would be. A ULV tank could probably take a bronze drum, wrought plates, and something to replace the pump, For the ULV chest, it could take some wrought iron, a bronze crate, and ULV-tier circuits,

[ALongStringOfNumbers]

Also, thoughts on the controller having a power upkeep requirement?

Hmm, this could be interesting. I'd probably add an "energy acceptor" type block to power the quantum controller network (to keep the sides of the controller or proxy open for I/O)

I did some thinking on it, and thought that if implemented, it should be kept pretty low. The numbers I was thinking about internally were 8 EU/t per connected Tank/Chest and 2 EU/t per connected extender. And yeah, an "energy acceptor" type block could be a nice solution to keep some faces free on the controller.

:servernotforrendering: (Honestly not a bad idea, but i'd have to figure out rendering to do that)

I think Trouser's AE fork does something like this, if you need a possible example. From the interface terminal for highlighting interfaces in the world