[0.11.11] Default logistic value shouldn't be one stack

[FishSandwich]

The default value of item in the logistic gui is the count of one stack.

Sorry kovarex, I don't think this should be intended behaviour.

I want to request 10 ECs to a requester chest(for example), I click the filter and 200 are requested automatically. Before I can change it, 200 ECs are sent to my requester chest.

There is another slightly more serious example, where I wanted to request 5 alien artifacts for my module 3's, and automatically requested 500 which starved my alien science pack production(and I had to take the 495 back)

[MF-]

Sounds like we need to enable "getting items" no sooner than the count is set and confirmed as well.
Any default count would lead to reqesting too much in the beginning except 0 or 1, which would be useless in most of the applications of course.

[kovarex]

Sounds like we need to enable "getting items" no sooner than the count is set and confirmed as well.
Any default count would lead to reqesting too much in the beginning except 0 or 1, which would be useless in most of the applications of course.

What about having the default value as property of the item. By default it would be one item stack, but it can be specified to be different.
So for the more precious things, like modules or alien artifacts, the default would be just few.

The problem is, that for the common use for player logistics or common items, I personally love that it is set to one stack.

[psihius]

Sounds like we need to enable "getting items" no sooner than the count is set and confirmed as well.
Any default count would lead to reqesting too much in the beginning except 0 or 1, which would be useless in most of the applications of course.

What about having the default value as property of the item. By default it would be one item stack, but it can be specified to be different.
So for the more precious things, like modules or alien artifacts, the default would be just few.

The problem is, that for the common use for player logistics or common items, I personally love that it is set to one stack.

For the common items like plates and stuff one stack is a good default option, no swet here.
But I think there has to be a way to edit the value before robots bring it to you.

And the second gripe I have - I had a slot with 500 iron plates, then I removed it, after a while I add it again and it was adding the same 500 before last update - a very handly trick. Now it defaults to stack size by changing the value (I see it being at 500 first and then changing to 100)

[kovarex]

I changed the default request value for modules and alien artifact to 10.

The rest is left as one stack.

[Marconos]

I guess I don't understand why you are forcing us to take X number of items, or is this just the starting value and we can't change things because the edit window is messed up.

If I only want 25 inserters kept on me why can't I set it to just 25? This is common for me. When I'm tearing down / setting up new production areas I don't want to have multiple stacks and it's not uncommon to tear up 10 + inserters. If I request a stack then my inventory just gets full quicker.

I just want to make sure that we as the player can put in whatever value we want and you are just starting the value at one stack.

[kovarex]

I guess I don't understand why you are forcing us to take X number of items, or is this just the starting value and we can't change things because the edit window is messed up.

If I only want 25 inserters kept on me why can't I set it to just 25? This is common for me. When I'm tearing down / setting up new production areas I don't want to have multiple stacks and it's not uncommon to tear up 10 + inserters. If I request a stack then my inventory just gets full quicker.

I just want to make sure that we as the player can put in whatever value we want and you are just starting the value at one stack.

Well, you an set it to any value ofcourse, this is just about the default starting value.

[silenced]

To make everyone happy you should set the default to 0, and whenever you add an item to the box it should automatically move the cursor to the 'set amount' field where you then can enter your number requested. Be it via slider or numpad for example.

This would not cause any trouble with anyone, I'm pretty sure.

[LordFedora]

Number one rule of working on a codebase when people are using it

http://xkcd.com/1172/

[Martc]

Yes there is no good default value for everyone.
It is possible to add some delay? So robots will wait some time (5-10 sec) and after that starts filling chest (player) with stuff. So you have time to change default value before robots start delivering stuff.

Or another solution, wait until gui is closed and after that changes takes effect. But in this case, player can be confused and wait for stuff with gui open

[Weresmilodon]

Well, since we're throwing out suggestions about it, how about a nice button to press, preferably with a shortcut key.

You put the chest down, chose item, default amount, press button or key.
You put the chest down, chose item, change amount, press button or key.

The robots don't start moving stuff until after you press the button or key. There, problem solved.

[Tami]

A defaultvalue of 0 would be best for certain reasons.

An uncommong example: You have a requester reqesting 10 different items by 1. The Inserter next to it drop all items to a belt.
Now you have and you have a belt with 10 different items as intented.

But now there comes a crazy bot with 100 of a kind to spam you. The result is, you have 100 of a kind of the same belt and the full layout gets broken.
Especially if you have an allready functional layout with 10 items and you want to add an 11th item for a request of 1 and again the crazy bots come again with 100 items.

[n9103]

I think waiting for the GUI to be closed is probably the only solution that involves non-0 defaults (which I support. PITA to set all the requests to one stack manually,) and doesn't overly burden those that don't want a full stack.
Best way to note this change might be to add a small section of text under the logistic slots that states "Close GUI/Inventory to commit changes" or something of the sort.
Not overly obtrusive, shouldn't be hard to program, and would be a good precedent for other short helper text blurbs (which are definitely needed for newer players).

[ssilk]

It is possible to add some delay? So robots will wait some time (5-10 sec) and after that starts filling chest (player) with stuff. So you have time to change default value before robots start delivering stuff.

Or another solution, wait until gui is closed and after that changes takes effect. But in this case, player can be confused and wait for stuff with gui open

That is my opinion.

Change takes effect, when
a) GUI closed or
b) after some seconds, when the slider/input isn't changed anymore.

In the case of b), the GUI displays the player, that this takes now effect (different color, green lamp in the icon, just something simple).

[UntouchedWagons]

Yes there is no good default value for everyone.

Sure there is: 1. There's no need for an overly complex solution when a equally effective, but far simpler one, is staring you right in the face like a hungry cat. There's also no need to fix something that wasn't broken.

[SHiRKiT]

I still think that none (which will translate to 0 if unspecified) should be the default option, and the cursor should be moved to the textbox to type the amount.

[Nemoricus]

The default should be a full stack (with some exceptions), because that's likely to be the most common use case. However, the game should give you a chance to adjust the values before it starts requesting items. Just having a confirmation prompt would be enough.

[n9103]

It would seem, due to a large division in community interest, that there should be an option setting to default to a full stack, one, or none. And/or an option to start retrieval immediately.

[ofca]

So what's exactly wrong with "apply" and "are you sure you want to discard the changes you've made?" when attempting to close a window with unapplied changes? Microsoft figured it out years ago

The problem itself did bother me to some degree, too

[kovarex]

So what's exactly wrong with "apply" and "are you sure you want to discard the changes you've made?" when attempting to close a window with unapplied changes? Microsoft figured it out years ago

The problem itself did bother me to some degree, too

The problem with that is, that it adds a condition that you have to close the window to apply it, or to add additional button to gui that has more than enough slots and buttons already.