they dont use closest storage ?

[skeletin]

i had some time to paint it instead writing text, so here is the problem, and its ruining my game   (sorry for my good english by the way)

[bzgzd]

Yes this thing sometimes makes me angry too...

Dupe is not looking for job when picking item (after picking it) at the place where item is.

He was looking for job when he was near your old storage and saw that there is some container near him that has some job for him and so he is "working" for that specific container (not for item or for all containers).

 

[Argelle]

So the only way to fight this, is having sweep only containers AND set the proirity of the containers close to the cleaning to 6 while setting down the others 604 containers to priority 5?

[bzgzd]

8 minutes ago, Argelle said:

So the only way to fight this, is having sweep only containers AND set the proirity of the containers close to the cleaning to 6 while setting down the others 604 containers to priority 5?

You can also use something to make him look for job where you want, like "move to" command.

I made a video about this problem (sorry for my excellent English used in video):

 

[Argelle]

OK 'the move to' order reset the dupe list of chores, so he/she's now close to the bin.

Either solutions are clicks intensive tho.

[AndreyKl]

1 hour ago, bzgzd said:

I made a video about this problem

Thanks, this explains quite a lot of problems I had. Also of note: dupes ignore priority assigned to items they need to sweep and instead act based on priority of the storage (which is stupid and problematic if you need to urgently pick up this specific item)

P.S. A shame we can't at least switch input and output modes for storages, like input: sweep only/no sweep/storage exchange/any/none and output: storage exchange/tasks/none, would go a long way towards better inventory organization. Same should go for prioritis, storing and input priorities should be separate, so that dupes will sweep to specific storage due to high 'sweep only' input priority, then extract en masse to other storage with higher storing priority.

[Lafara]

ain't target storage bin always be LEFT instead of right.

and target storage bin always be TOP instead of bottom.

[Steve8]

18 minutes ago, AndreyKl said:

A shame we can't at least switch input and output modes for storages, like input: sweep only/no sweep/storage exchange/any/none and output: storage exchange/tasks/none, would go a long way towards better inventory organization.

Something like the door interface with the left/right arrows would be very nice. I  wanted that for slime storage just now. Put a storage bin in my mushroom farm and designate it as output only. Then dupes can put still put infected slime to my chlorine room.

[bmilohill]

31 minutes ago, Lafara said:

ain't target storage bin always be LEFT instead of right.

and target storage bin always be TOP instead of bottom.

I do think this is part of it. 

Put another way, its not that the dupe did a digging task, sees a nearby object, and decides to take it to a convenient bin. 
It's that the dupe finished his digging task, moved on to storage tasks. The game scans for the first bin that needs items put in it. That happens to be the one very far away. And luckily, there is a nearby item that can go there, so he picks it up and then makes the journey. 

The main thing is the bin is what the storage task is based on, not the item on the ground. Which is why a high priority bin fixes the issue. 

[KittenIsAGeek]

The dupes prefer "closest" tasks.  Unfortunately, the way storage tasks are assigned means that the dupe gets a storage task to the storage bin that is closest to him, not the closest to where the materials are.

Say that there are two bins, as posted in screenshots above.  One is close to the dupe, the other is closest to the debris.  Both bins have an equal priority, and they both need to be filled.  Since there are debris that can go into both bins, they both generate a supply task.  AFTER this point is where the dupe gets involved.  The dupe has room for a task, so given that all tasks are the same priority, it sorts by proximity.  The storage bin closest to the dupe "wins," and its supply task is added to the dupe's chore list.

Thus the dupe has taken the closest task.. but that's in relation to the dupe's current position, rather than where the debris are.

Of course, this has all been covered above, but.. maybe wording it in a different way will help someone.

[VECCTOR]

Yeah, this has been a problem for a long time. 

The dupes should look for what storage to use *AFTER* they pick up the debris, not when they take on the task.

It seems like this should be a simple fix, but this bad behavior has always been there.

[blackbellamy]

I build and destroy a LOT of bins.  I take their choices away.

[Risu]

There is a checkbox in priorities window for doing the nearest jobs instead of the best jobs. It will ruin your colony if you leave it checked for too long.
 

[Argelle]

Seems a good advice, but the in game tooltip is confusing me, as it recomand proximity for large colonies... ?!?

[Risu]

9 minutes ago, Argelle said:

as it recomand proximity for large colonies... ?!?

If you had enough space and enough dupes they'd all be in proximity of important jobs.
 

[Argelle]

And if i've got a base where vital tasks are still central, and distant tasks.. exploratory, uncheck "proximity" is not a good idea ?

[Risu]

Any dupe that was still in the base would run around finishing jobs in there and any dupe out exploring would keep digging, until it had to return for downtime then it won't leave the base.
 

[KittenIsAGeek]

42 minutes ago, Risu said:

There is a checkbox in priorities window for doing the nearest jobs instead of the best jobs. It will ruin your colony if you leave it checked for too long.
 

There's a fudge factor in determining which job gets put on the list.  Without the box checked, base jobs get priority (such as supplying water to terrariums, running on the hamster wheel, etc).  With the box checked, the job closest to the dupe's current position gets priority.  This is assuming that all jobs are otherwise of equal priority.  

If you have a small base, its certainly best to not have the box checked.  This makes certain that base maintenance gets done.  However, once you've got a large base, it can get really frustrating without the box checked.  For example, lets say you have a dig order that is down in the oil biome.  Without the box checked, a dupe will run down, dig one tile, then run back home while another dupe is running down the ladder to dig the second tile.  With the box checked, however, a dupe will run down the ladder, then dig out all the tiles (assuming a higher priority job such as, oh, breathing, doesn't get in the way) before running home.

My personal experience has been that checking the box doesn't ruin my base unless I have only a few dupes but a LOT of base jobs -- such as farming mealwood.

[dearmad]

Been here.

Done this.D

 

[FantasticMoose]

My in-base compactors are prio 1 and only gets used when dupes would otherwise be idling.
I usually build a line of Compactors in every area I dig into for the Biomes local resources and prio 2 it.

[bobucles]

On 8/14/2019 at 7:32 AM, Argelle said:

So the only way to fight this, is having sweep only containers AND set the proirity of the containers close to the cleaning to 6 while setting down the others 604 containers to priority 5?

Don't ever do this. Setting a higher priority storage will cause dupes to pull items out of existing storage and deliver it all into the higher priority storage. You will end up with a huge mess and the trash will still be on the ground.

Dupes do not perform errands on items, they perform errands on storage. Dupes will look for the closest storage near their person, and bring the closest item into that storage. No other storages are considered during the errand.

[LucidFugue]

13 hours ago, VECCTOR said:

Yeah, this has been a problem for a long time. 

The dupes should look for what storage to use *AFTER* they pick up the debris, not when they take on the task.

It seems like this should be a simple fix, but this bad behavior has always been there.

It's a design decision that affects games of this type. To a certain extent is unavoidable if you want to maintain good performance. It relates to how you design your task system. 

You'll note that all delivery tasks have 3 elements:

1 - The building

2 - The resource

3 - The duplicant

Lets ignore 3 for a moment and focus on 1 and 2. You can design delivery tasks to be generated by either buildings, or resources. That is, you can say the building is generating a task to collect a specific resource and deliver it to the building, or your can say the resource is generating a task to be delivered to a specific building. The difference is subtle, but important. Most of the time you'll say buildings need to generate jobs already (operate) and their location is decided by the player, so we should be building centric. 

Now we bring in our duplicant. Lets say our duplicant wants to take on a new task. How does our duplicant pick the "best" task for them? Outside of priority, it's based on proximity to the task, right? But a delivery task has 2 locations - item, and building. If we rely on just one of those locations, we are going to have some sub-optimal results. 

Of course, you *can* use math to work out which delivery task is optimal in terms of total travel time for any given duplicant location. You don't even have to wait for the dupe to pick up the resource. You already know everything you need to know before the task has begun based on the duplicant's current location, the location of the resource, and the location of the container. Here's the problem - it's not going to be worth the processing power required to do so for the majority of delivery tasks (and there are going to be a LOT of delivery tasks). 

Then there's also the issue of how frequently you re-evaluate all these tasks to make sure each resource/building pair are optimised as new buildings are constructed, new pathways are opened up and new resources get added to the world. 

It does seem like it should be a simple fix, but you'll see some version of this problem in many games where you don't directly control the workers. 

[Lutzkhie]

I reported this ago as suggestion, the only solution is to make the closest storage a higher priority than all other storage bins

[bobucles]

4 hours ago, LucidFugue said:

 it's not going to be worth the processing power required to do so for the majority of delivery tasks (and there are going to be a LOT of delivery tasks). 

But you don't need to process a lot of delivery tasks. You only need to process the one task per minute a duplicant can actually manage. If code can't process 1 task per minute, it's probably bad code.

Starting the job from the debris is still optimal, because the trip is already half done. Go from debris to storage, done. Starting the job from storage means there are two trips involved. Start from storage, go to debris, return to storage. There's more stuff to do, so it should be no surprise it always takes longer to do.

[Lafara]

a funny fact : tasks with same multiplied priority number (such as 45) Dupe will rotate all tasks available in round robin fashion.

but not between each lump of debris. it rotate between each kind of task.

if that instance , there're mopping/storage/supply ... that dupe will rotate work from mopping 1 tile >> storage 1 time >> supply an industrial machine >> mopping again. if that dupe next task already been queue by other dupe, that dupe skip its rotation.