[2.1] certain Space Platform Requests should not dump to Planet.

[danischu]

edit: current alternative proposals for fixing the described problem

1. Fulfilled minimum request on space platforms should not prohibit the export of excess
   material to other platforms or planetary hub if they request them. [credit: pepnou]
2. Use items in Space Station Trash slots to fulfill logistic requests first before dumping
   the not requested amount to the planet. [credit: Nidan]
   (analougus to logistic bots preferring blue and green to yellow chests when trashing items)

TL;DR

When a space platform request only requests items from other platforms (not planet and not all) AND has a maximum (< inf) set it currently dumps cargo to planetary hub when i think it should not.

The Topic is linked to this suggestion viewtopic.php?t=134822 as it tries to address similar issues but with a different or additional fix.

How i arrived here

I tried a simple thing: Send items by request from a Space Station to the Planet, but keep a minimum number on Station.

Example: First space station that constructs science, should supply Planetary Base with overflowing Iron but keep a reserve for continued production.
The implementation of that idea has several issues. Even in [2.0] i can either:

1. Set a space station request for Iron, but also limiting it.

   

   grafik.png (23.88 KiB) Viewed 740 times

   • I now cannot enable automatic rocket requests, because it may waste Rockets on Iron. Can be mitigated by setting min amount to 0.
   • I cannot limit Iron supply on Planet, in worst case resulting in Landingpad-Overflow
2. Set a request for iron on landing pad
   • Now i cannot guarantee space production as it may use all iron to fulfull the request
   • I cannot coordinate different space station logistic hubs with that

Using solution 1 and 2 simultaneusly has no benefit and compounds drawbacks.

Now with [2.1] arrived inter-space-platform-requests and i'm excited for a new idea:
I'll use a buffer platform like mentioned in the semi-recent FFF https://factorio.com/blog/post/fff-441

• Buffer platforms in orbit for quicker transport turn around.
• Orbital assembling of space materials (such as Space platform foundation) to save on surface rockets.

I set up everything like i imagine it should work and it does not:

1. Landing pad requests items.
2. Buffer station requests min X [no max set] of items only from other platforms. Inserters voids items to space if item_amount > X+threshold. (I would like it to enable supply of other stations for it to be also a space supply buffer, but do not as of now for simplicity)
3. Any other platform or Ship in Orbit that want's to make use of the buffer is set to request the amount of item it wants to keep as min amount from other platforms and sets the max amount upon which it dumps items to other places in the same slider. They set no planetary request for those items. They enable supply of other stations.

grafik.png (428.7 KiB) Viewed 740 times

What i would like to happen: Any station configured to use the buffer for a certain item will keep a number of itmes [min < cargo < max] of the request set. And if the cargo exceeds max amount it should send a cargo pod with those items to the buffer station. If the landing pad has cargo < requested then the buffer station should send it's cargo down and the non-buffer stations should ignore that request if they have < min amount of requested items in their cargo bays. In other words: the condition [item in cargo < min amount requested from stations] should prevent items to be dropped to planet.

What happens instead: Any other platform that overshoots it's target just dumps it's items directly into the planetary landing pad. This is frustrating because they completely circumvent the buffer station. And will still overflow the landing pad. That will happen even if the landing pad has no request set, or if the request is set to max=0 which will dump the items into it's trash-slots.
At least i can confirm that the Buffer station will adhere to landing pad requests, even if it has that request set from other stations on itself and it's minimum requirement are not yet met. I think this works as intended, or how i think it should. [edit: after closer examination, this is not how it should work actually. As described it's exactly what i want to prevent in the other stations. With my idea the buffer station would not have a minimum number of items needed for it's purpose (buffering). It then could've been configured to request min=0, max = inf from ALL (not just platforms) and inserters start voiding at threshold for each item type to be buffered. It should then be able to also drop to planet on request.]

Current solution rant or Why this is important

The standard community (i asked in discord) solution seems to be "just use [2.0] method 1 and dump/void everything". But i would argue that is provably/empiricly wrong.

The logistic problem i describe can appear as soon as the first space platform, long before we unlock the recycler or even Fulgora itself. While space has a voiding mechanic, Nauvis does not. The only reliable way to void overflow iron would be to limit oneself to ore (not plate) requests, detect an overflow, craft ore into plate and send that up to a second space station for voiding. At that point in the game there would be no way to effectively void carbon (if collection rate > burn rate on planet).

The other community answer is "you should not be overflowing iron anyway". And i would argue that assumption of player behaviour is out of place.
If you encounter the setting as early as i described you may soon fly to another planet, and have science stall for hours while exploring other places for the first time.

The last idea would be to try to automate requests with radar networking, memory cells and SR-Latches which would be way above the giving up threshold of your average player and also does not work for it's own reasons, see the linked suggestion in TLDR segment.

What i want to establish in this section: this issue is legitimately encounterable, confusing and has as of yet no viable automationable solutions.

Where do we go from here

I acknowledge that the first naive solution would be to set seperate requests in stations for each item for planetary and space requests.
I tried that and found out that this basicly acts as an "from all" request with maximum values selected both requests min-max sliders.
I will asume that seperation of those request destinies would be technically difficult to implement.

That's why i propose this simpler fix: If a Space Platform has more items of a type than the maximum value of it's request from other stations and no planetary request for that item then exclude the landing pad from the list of valid recipients. I would like to see Stations with any request for that item with < maximum items of that type in cargo to be preferred in dumping cargo. If there are no other stations to dump to then the station should simply NOT send those items anywhere.

[Alfonse215]

I appreciate what you're wanting to do here, but I don't think you're using the right tool for the job.

Essentially, what you want to do is use the hub for local storage, but if there's more than X of an item in the hub, then you want it to be made available to others who want it.

I do not believe that trashing (and requesting, for that matter) is the appropriate way to handle that.

If you trash an item, what you're saying is "get rid of this ASAP." This is not a request; it is an order. It should not be ignored, just as logistic bots cannot ignore when you trash items in your inventory. You're not trashing things to help fulfill the requests of other inventories; you're trashing things to get rid of them.

Having the failure state of trashing (ie: nobody wants it) being that the hub keeps the item is... bad.

[danischu]

I appreciate the insight, so i should clarify.
What you say is absolutely correct, that is why the hub (my buffer station) is using inserters to void items as failure state for this "nobody want's items" case, see picture in original post.

Essentially, what you want to do is use the hub for local storage, but if there's more than X of an item in the hub, then you want it to be made available to others who want it.

That is exactly what i want to be able to implement, and came to the conclusion that this is impossible with the current space logistics. (There is no way to conditionally enable supply of other stations, there is no way to orchestrate demand side requests without invoking planetary logistics)
I did mention this:

I would like it to enable supply of other stations for it to be also a space supply buffer, but do not as of now for simplicity

But that's only my example for how i think the game should behave in the depicted situation.

Having the failure state of trashing (ie: nobody wants it) being that the hub keeps the item is... bad.

I would argue the opposite: this behaviour would be consistent. That's exactly how your players inventory trash slots, or any other trash slots behave if there are no free logistic chests to dump to. It would also be consistent with the UI: there is only one selection for "import from" and this selection should apply to the entire request. The other interesting option would be to have a second selector "Export to" also with [planet | platform | all] options. However that would encroach feature creep territory and be less clear even tough it could arguably be a bit more useful

The current feature is: i can request from stations, but they will be emptied.
The current failure state is: planetary logistics hub overflowing.

This is not a request; it is an order.

I think this description is immaterial, the only difference is direction and guaranteed availability of material vs guaranteed space.
That's exactly where the comparison to the robot network falls apart: Space logistic currently has no buffer chests.
If i trash inventory normally i can have it immediately sorted into requests from blue green (selectively even yellow chests); thus the trash order can come with usage direction.
However that behavior is not present with space logistics: i only get to trash to the planetary logistic hub; basicly a single chest for everything.
From the FFF-blog i figure that buffer stations are indeed intended, but currently for one station to request basic materials to buffer and then sending them to another for a higher priority request is simply not feasable.

My solution solves the core problem with minimally invasive change, while not touching any other scenarios. The only negative could be that non buffer stations trash items into random stations that are not configured to reject the items. It would be an easy problem to solve, and could only occur after explicitly trying to use the feature in a way i described.

@Alfonse215 As you appreciate what i'm wanting to do here, what would be your way of handling the requirement (sending only overflow items). Do you have a current vanilla-SA method for that? If not do you have a different/better proposed change?

[Alfonse215]

There is no way to conditionally enable supply of other stations, there is no way to orchestrate demand side requests without invoking planetary logistics

Of course there is. You just need to use circuit networks and interplanetary communication.

There are two cases here. One is the traditional platform->platform->platform transfers. That's done easily enough by communicating to the hub. The feeding platforms specify which items they're providing and how much of them, but they only send this information to the channel for the hub when they are in the same place as the hub. If the hub needs something, it only requests it when a feeder platform is sending a signal. And it only requests the amount it needs, up to what the feeding platform is providing.

As such, no "planetary logistics" will be invoked, since platforms can always cover them.

The case you talked about, where the platform is producing a thing for internal use *and* for external use is even simpler: if you don't want it send to other platforms, don't put it in the hub. If you need to keep 100 iron ore around for internal use, those ores should go onto belts. The extras can be split off to go to the hub via a prioritized splitter.

That's exactly how your players inventory trash slots, or any other trash slots behave if there are no free logistic chests to dump to.

But there is space to dump to. On the planet. Which is where stuff gets dumped to in space.

Or more to the point: if trashing stuff doesn't go to the planet, how can you send stuff to a planet without a landing pad? Or to send something without making a request for it (a one-time manual delivery)?

My solution solves the core problem with minimally invasive change

I don't call changing a fundamental operation of a space platform's behavior "minimally invasive". Any build which relies on trashing to send stuff to the planet stops working.

Especially now that you need a new UI to send stuff to a planet deliberately without an active request.

[danischu]

Or more to the point: if trashing stuff doesn't go to the planet, how can you send stuff to a planet without a landing pad? Or to send something without making a request for it

Just like before, by setting a max-value in your requests for planetary or all categories.
My proposed change explicitly only limits the dumping to planet when selecting a max value for from platform request.

What you neglect is ease of use. Your explanetion is lacking in detail. "easily enough by communicating to the hub" which hub? planetary, delivering space platform, buffer station? all of them? then you need to orchestrate though global radar, you need a system of message multiplexing, band modulation or usage locking. At least if you possibly want multiple deliveries with multiple stations. That is not "easily enough".

even simpler: if you don't want it send to other platforms, don't put it in the hub.

Now your semanticly circumventing the example i gave in order to not provide a solution for the szenario. Your second case answer boils down to "don't let it come to the situation" which is deeply unhelpful.

But there is space to dump to. On the planet.

Yes but also in the buffer station. That's why there is a buffer station.

Any build which relies on trashing to send stuff to the planet stops working.

I legitimately cannot come up with an idea on why or how to use a space platform from platform request, that then relies on overfilling and dumping to the planet ... i cannot come up with such a thing at all. Not with the current way in which these requests work. ... Did you even read the TL;DR? maybe the topic title was a bit too aggressive.

[Alfonse215]

Just like before, by setting a max-value in your requests for planetary or all categories.
My proposed change explicitly only limits the dumping to planet when selecting a max value for from platform request.

That is now highly bespoke behavior. You want space platforms to have two sets of trash slots when every other logistic requester makes due with one.

What you neglect is ease of use.

Buffer platforms that act as an intermediary between a planet's surface and other platforms are "easy to use". They request from a planet and provide to platforms; there is no conflict. Centralized hub-and-spoke networks that use platform->platform->platform passages are not as easy to use.

I can live with hub-and-spoke networks requiring specialized circuit machinery. It's still very doable to make them; it's just not as simple as setting a few requests.

And I'm honestly surprised that nobody's made a blueprint book for the circuit machinery for it. It's not that hard.

Your explanetion is lacking in detail. "easily enough by communicating to the hub" which hub? planetary, delivering space platform, buffer station?

That's a matter of terminology overloading. You're building a hub-and-spoke model of interplanetary logistics, where each planet feeds a central "hub" platform, and all planets pull from that central "hub". Also, planets don't have a "hub"; they have a "cargo landing pad"

However, to break it down more granularity, it works like this:

There is a central repository platform; let's call it the "repo". For each planet (except for the one the repo is in orbit around), there are some number of platforms that carry exports to the repo and pull imports from the repo to take back to that planet. Let's call them "feeder platforms".

Each feeder platform has a constant combinator containing the things they want to export from their source planet to the repo. Naturally, they request those items from their source planet. But, they take their current inventory, filter it based on the constant combinator, and then send the inventory values for any matching signals through the green wire of a radar using a specific channel. However, that last step (sending the signals out) only happens if the feed platform is currently in orbit around the repo's planet.

The repo station has a constant combinator containing the same logistic group as the feeders. They look at the green wire of that radar channel. When values are on it, it checks to see if its inventory of that item exceeds the amount that it wants to store. If there is a deficit of items, then it sends the full request to the repo's hub. But once the inventory equals the request amount, the request stops being sent to the repo's hub. Any items on the radar which the platform doesn't have a request for in its constant combinator are ignored.

Let's look at an example.

Vulcanus is exporting 500 tungsten plate to the repo. There's a logistic group with 500 tungsten plate on it. The feeder platform uses that group in its internal requests to fetch the plates from Vulcanus (so the requests need to be set to request from Vulcanus). But this logistic group is also used in the constant combinator mentioned above. Therefore, when the Vulcanus feeder arrives at Nauvis (the location of the repo), it sees that it has 500 tungsten plates in inventory. Since tungsten plate is in its constant combinator, the 500 tungsten plates in its inventory are passed to the green wire of the radar (how big the request is is irrelevant; it broadcasts its entire available inventory).

The Nauvis repo sees 500 tungsten plates on the green wire. It wants 500 plates, so it requests that many from "all". This means 300 plates will be brought in. But since the Vulcanus platform is there and has more than 300 plates on it, this request will be fulfilled entirely by the Vulcanus platform. As such, any plates on Nauvis should be untouched.

Once the platform has more than 500 plates, it will detect that its inventory of plates exceeds its desired request amount, so the repo immediately stops requesting any tungsten plates. Since the repo is no longer requesting plates, any platforms who are making requests for tungsten plates from Nauvis platforms will be able to get them from the repo (or from the Vulcanus platform if it's still there, which is also fine).

But what happens if the Vulcanus feeder isn't there? Well, there are 0 tungsten plates on the green wire. Regardless of how many the platform wants, 0 are available, so it requests 0. Therefore, whatever it still has is available to any platform.

[tottoko]

I think the problem lies in the difference between the orbital transport request mechanism and the ground-based logistic network model. The expectation is that other spacecraft will act as buffer chests, intercepting items destined for planets beforehand. Unfortunately, it doesn't work that way.

However, "dumping trash on other platforms" requires determining which platforms are ready to be dumped, similar to "providing materials to other platforms." A separate option needs to be set for it; otherwise, all space platforms will be filled with trash.

But I think this would create complex logic, such as needing to check how many slots each platform has for dumping. You mentioned that the space station shouldn't dump excess items onto planets. According to #411, "No leaving with trash," can the space platform leave the planet in this situation?

Given the current situation, converting the items to be discarded into signals and sending them to other platforms as delivery requests would be more suitable.

[danischu]

Thank you Alfonse215 for going into detail that much. I now understand exactly how the system you would want me to use works.
However this is a description of how you think people should play, given the current mechanics.
While i wanted a discussion on a change to those mechanics i thought might be useful to enable better and differentiated behaviour.

I even agree, that what you describe is the best approximation to a solution that's currently available. I just find it lacking.

You keep suggesting a solution for a problem i don't have: A Centralised Hub that redistributes Planetary Rockets to other space stations.
While disregarding the need for a solution to the problem i proposed a fix to: Not beeing able to limit demands supply side.

I don't think i am in the position to dictate how players should act, instead i would want to enable the wides set of possible playstyles.

You're building a hub-and-spoke model of interplanetary logistics, where each planet feeds a central "hub" platform

No that's what you describte, not what i'm building. I just want a reliable way to to limit the export of a platform. And came up with a concept.

In your model: What happens when there is no 1:1 relation between platforms? Let's say i have 1 Asteroid Collecting Station and 1 Space Science Station, both with 500 Iron Ore in inventory and one Central Hub that would like to request Iron Ore. Let's say i want to keep 200 Iron Ore at the Science Station, then the Hub will read 800 available Ore and request that. Now there is absolutely no way to restrict the Science Station from loosing all of it's Ore, which it needs.

That's why i would need for a system like you describe to work for my only requirement a clock cycling through all available stations. Each station would need to always request at least 1 for each item in it's inventory to block it from sending that away, Then lift requests selectively to enable them to send items.
But it get's worse, because a system like you describe also uses Spaceship-Platforms, that can arrive in Orbit or in that radar group (enabling connections to radar by reading planet location). Now you need 1 radar per orbit you travel to per ship, and orchestrate them AND you need a handshake protocal to get the new ship into your signal cycle. This is slow and unreliable, i.e. what happens if by chance 2 ships arrive at the same orbit at the same tick, breaking the handshake? etc.

Alternatively you would need 2 radars for each connection so that every transport can be parallely coordinated then the amount of radas and logic you would need scales squarly with the size of your fleet. AND it still would not be able to resolve conflicts! (multiple connections supplying the same item)

That is precisely why i would like to use the trash mechanic instead of requests. The difference is beeing able to coordinate where items come from and precisely how many. Rember: i don't suggest all trash should go to other stations, ONLY trash that's discarded specificly via a "from platform" request. Whith my proposes change there would then be a new cost to that interaction: you'd not necessarily know which of the station that's configures to take the trash actually would. And i think if you want to use a mechanic like i envision, that's perfectly ok.

[danischu]

Thanks tottoko, what you point out didn't even cross my mind. Ships with trash in their slots cannot leave orbit.
I think that is an acceptable downside of using the mechanic. Just like with the Robot-Network you would need to make sure there is enough inventory available.
And then again, a player might choose to add a request via circuitry, overriding the "just platform" requirement to dump to planet immediately for an instant departure.

otherwise, all space platforms will be filled with trash.

That is the tradeoff i was going to accept. I mentioned this here:

I would like to see Stations with any request for that item with < maximum items of that type in cargo to be preferred in dumping cargo.

Now your comment actually got me thinking, and understanding why Alfonse215 is so adamant my suggestion would be bad.
Yes trash slots don't store a direction. Thus he must think that all items beeing trashed must not go to planet to ensure my requirements.
But item type+quality is unique per request, so a trashed stack can check on disposal if it's currently only trashed to platforms. No second Trash inventory needed at all. The logic would need to plug in to the orbital logistic listeners to update on changed platforms in network or on changed request.

[pepnou]

I really want to like this idea.
I feel that the introduction of platform to platform logistic was something that wasn't well thougth and is more of a tack on addon.

I somewhat agree with Alphonse215 on the use of the wrong tool here, and i'm not sure the trash slots should be used to control what to export.

If i understood correctly, you want to have the capability to expose what you want to export, in order to be able to keep a minimum amount of an item.
As already said, it's not completely impossible, at least it depend on the configuration.
You can expose the platform inventory with radars to then create appropriate requests.
You can also block the export of an item by creating a request for this item.

But what do you do when you have multiple feeder platforms for the same item ? The transfer is too fast, and depend on the number of cargo bays.
If you use 2 (or more) feeder platform with multiple cargo bays, is factorio going to fully empty one platform before the other ?
Or what happens if the 2 feeder platforms arrive at different times, or at the same time ?
And no, i'm no going to try to implement a lock system to enable a single platform to export a specific item.
This feels like bad solutions (sorry i just saw the last 2 responses, but it was already written).

The aspect i dislike with your proposal is the reliance on the UI.
You can't set a maximum value when setting a request with signals.

But thinking about it, i'm not sure we need anything new:
Why not just treat the minimum amount of a space platform request as the amount it want to keep in it's inventory ?
A request currently block the export, but i don't know why it should stay that way.
This could be set with signals and might also removes the need for the "import from planet/platform/all" field.

[Alfonse215]

While disregarding the need for a solution to the problem i proposed a fix to: Not beeing able to limit demands supply side.

The thing is, you have a solution to that. That solution being this: if you don't want other platforms to steal some amount of stuff, don't put it in the hub.

I get that you don't like that solution. You want a solution that allows you to protect stuff that's already in the hub. But you do have a solution to the problem.

Consider your 200 iron ore example. 200 iron ore is less than 10 stacked belts of storage. You probably have 10 belts between the crushers making ore and the furnace stack processing it (or the foundries melting it). Not to mention the belts buffering plates (and pipes of molten metal) between the furnaces/foundries and the assemblers making science. This is a natural buffer that solves your problem in this case.

Which means this particular problem likely is solved just by building it. And if 200 ore isn't enough, add a few more belts.

My overall point is that the problem you cite is not strictly needed; it can be addressed adequately via other means. As such, radically changing how trashing works in order to solve a problem that can be approached a different way is a pretty big ask.

Furthermore, your proposed solution... doesn't actually solve this problem. It doesn't let you keep 200 iron ore on a platform's hub. It inverts the relationship between provider and requester, where the provider demands that some other platform take everything above 200 iron ore.

This is an incredibly indirect way to solve this problem. And it's very unintuitive.

[Alfonse215]

Why not just treat the minimum amount of a space platform request as the amount it want to keep in it's inventory ?
A request currently block the export, but i don't know why it should stay that way.

Because there are a lot of existing platforms that rely on zero-sized requests to prevent other entities from stealing their fuel cells. Changing that without an opt-in mechanism is a pretty big deal.

[pepnou]

My overall point is that the problem you cite is not strictly needed; it can be addressed adequately via other means. As such, radically changing how trashing works in order to solve a problem that can be approached a different way is a pretty big ask.

A lot of things in the game are not "stricktly needed": belts are not needed, 3 furnaces types are not needed.
Do not use your own playstyle to generalize how other should play.
The proposal might not be ideal, but this doesn't make the problem less real.
And again, multiple exemples where provided to explain why your solution does not work with multiple feeder platforms.

Why not just treat the minimum amount of a space platform request as the amount it want to keep in it's inventory ?
A request currently block the export, but i don't know why it should stay that way.

Because there are a lot of existing platforms that rely on zero-sized requests to prevent other entities from stealing their fuel cells. Changing that without an opt-in mechanism is a pretty big deal.

Yes it would be a breaking change.
A breaking change from the EXPERIMENTAL version, how is that a big deal ?
It wouldn't even change anything for "a lot" of player who have a request for cell fuel, which would translate to an amount of cells to keep in the platform inventory.

[danischu]

Actually i REALLY like your idea, pepnou, of fulfilled minimum requests not blocking exports anymore. I did add it to the initial proposal. It's how i intuitively interpreted the UI at first and needed to learn how it works instead. However you understate the importance of the breaking change: It would change the established behaviour of the 2.0 logistics, which is not experimental. If that ever changes it would need to happen now within the experimental period and then carrying over onto stable.

@Alfonse215 you did provide the belt-solution earlier and i ignored it because it is example specific and not generalizable. If i construct a different scenario; let's say a freigher that ships items from vulcanus to fulgora with a stop at nauvis to unload excess items of that type if nauvis requests it, but keeping a minimum request for fulgora. Then your solution would be to unload potentially 1000s of items onto a belt to protect them from beeing stolen with a buffer station request.

[Alfonse215]

Yes it would be a breaking change.
A breaking change from the EXPERIMENTAL version, how is that a big deal ?

2.0 is not experimental; it's been nearly 2 years since its release. People have been zero-sized requests to prevent planets from stealing their fuel cells since the very beginning. 2.1 makes that more likely since platforms themselves can steal them, but it's not like planets didn't steal fuel cells in 2.0.

And it's not just fuel cells. Zero-sized requests are often used to ensure that something gets to its desired destination. Your Aquilo platform needs to take tungsten plate to Aquilo, but it also needs to stop by Nauvis for some UFCs after visiting Vulcanus. It'd be really good if Nauvis didn't steal the tungsten plate for artillery shell production, wouldn't it? So you add a zero-sized request for tungsten plate to Nauvis.

So you can't just go behind everyone's back and break the means people have been relying on to safeguard storage for nearly 2 years. Even if you give them a different means to preserve them, the old method still needs to work.

At the very least, you'd have to special-case the meaning of zero sized requests.

A lot of things in the game are not "stricktly needed": belts are not needed, 3 furnaces types are not needed.
Do not use your own playstyle to generalize how other should play.

It's not "stricktly needed" for space platforms to forbid placing non-logistic chests on them too. I mean, that's ultimately what you want, right: a way to store items (besides belts) that isn't accessible to other platforms. Being able to use non-logistic chests would do that.

But the game doesn't let you because that's part of the design challenge of space platforms. You have exactly one storage item, and that item is ultimately a buffer chest that other things can steal from at any time. This pushes players towards using belts for storage of things. Asteroid chunks can't stack so they take up lots of room in the hub, but they take up far less room on a belt. So if you want to buffer a number of chunks, you generally just leave them on belts.

You can buffer them in the hub; the game won't actually stop you. And before 2.1, there was little reason for a planet to request them, so you could be sure that they'd stay there. But the game is clearly pushing you towards using belts to store them.

But it's not like belt storage is some weird "playstyle" in Factorio. You have almost certainly done it yourself in a Kovarex build. How do you prevent the logistics network from stealing all the U-235 that you need to keep Kovarex running? You only put the excess in a logistic chest. Using a belt with a prioritized splitter is an extremely common way to handle Kovarex; that belt is your "safe from the logistic network" buffer.

So let's not pretend that belt storage is some strange quirky "playstyle" instead of being a basic tool that most players have used at one point or another. Especially in an environment where the design is pushing players towards using belts as storage devices.

[Almalexia]

Being able to set the possible destinations (blacklist or whitelist or even circuit conditions) for trash categories would fix this

[danischu]

Thanks Almalexia, i like your idea but it depends on implementation. I could image a 3 directional toggle (like splitter toggle [left - eq - right]) trash to [planet - both - station] on each space station, affecting ALL trash categories, even beeing able to control that on a circuit. Or that same toggle on each request category but not beeing able to control that with circuits.

I agree that this would enable the functionality i would like to see without breaking things.
The downside with this is yet another toggle and even more complex design, which is not neccessarily the best thing ever.

So let's not pretend that belt storage is some strange quirky "playstyle"

Now you're just patronizing how to play. You completely disregard the example i provided when i argued, that belt storage can be impractical. It's just to use your words the wrong tool for the job.

[Nidan]

My 2 cents: If there are items in the trash slots, they need to go away ASAP. But I don't see anything wrong with using them to fulfill requests, before dumping any remainder into the big storage chest called planet.

For configuring a hub to act like e.g. a buffer chest, introducing a drop-down like the one infinity chests have sounds like the better option to me.

[tottoko]

Thanks tottoko, what you point out didn't even cross my mind. Ships with trash in their slots cannot leave orbit.
I think that is an acceptable downside of using the mechanic. Just like with the Robot-Network you would need to make sure there is enough inventory available.
And then again, a player might choose to add a request via circuitry, overriding the "just platform" requirement to dump to planet immediately for an instant departure.

I think by then, a lot of people will complain about why the platform won't leave the planet.

Now your comment actually got me thinking, and understanding why Alfonse215 is so adamant my suggestion would be bad.
Yes trash slots don't store a direction. Thus he must think that all items beeing trashed must not go to planet to ensure my requirements.
But item type+quality is unique per request, so a trashed stack can check on disposal if it's currently only trashed to platforms. No second Trash inventory needed at all. The logic would need to plug in to the orbital logistic listeners to update on changed platforms in network or on changed request.

Multiple quality levels can be set for discarding items of different qualities. For example, setting a quality greater than "normal" will discard items that are not "normal."

The reason a second junk inventory is needed is that the junk inventory itself doesn't carry destination information when discarding items. Currently, the discarding method simply adds the item to the junk inventory. Therefore, under the existing mechanism, unless a new inventory is added to dump junk onto the platform, the entire mechanism must be rewritten. Furthermore, the current recycling bin is exactly the size of a rocket, making it impossible to cram items with different destinations into it.

My idea is simple: your goal is more like "exporting" surplus items than "discarding" them. As I mentioned earlier, when discarding items on the ground, they are prioritized for placement in need. Space transport, however, is different; it only drops items onto planets.

However, you overlooked one point: "discarding" means that you don't care about it and can't control where it goes, and the same applies to the ground.

[Alfonse215]

@Alfonse215 you did provide the belt-solution earlier and i ignored it because it is example specific and not generalizable. If i construct a different scenario; let's say a freigher that ships items from vulcanus to fulgora with a stop at nauvis to unload excess items of that type if nauvis requests it, but keeping a minimum request for fulgora. Then your solution would be to unload potentially 1000s of items onto a belt to protect them from beeing stolen with a buffer station request.

You're looking at it from the perspective of hypothetical pieces that can be used to build something. I'm looking at it from the perspective of what pieces we need to have to solving logistics problems.

To me, the problem is not whether a platform can incidentally deliver tungsten to Nauvis but primarily to Fulgora. The problem is how to effectively feed both Nauvis and Fulgora the tungsten they need. Can incidental transfer of the type you describe do that? Sure, but there are many other ways to do that which don't require incidental transfers. If the problem can be solved in a multitude of different ways that can suite a variety of playstyles (and it can)... what's wrong with this one not being available?

With 2.1 opening up so many new ways of doing interplanetary logistics (from hub-and-spoke designs to platforms-as-logistic-bot designs, etc), why is this particular method of delivering items so important to have that it's worth redesigning what logistic requests mean?

Thanks Almalexia, i like your idea but it depends on implementation. I could image a 3 directional toggle (like splitter toggle [left - eq - right]) trash to [planet - both - station] on each space station, affecting ALL trash categories, even beeing able to control that on a circuit. Or that same toggle on each request category but not beeing able to control that with circuits.

I agree that this would enable the functionality i would like to see without breaking things.

How would a platform specify that it wants to receive "trash," and how would it specify that it only wants a certain amount of "trash"? Would this be accessible to the circuit network?

I really think "trash" is the wrong tool for the job. The thing you ultimately want is to say "take no more than this". Using "trash" to say that just feels like the wrong way to say it. It's not that it's impossible to find a way to make it work, but it is attacking the problem from the wrong direction.

You completely disregard the example i provided when i argued, that belt storage can be impractical.

That's because I was writing my response to someone else (and you posted while I was writing it). I generally try to avoid responding to multiple people in the same post; I find that it makes it easier to follow the discussion.