Advanced Modem / Virtual Pipes peripheral

[RobertBouillon]

Describe your idea

Create a block that would provide access to each side of a "peripheral" block. This could be identical to a CC:T modem except the API would accept a "side" for both the source and the destination when pushing/pulling items/fluids. Ideally would work with items and fluids at a minimum, however RF, Mekanism gasses, etc. would be great.

Providing a modem with access to a peripheral's sides would allow CC:T to interact with any block that's normally friendly to "pipes", even if the rest of the API is janky (many are). As it is currently, CC:T ignores sides, which makes it impossible to interact with many blocks, and the maintainer has indicated that this is a design decision. I'm hoping you disagree.

This would allow CC:T to act in the same manner as something like XNET.

Describe alternatives you've considered if you've any

I could just not.

Additional context

No response

Linked Issues

No response

[zyxkad]

What about place the modem on each side of the inventory? It will makes more sense.

[Einhornyordle]

I agree with zyxkad, the same way you'd have to connect a pipe or hopper to the correct side you'd also have to check the side the modem is on, if you need access to multiple sides, use multiple modems.

But I do also agree that CC:T with XNET capabilities would be amazing, although this sounds like hell to implement.

[RobertBouillon]

What about place the modem on each side of the inventory?

@zyxkad This was my thought at first, as well, but I ran into some issues in practice:

• The side defaults to 'null' when the inventory/fluid API's are available. This prevents me from creating reliable / reusable code to access the sides of a machine because access would depend on that specific machine's API support.
• This can get crowded with machines that have multiple inputs and outputs, defeating the purpose. It would be great to use CC:T to control all machine I/O through a single cable / interface.
• This would only support items and fluids. Would love RF & Gasses as well.

But I do also agree that CC:T with XNET capabilities would be amazing, although this sounds like hell to implement.

@Einhornyordle I'm doing this in skies expert and it hasn't been that bad - the trick is to find good reusable patterns. The code could be made even simpler if I could implement "virtual pipes", but I need reliable access to sides to make a clean API. A more ambitious individual could probably recreate the XNET UI in CC:T.

Current "Factory Controller" (Simplified)

local inv = require("inventory")

local STORAGE 	= inv.wrap		("functionalstorage:storage_controller_0")
local FLUIDS 	= peripheral.wrap	("functionalstorage:storage_controller_0")

local WATER 		= "minecraft:water"
local POTATO 		= "minecraft:potato"

local POTATO_MACHINE	= inv.wrap("thermal:machine_insolator_0")

local function usePhyto(machine,seed)
  FLUIDS.pushFluid(machine.name, nil, WATER)
  STORAGE.push(machine,seed)

  --Only push output
  for slot,item in pairs(machine.list()) do
    if slot > 1 then
      machine.push(STORAGE.name,slot)
    end
  end
end

while true do
  usePhyto(POTATO_MACHINE, POTATO)
  --SCALE!
  sleep(0)
end

(My inventory API adds the ability to specify an item name instead of slot)

Access to sides would enable virtual pipes

local pipes = require("pipes")

local STORAGE 		= pipes.wrap("functionalstorage:storage_controller_0", "bottom")
local POTATO_MACHINE	= "thermal:machine_insolator_0"

local WATER 		= "minecraft:water"
local POTATO 		= "minecraft:potato"

local function usePhyto(machine,seed)  --Configure TOP input, BOTTOM output
  STORAGE.pushFluids(machine, "top", WATER)
  STORAGE.pullItems(machine, "bottom") --Side configured for output - no need for filter
  STORAGE.pushItems(machine, "top", seed) --Recycle seeds
end

while true do
  usePhyto(POTATO_MACHINE, POTATO)
  --SCALE!
  sleep(0)
end