Allow non-joining logistic networks

[BicycleEater]

TL;DR

Add some mechanism to mod in a logistic network which can be distinct from the regular logistics network even while overlapping.

What?

I have several ways of implementing this:

• Allow logistics_connection_distance < logistics_radius (in particular logistics_connection_distance=0 and not connecting at all...)

• Add setting to a roboport prototype to not join its network onto others

• Add some kind of collision layering to logistic networks

Note that I want logistics capability within this isolated network, not construction.
I'm only asking this on the basis that it might be easy - I don't know whether it would be or not.

Why?

I'm trying to make a mod for an early-game alternative to drones, with the hopes of removing some of the issues mentioned in https://factorio.com/blog/post/fff-224. The idea is to implement pick-place machines, like those in warehouses. Big singular machines which can (relatively quickly) move items around within their bounds, but not outside. This is workable enough using a (very) weird roboport, but the issue is preventing them from interacting with other logistics drones, so people can use both at the same time.

[curiosity]

Suppose there are two overlapping networks. Which one should process logistic requests?

[BicycleEater]

Suppose there are two overlapping networks. Which one should process logistic requests?

Yeah, that's a big question.
The same can be said about processing construction requests.
If the game engine doesn't support a good answer to that, then I'll take that, no problem - I can find workarounds.
If the game engine handles it the same way it does for construction (where different networks can overlap), then great, maybe?

[Stringweasel]

For now you could try https://mods.factorio.com/mod/LogiNetChannels

[BicycleEater]

For now you could try https://mods.factorio.com/mod/LogiNetChannels

Ok, that's not bad, I'll see if I can use the same approach for my use-case...

[Rseding91]

The game currently does not support the concept of overlapping logistic networks. Entities that register in logistic networks can only be in 1 network at a time so overlapping networks simply are not supported at the engine level.

There's a *ton* of logic that goes into making overlapping construction networks work and it's the primary reason you get slow-to-respond construction robots when there are a ton of jobs to process.

[curiosity]

The game currently does not support the concept of overlapping logistic networks. Entities that register in logistic networks can only be in 1 network at a time so overlapping networks simply are not supported at the engine level.

Oh, so it does actually support it. You just have to let prototypes specify what kind of logistic network they belong to. This kind of overlap seems to fulfill OP's use case.

[BicycleEater]

The game currently does not support the concept of overlapping logistic networks. Entities that register in logistic networks can only be in 1 network at a time so overlapping networks simply are not supported at the engine level.

There's a *ton* of logic that goes into making overlapping construction networks work and it's the primary reason you get slow-to-respond construction robots when there are a ton of jobs to process.

That figures.
I'll look into doing it the forces way, though as curiosity said, the "collision mask" approach would actually solve my issue - just I don't imagine its worth the dev time.

[Qon]

The game currently does not support [...] overlapping logistic networks.
[...] overlapping networks simply are not supported

OH, sO iT DoEs ACtUaLly sUPpOrt It.

You just completely ignored what Rseding91 said. *violent facepalm*

You just have to let prototypes specify what kind of logistic network they belong to.

Then you tell him to add the support to the engine that you first said already exists. WTF.

[curiosity]

The game currently does not support [...] overlapping logistic networks.
[...] overlapping networks simply are not supported

OH, sO iT DoEs ACtUaLly sUPpOrt It.

You just completely ignored what Rseding91 said. *violent facepalm*

You just have to let prototypes specify what kind of logistic network they belong to.

Then you tell him to add the support to the engine that you first said already exists. WTF.

If you are going to ridicule me, at least don't make things up. That way you won't make a fool of yourself.

[Qon]

If you are going to ridicule me, at least don't make things up. That way you won't make a fool of yourself.

The one making a fool out of themselves here is you, not me. You didn't mention what I made up, because there are no examples of it.

[BicycleEater]

If you are going to ridicule me, at least don't make things up. That way you won't make a fool of yourself.

The one making a fool out of themselves here is you, not me. You didn't mention what I made up, because there are no examples of it.

Just to try and, like, help the communication, I think curiosity meant that the issue raised was not crippling for the case I was referring to - the reason Rseding91 gave was applicable for the general case of overlapping logistic networks, but did allow the implementation of a system for entities to chose which logistic network to use in their prototype. This was conveyed with ambiguity, but the "it does actually support it" was intended to mean "it isn't incompatible with the way the system works", and the suggestion for implementation was just how the actual capability could be managed.

Oh, so it does actually support it. You just have to let prototypes specify what kind of logistic network they belong to. This kind of overlap seems to fulfill OP's use case.

I hope this helps things resolve a little more amicably, as there really isn't cause for this to descend into an argument.
Also, I have no problem with the devs not implementing this - I recognise its a pretty niche use, and was only asking in case it was a one-line fix of removing the check.