Logistic request interface

[Ogro]

Each line would have three buttons: Activate, Deactivate, and Flush.
- An activate line would function like request lines are working right now.
- An deactivate line would function like it did not exist.
- A flush line would behave as a trash line.

The benefit of that implementation would be that we do not have to rebuild our orders each time we need them. Example let us say I make a logistic request line to build mining train station. All railway stuff plus other mine and electric stuff would be on that line. After I finish building my mines, I could simply deactivate the line to stop receiving stuff and keeping the leftover from construction on my inventory, or I could flush and store all the mine construction stuff. Next time I want to build mines I can simply activate the line instead of rebuilding my request orders.

Things to consider:
- Handling conflicts, same item in more than one request and flush lines at the same time. One solution would be to sum all the flush and request quantities, take the difference between them and if positive and greater than zero, request that amount.
- People might also want to reorder lines as they play.

[ptx0]

..

just use autotrash mod?

[ssilk]

I like the simplicity of this suggestion. It really adds gameplay but very little complexity.

Compared to autothrash mod I would prefer this.

[Koub]

The only thing I still would miss if this idea was implemented wouldbe the "extraordinary request for something I already usually request" (which has already been requested in the past as "one-time request").

If I reuse the "mining outpost building example", I usually keep 2 stacks of belts for everyday use and get rid of the excess whenever over 4 stacks. The day I want to build an outpost, alongside with mining stuff, I'll want 10 stacks of belts. I would like not to have to break my usual setup to allow myself this one time "give me 10 stacks of belts just for once".

If there was a way to merge both needs into a single interface, it would be neat.

[NotRexButCaesar]

+1

[Ogro]

Greetings Koub!
I agree, and I think my suggestion kind of address that, but the way I proposed handling conflicts was not the best for this scenario.
One thing that perhaps was not clear, is that on this implementation you can request the same item in different lines, instead of getting the message “Request for this item already exists”. Also, instead of just trashing what you have at hand, this implementation has “trash requests” that I called “flush” lines. The way conflicts are managed seems to be the secret for an even better system, so I will make another proposal based on your “extraordinary request” necessity.
Example:
Line 1: Request for 200 belts (that is the player usual setup)
Line 2: Request for 500 belts plus other stuff (that is the mining outpost line example)

What happens when both lines are active? Do you get 700 belts or 500 belts? Based on Koub’s post I think the best implementation would be to request the greater instead of the sum, so in this case the final request would be 500.
Now, the mine building is done. If you deactivate Line 2, you simply keep what you have at hand, but if you flush Line 2 what happens? Would you get striped of all belts because of 500 flush order? Or would you keep 200 because of active Line 1? Based on Koub’s post I think the best implementation would be to flush excess until the next greater request, so in this case belts would be trashed until 200 remained.

Another thing that was not clear, but I think it is important to keep logical behavior, is that a flushing line would automatically switch to deactivated after its items were trashed to the greatest current request.
I just realized, based on the mention of auto trash mode, that some players might not like this behavior because they would like constant auto trash behavior. So, to address this, a check box could be added to the interface: “Auto trash/flush everything until greatest request is met”. That check box would allow players to have a usual setup line that would constantly be kept as the only stuff in inventory.

[ssilk]

I agree, and I think my suggestion kind of address that, but the way I proposed handling conflicts was not the best for this scenario.

I think that’s clear. But what this introduces is handling of quite common situations.

What I recommend here is to create more suggestions that try to solve the pointed out issues, while keeping the pointed out advantages.