Smarter auto-trash

[Kyralessa]

I've found that the interplay of request slots and auto-trash slots can be a bit awkward. Say I want to carry 200 and only 200 blue belts. I set my request slot for 200, and I set my auto-trash slot for 200 as well. Then later I change my request slot to 300 blue belts. Now my logistic robots give me an extra 100 belts, which immediately go into my trash slots, whence the robots retrieve them, deliver them to me, and I trash them again...

Obviously at some point I notice what's going on and bump up the auto-trash number.

My request: That the request and auto-trash numbers would take note of each other, so that if you reduce an auto-trash number, the corresponding request number (if any) would be reduced too, and if you increase a request number, the corresponding auto-trash number (again, if any) would be increased as well.

This would still leave you open to have a range, e.g. requesting 200 blue belts and discarding after 300, but it would avoid the weird situation where you're requesting more than your auto-trash limit.

[daniel34]

Related: [0.13.10+] auto trash can be lower than player request slots [Not a bug]

That would be very annoying if you changed the slider for a moment by mistake and it changed your requests which is why it's left as it is and relies on you - the player - to determine what you want done.

You can also setup a requester chest to request more than the chest can hold. You can shoot buildings as robots repair them. It's up to you the player to figure out what you actually want

[ssilk]

I think both (request and trash) should be controlled with the same gui-elements.

And it would make sense, to have similar controls also for requester-chests.

[<NO_NAME>]

It's a common situation for me, that I must order something that I normally have in my autotrash slots.
Setting request, disabling autotrash, wait a little while, deleting request, enabling autotrash - it is so tedious when you do it often.

My proposition is to allow an autotrash condition to be lower than the request but give requests a higher priority.

EDIT: I expressed myself poorly. I explained this better in my post below.

[Kyralessa]

Actually, I'd much prefer that autotrash had a higher priority.

If you've ever made the mistake of deconstructing a storage chest with a personal roboport, then you already know why...

I feel like autotrash should actually have the highest priority, even above personal request slots. After all, trash is how you make room for more requested items. What's the point of autorequesting items if you can't hold them anyway because your trash slots are backed up?

[Factoruser]

The right behaviour would be that if you increase your requests over the trash limit, the trash limit should be automatically increased to the same value, if set. If you set the trash limit below your request amount, the request amount should be set to the same value resp. removed if 0.

[<NO_NAME>]

My proposition is to allow an autotrash condition to be lower than the request but give requests a higher priority.

I feel like autotrash should actually have the highest priority, even above personal request slots. After all, trash is how you make room for more requested items. What's the point of autorequesting items if you can't hold them anyway because your trash slots are backed up?

I was imprecise. (I need to improve my English.) I didn't mean priority but importance.

Example:
- request slot is set to 150 iron plates
- autotrash slot is set to 100 iron plates
For now, robots will give you and take away 50 iron plates in a loop.
My idea is to temporarily interpret autotrash as 150 iron plates but only until request slot is set.

This is about interpreting values, not about changing them so the game has to remember the original setting of autotrash. This is important, because otherwise we could ruin autorash settings by accident while changing requests and vice versa.

[Deadly-Bagel]

My idea is to temporarily interpret autotrash as 150 iron plates but only until request slot is set.

This is about interpreting values, not about changing them so the game has to remember the original setting of autotrash. This is important, because otherwise we could ruin autorash settings by accident while changing requests and vice versa.

Actually this is quite a tidy idea. You don't normally carry miners until you want to build an outpost right? Suddenly you need 200 miners in your inventory, so you request 200, go build the base but find you only used 140. When you get back, rather than having to manually trash the items you can just remove the logistics request for miners and the trash will kick back in and your bots will empty them out.

[micomico]

*****
TL;DR - If the value on the request slots is bigger, use it instead of the value on the auto-trash.
*****

Quoted from this post.

I think the autotrash function should check the current requested values for the items and, if they're bigger than the values set on autotrash, those values should be used instead.

Code: Select all

items_to_trash = autotrash_amount(copper)
if (request_amount(copper) > items_to_trash)
  items_to_trash = request_amount(copper)
if (total_amount(copper) > items_to_trash)
  trash_item(copper,total_amount(copper) - items_to_trash)

This way you can set temporary requests bigger than the ones you usually have, without having to fiddle with the autotrash amounts. When you're finished building whatever, just set the requested values to their normal.

So, setting auto-trash does nothing do the request slots. And setting the request slots doesn't change the auto-trash values as well.

The thing I find annoying is when I want to build something new, I increase the request slots of the required components, but they get sent away by auto-trash. Queue changing or deleting auto-trash slots for the build and recreating them when it's finished. It gets old pretty quickly.