[2.0.12] Unexpected orbital logistics behaviour

[Belaith]

I have a small starter platform in orbit around Nauvis.
I wanted to send the overflow of iron plates down to Nauvis but wanted to keep a buffer on the platform.
I set the cargo landing pad up like this:

10-28-2024, 22-47-08.png (153.75 KiB) Viewed 352 times

And the space platform hub like this:

10-28-2024, 22-47-14.png (403.68 KiB) Viewed 352 times

I thought that the request on the space platform would act as a kind of "reservation" - keeping 90 iron plates on the platform and having the remaining plates available to fulfill requests from the cargo landing pad.
But as long as the request in the platform exists no plates are shipped.

In the first screenshot you can see "satisfaction 0/200" and "logistic storage 290", that doesn't make sense.


I could set the request-max on the platform to 90 - but then all plates above 90 would get send down, no matter the request on the landing pad.
Or i could remove the request on the platform - then the request from the landing pad would get fulfilled without keeping a buffer on the platform.
Both options wouldn't achieve my goal of having a buffer on the platform and sending the remaining down, but only if there is a request.

[Belaith]

The thread got moved to "Gameplay Help", but this is wrong.
This is about a bug:

Setting a request on the platform blocks requests on the landing pad (for the same resource) from being fulfilled.

[ezylot]

But is there a way we can create the desired behavior of OP? This would be quite useful

[DragoonGXG]

The thread got moved to "Gameplay Help", but this is wrong.
This is about a bug:

Setting a request on the platform blocks requests on the landing pad (for the same resource) from being fulfilled.

That ISN'T a bug. That's how the logic system works. This would be more of a feature request.
To your original post if I'm understanding it correctly, what you have done is essentially tell the platform to send iron requested by the planet until satisfied and THEN if the space platform is low on iron to send it back up via rocket.

[Belaith]

The thread got moved to "Gameplay Help", but this is wrong.
This is about a bug:

Setting a request on the platform blocks requests on the landing pad (for the same resource) from being fulfilled.

That ISN'T a bug. That's how the logic system works. This would be more of a feature request.
To your original post if I'm understanding it correctly, what you have done is essentially tell the platform to send iron requested by the planet until satisfied and THEN if the space platform is low on iron to send it back up via rocket.

The System isn't working as configured, so it's a bug. Simple as that. Either the bug is that it doesn't work like it's configured or the bug is that i can configure it in such a way. Either way: it's a bug.

What you describe is part of whats configured, yes.
We basically have a resource and two requests for the resource.
Logically the request from the place where resource is right now would reduce the available resource and the remaining resource is then available to satisfy the second request.
But what is happening is: nothing. No "send iron requested by the planet until satisfied and THEN if the space platform is low on iron to send it back up via rocket", nothing.
A Request over 1 iron plate on the platform blocks the request for iron plates from the planet completely.

[EustaceCS]

The System isn't working as configured, so it's a bug.

Let's pretend that it's usual logi bot network.
You have two modded logi chests which can have items requested to and dispatched from.
One requests 90 iron plates, another requests 200 iron plates. Both are empty.
Somewhere, a logi bot with, say, 15 plates on board appears in this logi network.
The question is, how much time of useless logi bots flying to and fro it will take to understand that it is not supposed to work this way?

Chests are not an option for buffering on platforms.
So you have to resort to either belt buffering or circuit network based interrupts.

This is about a bug:

Setting a request on the platform blocks requests on the landing pad (for the same resource) from being fulfilled.

This "bug" is a side effect of this (currently undocumented - but explained and thanks goodness) feature: viewtopic.php?p=625983#p625983

Automatic requests work only if you have enough stuff in logistic storage and a full rocket of each requested item type is sent individually. Not a bug.

90 plates is not a full rocket of plates, so a request will never be created nor attempted to be fulfilled. Be thankful that it does not destroy your preconfigured requests either.
If you'll set it to 100 plates, you'll PROBABLY witness a thing described here: viewtopic.php?p=624658#p624658

That ISN'T a bug. That's how the logic system works. This would be more of a feature request.

To make a feature request, it is necessary to understand how currently the system works.
Can't tell for you or OP, but for me "understanding how currently the system works" is a problem so big so I'm postponing my space voyages until this settles.

[Belaith]

Let's pretend that it's usual logi bot network.
You have two modded logi chests which can have items requested to and dispatched from.
One requests 90 iron plates, another requests 200 iron plates. Both are empty.
Somewhere, a logi bot with, say, 15 plates on board appears in this logi network.
The question is, how much time of useless logi bots flying to and fro it will take to understand that it is not supposed to work this way?

If we had had chests that could request from each other i would expect the same behavior i expect between platform and planet.
Lets take your example:
Chest X requests 90 plates and starts with 0
Chest Y requests 200 iron plates and starts with 0

Scenario A: 15 plates are introduced to the system.
Both chests get filled according to the existing logic for fulfilling requests.
Each chests gets between 0 and 15 plates, both chests are below their requests, nothing more happens.

Scenario b:
200plates are introduced to the system.
Both chests get filled according to the existing logic for fulfilling requests.
Chest X gets a maximum of 90 plates
Chest Y gets a minimum of 110 plates

scenario c:
Chest X starts with 200 plates
Chest Y starts with zero plates
90 plates remain in chest X (= Request of chest X)
110 plates get transported from Chest X to Chest Y

scenario D:
Chest X starts with 400 plates
Chest Y starts with zero plates
200 plates remain in chest X
200 plates get transported from Chest X to Chest Y (= Request of chest Y)

There is no "useless logi bots flying to and fro", if you simply prioritize the status quo.
Meaning: if it's already in the chest and its at or below the request of the chest: don't fly it somewhere else.

This is about a bug:

Setting a request on the platform blocks requests on the landing pad (for the same resource) from being fulfilled.

This "bug" is a side effect of this (currently undocumented - but explained and thanks goodness) feature: viewtopic.php?p=625983#p625983

Automatic requests work only if you have enough stuff in logistic storage and a full rocket of each requested item type is sent individually. Not a bug.

This is pretty bad behavior and more so since it's undocumented (ingame), but it affects the rockets going up, not down. Going down there is no "waiting for a full stack / full rocket". So to be honest i don't see where this should be connected.

90 plates is not a full rocket of plates, so a request will never be created nor attempted to be fulfilled. Be thankful that it does not destroy your preconfigured requests either.
If you'll set it to 100 plates, you'll PROBABLY witness a thing described here: viewtopic.php?p=624658#p624658

That ISN'T a bug. That's how the logic system works. This would be more of a feature request.

To make a feature request, it is necessary to understand how currently the system works.
Can't tell for you or OP, but for me "understanding how currently the system works" is a problem so big so I'm postponing my space voyages until this settles.

A request never being created is alright, that request only serves to reserve the items.
But the problem wouldn't change if i multiplied the requests by 100.
It still wouldn't send anything down. I would not "probably" see the items instantly send back down, because, and that is exactly the point: items in this constellation are never send down...

And if something doesn't work like the ui suggest it would: yeah, that's a bug. Either in the ui for misrepresenting the logic, or in the logic for not working like the ui suggests.

I for sure doesn't understand the system completely, but i understand it enough to see that it's inconsistent.
It was probably a mistake to only have one building on the space platform for up and down logistics.
Should have been two different buildings like provider & requester chest.

[Genhis]

But as long as the request in the platform exists no plates are shipped.
...
I could set the request-max on the platform to 90 - but then all plates above 90 would get send down, no matter the request on the landing pad.
Or i could remove the request on the platform - then the request from the landing pad would get fulfilled without keeping a buffer on the platform.
Both options wouldn't achieve my goal of having a buffer on the platform and sending the remaining down, but only if there is a request.

All you say here is correct and this is how it works at the moment. Having an item request prevents the landing pad from taking that item from the platform. You could make a feature request in Ideas and Suggestions.