Modify platform transfers to mimic bot network

[pepnou]

TL;DR

Introduce a system of provider / buffer / requester platform storages to simplify and empower the automation possibilities.

Why?

I'll start with "why" or this feels weird.

The introduction of platform to platform transfers adds many new possibilities to the game that i was interested in, the main one being a planetary hub: a platform that links the planet surface to the other platforms. It stocks up on ressources to transfer to outgoing platforms in order to avoid rocket congestion. It craft ammo and necessities with asteroids gathered by other platforms. etc.

I have encountered 2 problems with this:
- you cant use the same logistic group to specify requests from surface to the PH (planetary hub) and from PH to other platform. This is due to the inability to send a ressource when there is a request for said ressource. This requires you to have two dupplicated logistics groups, one with import from planet and the other with import from platform.
- you cant select what you want to provide the other platforms with. You want to keep some asteroids to craft fuel ? Too bad! it's all or nothing.

The current system forces the player to interract with the tedious UI to select from where a ressource shoud be requested, and introduces request dupplication to allow platform to platform transfers.

This boils down to 2 things (still about platform transfers):
- The inability to request and provide at the same time.
- The inability to choose what you provide.

Seems somewhat linked to viewtopic.php?p=702865&hilit=transfer#p702865
and to viewtopic.php?t=134822

What?

The bot network already solves all the problems listed above:
- You put item in provider chests to expose what ressources can be send.
- You make requests from requester chests.
- You use buffer chests to create a link between provider and buffer chests.

The same concept could be used for the platform tranfers.
I thought of two ways to implement this (but i'm no game designer):

- By physically moving items to the correct logistic storage.
This could be done by introducing "logistic chutes". This building is 2x2, can only be built adjacent to the space platform hub (see image) and can be interacted with inserters. It comes in three variants: provider, buffer and requester.

factorio-sp-tranfers-buildable-positions.png (1.32 MiB) Viewed 313 times

This does not extend storage space, only acts as a way to "tag" item moving through it:
If you have 30 storage slot on your platform and put a stack of ammo (for example) in the provider chute, you now have 29 available "normal" storage slots and 1 stack of ammo in the provider storage.

factorio-sp-tranfers-logistic-sorage-1.png (104.38 KiB) Viewed 313 times

factorio-sp-tranfers-logistic-sorage-2.png (93.36 KiB) Viewed 313 times

The inserters interraction with the chutes could be restricted. But this might cause storage problems if the player end up stuck with stacks of unwanted items.
- The provider chute can only be inserted into.
- The requester chute can only be extracted from.
- You can two both (or neither ?) with buffer chute.

The interface of buffer and provider chutes should allow to create logistic requests.

Transfers between platforms / planets are done in the exact same way as the logistics bot transfers:
- from provider to buffer / requester
- from buffer to requester
The cargo landing pad is treated the same way as a requester chute.

A different possibility to implement this logistic solution is to rely solely on signals.
In order to separate provider / buffer / requester signals, i though of a new building: the logistic emiter.
Same as the chute: 2x2, adjacent to the space platform hub, 3 variants (provider / buffer / requester). But inserters CANNOT interract with this building, it is only to connect with red / green wires.

The 3 variant of the logistic emiter hace an interface to specify logistic "requests", the only difference between the 3 being that item specified in the provider logistic emiter are item to export.
These requests can be set manualy or with signals.

Same as before, the transfers are done in the same way as logistics bot transfers:
- from platforms with item listed in the provider logistic emiter (and with item in inventory) to platform with item listed in the buffer / requester logistic emiter.
- from platforms with item listed in the buffer logistic emiter (and with item in inventory) to platform with item listed in the requester logistic emiter.


With both solution (logistic chutes or logistic emiters), the checkbox "provide materials to other platforms" can be removed as no longer needed. The source of a ressource (planet / platform / all) can also be removed.

To conclude, this solution helps to clean up the UI and ease platform transfers.

[Alfonse215]

I have encountered 2 problems with this:
- you cant use the same logistic group to specify requests from surface to the PH (planetary hub) and from PH to other platform. This is due to the inability to send a ressource when there is a request for said ressource. This requires you to have two dupplicated logistics groups, one with import from planet and the other with import from platform.
- you cant select what you want to provide the other platforms with. You want to keep some asteroids to craft fuel ? Too bad! it's all or nothing.

Both of these are solveable with circuit controls.

If you want to stop providing a particular item, then send a 1-item request for that something via circuits; that will stop providing it (unfortunately, the circuit network can't send zero-item signals).

I'm not sure when a PH would want to try to import from the planet and other platforms at the same time, but that's the default behavior for all circuit network signals. So just put that group in a constant combinator.

The more general problem with hubs is the inability to provide an item to platforms if you're currently requesting it from platforms. So if the PH needs stuff from feeder platforms, it can't give it to other platforms easily.

This is solveable via circuit networks and radars. And it can be done in a granular, per-item fashion.

The PH gets all of its requests for stuff from platforms from the circuit network. Every platform that's going to provide something will send what it provides to a particular channel. But it only does so when it is at the PH's planet. And it specifically send how many of that item it has available (if you don't want to provide all of it, you can reduce the "available" amount appropriately).

The PH looks at this channel and compares that to its current storage and how much it wants of that item. If it is deficient of any items, and those items are available from nearby platforms, then it requests the difference, up to the availability.

This means the hub will only request what's available from other platforms in the area.

Ultimately, I don't think the devs are going to add a bunch of new buildings with highly specific functionality when you can accomplish the same effect via circuit logic. Not at this stage of development at least.

[pepnou]

If you want to stop providing a particular item, then send a 1-item request for that something via circuits; that will stop providing it (unfortunately, the circuit network can't send zero-item signals).

you're right, I didn't though about that.
I guess i could argue about some things
- you cant keep less stack than the amount off cargo bay, as the transfer is done all a once
- it's a bit counter-intuitive to create such request to block export
- if your platform is filled with random stuff you dont want to export, you have to create the request for all of those item (but again it's doable with circuit)

The more general problem with hubs is the inability to provide an item to platforms if you're currently requesting it from platforms. So if the PH needs stuff from feeder platforms, it can't give it to other platforms easily.

Yup, that's the "request and export at the same time" problem.

Ultimately, I don't think the devs are going to add a bunch of new buildings with highly specific functionality when you can accomplish the same effect via circuit logic. Not at this stage of development at least.

I guess you're right ...
I still feel a bit mad that the logistic bot network capabilities are so powerfull compared to the platform transfers (especially platform to platform).
But one can dream