Allow connecting entities directly to LuaCircuitNetwork, LuaLogisticNetwork, electric networks

[tux_mark_5]

Right now the main way to connect an entity to electric/logistic network is to use LuaEntity.connect_neighbour

I propose adding additional methods to LuaEntity or appropriate control behaviors that allow connecting entities directly to specified:

• LuaCircuitNetwork
• LuaLogisticNetwork
• electric network by given electric_network_id

This way entities could be directly connected to given networks while completely ignoring any wiring and positional restrictions.
This would be extremely useful for "wirelessly" transferring signals and power over great distances (or across surfaces) without using on_tick and doing it manually.

Might also make sense to add LuaElectricNetwork for symmetry.

[Rseding91]

That's not how any of the logic works for those things: they're all 3 completely different sets of logic and nothing can ever be "directly connected". They only connect via the specific APIs we expose and internally those APIs use the supported game mechanics (wires for poles/entities).

This isn't so much a "won't implement" but a "It doesn't work that way, can never work that way, and doesn't make any sense". But, we only have "won't implement" so I'm moving it there

[tux_mark_5]

I realize that they are completely different things. I'm probably being not 100% clear in what i mean.

Right now it's possible to connect an entity (say, a decider combinator) to a circuit network by manually connecting it with wire to some existing network.
It is also possible to do that with LuaEntity.connect_neighbour. In both of these cases, wire length restrictions apply.

What i'm suggesting is skipping the "wire that connects an entity to network" part and connect entity without any wire directly to the network, bypassing any wiring restrictions.

Similar idea can be applied to electric network: you can use LuaEntity.connect_neighbour to connect two poles. Connecting them "directly" would mean again, to bypass any wiring restrictions.

As for logistic network: how about an inserter that can connect to logistic network while being physically outside the logistic area. I don't see any reason, why this should be impossible. I'm assuming each inserter when connected to a logistic network stores some logistic network id or pointer to it. All i'm asking is a function/setter that would allow to change that value directly. Thus again, bypassing "physical" limitations of roboport area.

[Rseding91]

You're don't understand how those systems work internally in the C++ logic that is the game.

An entity is part of a circuit network as defined by the wires it's connected to. If you don't have wire connections it's not in any circuit network.

An entity is part of an electric network as defined by the wires it's connected to or the electric pole area it overlaps with. If you don't have wire connections or overlapping electric pole areas it's not in any electric network.

An entity is part of a logistic network as defined by it overlapping with the logistic area of a roboport or personal roboport. If it doesn't overlap with one of those areas it's not in a network.

You can't just "not do" part of how those work. That would be like saying: "I know you need food to survive but just don't eat food and survive anyway". You just can't do it. It's not possible.

[tux_mark_5]

It's entirely possible that I misunderstand some internal details about how this works on C++ side, however, the way I imagine it works (at least regarding electrical network) is this:
1. When player puts down an entity that uses electricity (say, an assembler), the game searches nearby area for overlapping pole supply areas.
2. Each pole for performance reasons has probably a cached electric_network_id.
3. When an overlapping pole is found, I'm assuming that this id is copied to the entity.
4. Each electric network probably has a list of its members. Then the newly detected entity is probably added to that list.
5. I'm guessing that for performance reasons this process is not repeated every tick and that electric_network_id is cached for quite some time.
6. Furthermore, I'm assuming that on each tick only that list is traversed when updating electric network without any regard to pole supply areas, pole positions, etc.

There is probably some edge case logic of when multiple networks are in range of the same entity too.

If that's indeed the case of how it works, then i see no reason why LuaEntity.electric_network_id couldn't be made writable.