Disabling an adapter side does sound like an interesting idea.

Unfortunately, it's not really possible to check if a cover blocks data as there are only methods to check if a covered side accepts items, fluid, EU or redstone.

Why would you need side-specificness to compact setups? Wouldn't you merely have one component you don't need in your network if there is an adapter adjacent to it? I don't see how a single redundant component would be this bad.

Because e.g. if an adapter is for a battery buffer, then it is fairly probable that there would be a lot of power cables around, if it a central power storage. And I certainly don't need any components for these cables even if they touch the adapter. Redundant components are bad because of the components limit. Even with server component cards the limit is not that high. Currently in the component list of my server about half of the components are cables. (Yes, I like compact design)

One solution to this (I don't mean it be easy to implement), would be to get interfaces as multi-part panes using AppliedEnergistics2 as a model. Keep current interfaces as single-block for convenience and backward compatibility but add option to convert these to interface panes to stick on computer cables.
Panel interface should only show component on its side.
Fit compact designs by interfacing multiple sides of a same computer cable block.

@wkalinin The obvious solution would be not to place the Adapter next to the cables. If you really are using all sides of the battery buffer in such a way that there are always cables nearby, you might instead want to re-think your design with OpenComputers in mind. That's not about compactness. Adapters cannot be set to check only specific sides and Computronics can do nothing about that, while the GregTech side doesn't provide any method to check whether a cover should block data transmission, otherwise I would have already implemented that.

@leagris This is not something that would belong into Computronics.

Unfortunately, it's not really possible to check if a cover blocks data as there are only methods to check if a covered side accepts items, fluid, EU or redstone.

The obvious solution would be to look if the cover blocks everything (which is the default), and only if it does not block something, then register a component.

But why would blocking items, fluids or redstone impact data flow in any way? It simply makes no sense.

On 06/06/2016 15:46, Vexatos wrote:

But why would blocking items, fluids or redstone impact data flow in any
way? It simply makes no sense.

Redstone is Data. So if covered side is blocking Redstone, maybe that
interface should not be reading the machine behind.

Gregtech as multiple kind of covers.

• Simple cover of one material, block everything. Think of a blind metal
  plate on a device.
• Purposed cover (pump, conveyor, sensor...) these may let pass only any
  of: Items, Fluids, Energy, Redstone

Would be fair: If you cannot read/transmit redstone through a side, you
should not read data from the block.
Considered as dumb block.

I probably could do that. I'll look into it.

As of OpenComputers 1.6.1, you can wrench an adapter's side to turn it off; that might help.

Yes, of course, thank you.

Just awesome. It also save on collecting unused data.