Opencomputers: Provide setting or card to stop discovery of all connected blocks

[clubpetey]

I've seen several comments in threads on this issue but could find an official bug, so I thought I throw out some ideas:

Problem: I create very compact systems with a lot of machines connected to each other. I also use RotaryCraft, which tends to have a lot of blocks connected to each other that can be access by OpenComputers. However, connecting one of these blocks to a computer (or adapter) quickly exceeds my component limit for that computer, because it attaches all connected blocks.

I would rather not separate all my machines by empty spaces, and in the case of RotaryCraft that is not even possible. So I would like a way to selectively disconnect blocks from my computer even though they are chain-connected (is there a better name for this?) to the computer, cable, adapter, etc.

Possible Solutions:

1. Create a setting in the config to not "auto-discover" blocks. In this mode, the computer would only see blocks directly adjacent to the computer, connected by cable, or directly adjacent to an adapter. If this setting is off, the current mode of finding all blocks that support OC and attaching them as components. This would also require that Cables can have their connecting faces disabled, which I think I saw was supported.
2. Create a card that is inserted in the computer that causes the behavior described above. As I see the auto-discovery as a feature, I would make the default state of the computer to NOT discover/follow blocks, and the card would allow that capability, but I know that may break many people's constructions. A card that disabled auto-follow would be better than a system-wide setting.
3. Change the default component limits for the computers. I realize I can do this today in the config, but that un-balanced some setups just to get others to work. In the case of RotaryCraft, connecting to an extractor will attach 3 additional components and with a chain of 4 extractors (for the 4-stage process), you are looking at 20 components when you really only need to communicate with 4 of them.

In addition to any of those options, I think it would be a good addition to OC to have the faces of adapters get an option to be disabled, so that when I place one down to operate on a machine, I don't automatically link all the other machines adjacent to it.

[gjgfuj]

Yeah, reika has his OC integration overuse everything, and it should really
just be adapter drivers. The issue with "auto discovery" being like that is
that it's completely not how the OC network works. They're all just nodes
and stuff, there's no need to connect anything with cables. And that is
much better than having to run cables everywhere. Yell at @reikakalseki
about this.

[clubpetey]

Well, if the premise of the Components is like USB devices (which is what I read in one of the forums) then no auto-discovery/lots cables makes more sense, each block should have a cable attached to it. to connect it to the computer. Adapters then end up like USB hubs.

Across the various mods I use (Thermal Expansion, Mekanism, EnderIO) they require power/item transfer via cable. The only Mod I can think of that auto-discovers/auto-powers like OC is AE2. But it only auto-discovers it's own blocks, and blocks attached to a specific adapter (ME Interface)

Just my opinion.

[Kubuxu]

@clubpetey Only OC own blocks are suppose to be auto-discovered. All other blocks are supposed to be accessed by adapters. Especially when this block has nothing to do with OC in general. This is Reika who made his blocks work like internal OC blocks and this is root of an issue.

There are drivers for most of things in MC, power, tanks and so on but there is no issue as they do not autoconnect.

[clubpetey]

Ah, gotcha. In that case, I will alter my request to just being able to turn off adapter faces, unless there's a way to do that already and I missed it.

[ReikaKalseki]

I do this because connecting everything individually is often impossible.

[gjgfuj]

So.... They can deal with it? That or completely overload every OC computer?

On Fri, 31 Jul 2015 9:48 am Reika [email protected] wrote:

I do this because connecting everything individually is often impossible.

—
Reply to this email directly or view it on GitHub
https://github.com/MightyPirates/OpenComputers/issues/1341#issuecomment-126523078
.

[ReikaKalseki]

When coding I never expected a limit of 64 components to be the highest obtainable, a value I find to be very very low for many RC/ReC applications.

[gjgfuj]

What.... If the component limit is not enough, you're supposed to network
computers. How do you expect to do that if all the networks are connected.
Adapters are cheap and not hard to use. It's literally one side. If one
side isn't available, how do you expect anyone to use it.

On Fri, 31 Jul 2015 2:25 pm Reika [email protected] wrote:

When coding I never expected a limit of 64 components to be the highest
obtainable, a value I find to be very very low for many RC/ReC applications.

—
Reply to this email directly or view it on GitHub
https://github.com/MightyPirates/OpenComputers/issues/1341#issuecomment-126562901
.

[Vexatos]

@ReikaKalseki Just make a Driver instead of implementing Environment. See aidancbrady/Mekanism#2826 for a more in-depth explanation on how and why to do it.

[clubpetey]

I understand @ReikaKalseki point. Several of his machines consume all sides. The multi-directional clutch when fully used will consume all 6 sides with connections, which I do quite frequently.

Gasoline Engines need control unit below, power out the front, water from one side, ethanol from another, and gas additives from another side have most of their sides used as well (tho EnderIO can help this a bit)

There was another issue posted here that suggested that maybe the component limit described attached components, not total components. In this model all component IDs and types would be placed in an array, but you would have to "activate" the component to interact with it, and you could only have so many active components at a time. Inactive components would not have their API available, so it shouldn't place too big of a load on the system as a whole.

In fact, thinking of the cuff, you could use RAM as the gating factor rather than component connections. Each active component takes a fair amount of RAM to load its driver and instance. Thus the user has to factor a trade off between accessing more components and running larger programs, or increasing RAM.

Note that my whole point may be moot, because the impetus of this issue was trying to get the intermediate products out of an Extractor, I ran some tests with Robots and it seems that even if I can access the extractor, I can see the inventory slots holding the intermediate product, but cannot suck it into the robot. This may be by design, and I'll follow up with Reika on that.

Still, I think the idea of selecting with Components are active is pretty cool.

[ReikaKalseki]

Correct, automation cannot remove intermediate products.

[ReikaKalseki]

Also, this "as cable" feature is both popular and in many cases necessary, and I have no desire to remove it.

[payonel]

i've given this some thought, as our component network issues do cause extra complexity and integration restrictions in some cases

1. as for a config or card to disable auto-connects. it simply cannot work this way reliably. networks are singular groups of nodes, not a mesh of nodes. new network connections get added in whole, and the order the connections are made at random. thus, if one machine is restricting connections because of component limits, it could interfere with another computer that would otherwise not reach that limit.
2. the config options are good where they are and what they provide.

[ReikaKalseki]

Also, a lot has changed since the summer of 2015. Notably, RC/OC compat has been reworked several times.