TL;DR
Have logistics requests/fulfillment actually pay attention to the radio buttons/planet filters/requested amounts and "do the math", rather than just block any source providing an item to a destination if that source has a second logistics request of that same item. See below for details/screenshots.What?
Let's say you have Ship A delivering a ware to Planet B. If ship A has a logistics request from the original source planet active, it's still able to drop the ware off to detination Planet B, as these two are not mutually exclusive.*HOWEVER*, let's assume now that Ship A has *two* logistics requests for that item being delivered. One is from the original source planet, and the other is from any platform (not planet) at all. This will gridlock and the ship will not "let go" of that item to be delivered to Planet B... even though there is NO request for that item to be taken from Planet B.
Why?
The issue with above (as noted in the bug side of the forum) is that a ship will not deliver *any* ware that has multiple requests for that ware, by design. While this is a simple way of making sure the same ware doesnt just get passed back and forth between source and destination, it's too restrictive and frankly makes space logistics "dumb". I mean that in the literal sense. A "smarter" and more logical space logistics system would take note of the amount requested, the amount in storage and the filter radio buttons on Ship A, and it should make a decision on whether it can supply the ware to Planet B without breaking the logistics requests constraints of Ship A.For example, Ship A has 150 Stack Inserters. 50 of them are requested from *any* source (or even just from platforms only) as a "maintenance" stockpile for the ship in case it gets hit by an asteroid. The remaining 100 are available to be "supplied" to Planet B below, as they have been requested from a different planet exclusively. The Planet B is requesting 100 stack inserters from the ship. The ship should be able to say "that math works" and drop the 100 requested stack inserters, since it doesn't conflict with the maintenance stockpile at all.
Another welcome side effect: This would make "orbital depots" concept more viable... so ships only need to fly by and do transfers with a "station" above the planet rather than sit there and wait for rocket launches below. Then the "orbital depot" restocks after the export ship flies away.
Last note before I post the "not a bug" report below for reference... THANK YOU to you fine folks for making this game. It is an amazing work of art and I would imagine you are crazy proud of what you have created. I hope nothing in the tone of this post suggests I am anything other than VERY GRATEFUL to have this game exist. Cheers!
Here is the "bug report" for reference as I had assumed this was a bug, since it did not act in a logical way to my mind.
TLDR: There are replicable cases where platform-to-platform logistics transfers do NOT take place even though the tooltips, radio buttons, and filters suggest they absolutely should. Specifically, multiple logistics requests for the same item (even if one is from the planet, the other from a platform, or they are otherwise mutually exclusive and shouldn't gridlock) will gridlock.I searched for similar bugs but nothing quite replicates what I'm getting at here. The closest I've seen is the one where construction requests gridlock delivery of items, so the source of the problem might be the same.
See screenshots and save file for an example. In this case, logically, the (Gleba) Exporter should be dropping Stack Inserters to Fulgora. However, it is not, and no reason is given. I've narrowed it down to the fact that ANY second logistics request of the same item from the source (in this case, the Stack Inserter request in the ship's maintenance logistics section) will gridlock the system no matter what. This is especially interesting because the maintenance request is set to ONLY pull from platforms, so sending it down to the planet should be no problem. Likewise, the "main" logistics requests under the ship's "exports" section is set to ONLY pull from platforms as well, so again, sending down to a planet should not cause a gridlock.
- Gleba Exporter (Source).png (1.72 MiB) Viewed 139 times
- Fulgora (Destination).png (3.07 MiB) Viewed 139 times
What did you do?
Set any logistics request for a platform-to-platform or platform-to-planet transfer while also requesting the same item in another logistics spot of the source platform (like for ship maintenance).
What happened?
No transfer takes place/the two platforms are gridlocked, even though there is sufficient quantity in the source to allow transfer without violating the source's own logistics request. It seems that having more than one logistics request of ANY item on a platform makes it unable to transfer the item to another platform. This is VERY similar to the other bug where construction requests block transfers, but slightly different and might rely on a different bug fix.
What did you expect to happen instead? It might be obvious to you, but do it anyway!
I expect the transfer to take place. Based on radio buttons, filters, and tooltips, the source (A) should be able to transfer the item to the destination platform or planet (B) if fulfilling the request does not violate its own requests. See attached save, I have multiple instances where this is not true. The most obvious is the screenshot I provided. The (Gleba) Exporter has enough Stack Inserters in inventory to fulfill the logistics request of Fulgora landing platform without going below the amount in the maintenance section (50)... so the transfer should take place but it doesn't. I'd have to completely delete the separate logistics maintenance request for the transfer to take place.
Does it happen always, once, or sometimes?
*Almost* always. The only logistics requests that will allow a platform-to-platform (A to B) transfer require that the source (A) does not have a logistics request for the same item it is trying to transfer, or that the other transfer MUST be from a single planet no matter what. (B) will never receive the item otherwise.
