Will dupes ever just deliver to nearest container (all other factors being equal)

[CDoroFF]

54 minutes ago, Boxman_90 said:

Your argument seems to be based on "everything is pre-calculated and saved continuously so you can use it when asked". You seem to say that you think the distances between dupe-storage and dupe-debris are always known, at all times.

No.

 

54 minutes ago, Boxman_90 said:

changing the anchor-point for the proximity-calculation from dupe to sweep-task doesn't require any new information

It requires new information. It requires, literally, to calculate the whole way from debris to compactor. If it require no additional information, tell me the compactor-debris distance plz: Dupe-debris - 100 tiles, dupe-compactor 100 tiles. And this information is necessary and sufficient to show you the table of resources and compose tasks as game do it now. Until you realize this we can't go farther. And you have not to read the next part before.

 

54 minutes ago, Boxman_90 said:

paths for all these relations would have to be calculated and updated continuously as whenever a dupe moves one spot, the previous calculation becomes invalid. That's a massive workload for no good reason as these calculations are then most of the time not even used. I really doubt Klei decided to waste CPU-time by constantly pre-calculating possible dupe-debris and dupe-storage routes and saving them for later for the off case a sweep-task is issued.

Real-time is not really real . It basics of the modern game devlopment. Game is not continious.
There is a "tick"s when everything calcs and acts. If I remember right, there is 4 ticks per second. I guess they not recalculate all the paths each tick, but some or most of them they do. At least, I guess, the more debris on the map, the less often they calc it and more stupid dupes become. Do you ever come across the "stuck" at the moment of building or deconstructing the pipes? At these moments game recalculate just gas or liquid pipe systems coz smthing changes and whole system needs to be recalculated. That causes significant lags on my pc, if I have decent amount of pipes on the map. Just imagine how simplier pipes+in's+out's against paths+debris+compactors. Also, game have to calculate whole map paths to know is that resource\job task available or not. They can't avoid it, but can optimise. But anyway, game have to know every derbis availability for every dupe and it is the mad amount of calculations. How can you avoid it? How the game can know should it add this debris to the list in the left side of the screen? What happens if dupe pick it up? Just a handful of dupes on later stages makes game so slow, and you believe that debries does not impact perfomance?

Do you know the reason why they decrease map size so significant just per year? Because it is impossible to play on such large maps with that variety of resource consumers. Do you know why game become so slow not as soon as you reach the surface, but after digging out the tonns of regolith. Also the way to speed game up is to forbide half of the map to visit.

[Boxman_90]

Quote

It requires new information. Dupe-debris - 100 tiles, dupe-compactor 100 tiles, if it require no additional information, tell me the compactor-debris distance plz.

It requires no new information to make the calculation. The result of the calculation = the new information, however dupe-compactor doesn't need to be calculated anymore.

You say "no" but continue to explain that all pathing is continuously calculated. I really don't think this is the case since it's so expensive to do.

BUT

Let's say you are right, and actually the game does pre-calulate and cache all dupe-debris paths so it knows what is available. Then with 12 dupes and some 100 pieces of debris, it constantly calculates 1200 paths and keeps these up-to-date as the dupes move around. Then how much of an effort is it, really, to calculate just one(!!) more path if and only if a sweep task is accepted? Even if you have 100 compactors, that's just 100 more paths to check (if you do full path-finding to check for proximity, which you don't even have to do), less than 10% extra work-load in that specific case. Or if I use your own "10000 debris" (not sure where you got that from), you're adding 100 paths to 120000, less than 0.1%. That's not 'prohibitively expensive'. 

There is 0 need to pre-calc and cache all the debris-to-storage paths. This path only needs to be known when a dupe gets a sweep task. So, IF it works as you say, then instead of calculating 1200 paths per 4-tick, you now calculate 1300 paths for one 4-tick (one extra path exclusively for the sweep w/ 100 compactors) and execute the sweep. Only have to do that once so the added work-load lasts very short, since the debris location is stable.

If your whole premise is true, which I doubt, then still the calculation of that one additional path is pretty cheap compared to all it calculates anyway.

[Xuhybrid]

1 hour ago, CDoroFF said:

It requires new information. It requires, literally, to calculate the whole way from debris to compactor. If it require no additional information, tell me the compactor-debris distance plz: Dupe-debris - 100 tiles, dupe-compactor 100 tiles. And this information is necessary and sufficient to show you the table of resources and compose tasks as game do it now. Until you realize this we can't go farther. And you have not to read the next part before.

Again you're missing the point. It requires the same calculation compared to both of our test cases. The first test case being how it currently works and the second being how we want it to work. Also, it has already been confirmed that the task is pre-calculated. A storage container is selected, an item is selected. All based on proximity to the duplicant. I really don't see how you keep missing this key point. The path finding is already being done, therefore it costs nothing extra to use proximity from an item instead of a duplicant.

[ishakaru]

14 hours ago, CDoroFF said:

when and for what they did that calculations?

Why/what: sweep task(specific or nothing else to do)+one or more storages that can accept the specific type of resource. 

When: The frame before the dupe begins moving. It may happen before then, but I doubt it. The calculations are fairly light. This is the reason why jet packs cause so much lag. 

Context: This is happening in game right now. 

14 hours ago, CDoroFF said:

How game choose which debris require storage and which are not if the jobs tasks still not given?

From what I've seen: sweep command first, then random. They probably don't access the RNG specifically but just pull from the list of debris that isn't organized. This would mostly random in appearance.

14 hours ago, CDoroFF said:

It have to precalculate it then.

If you mean the calculation the frame before the dupe moves? Sure, okie fine. It's "precalculated" because you can't move with any kind of guarantee that you'll get to your destination much less chained destinations. But to my mind that's just standard calculation. But that calculation doesn't happen until it's determined that something should happen. 

 

14 hours ago, CDoroFF said:

game should know all the distances between debries storages before giving a task to dupe since it cannot be incomplete.

It sort of knows. It would be like you knowing the distance between your home and any other random building down to the inch/centimeter. Cept it doesn't have the intuitive capability to say building A is further than building B without doing the math. 

 

Here's how it works:(part I know for a fact) It moves out from a dupe checking for all available paths every several seconds(not per frame). There may be some shortcuts here to reduce load. An example of that would be skipping dupes found along that path because it's the same path. (guess)It links the items to the specific pathing node and somehow connects that item to the tasking system. <-- all of that is stored and updated as needed.

 

Using only what can be accessed along that pathing information we only ever have to worry about taking the right path and can ignore "is it possible". Specific paths(aka distance) between items is not stored because it's redundant and quickly calculated.

 

After giving it some thought, I think the core reason that swept items go into the closest compactor from the dupe and not the closest compactor to the debris is because the tasking system looks at the compactor and asks "is there anything available".  Since the dupe looks at closest to them first (when the proximity checkbox is selected) we get the behavior seen. 

[CDoroFF]

14 hours ago, Boxman_90 said:

Then how much of an effort is it, really, to calculate just one(!!) more path if and only if a sweep task is accepted?

To be ready to compose a complete job task game have to already know that way before assigning a task. To know it before you mark smth to sweep game have to precalculate it, since the game don't know what you intend to sweep.

14 hours ago, Boxman_90 said:

It requires no new information to make the calculation. The result of the calculation = the new information, however dupe-compactor doesn't need to be calculated anymore.

You making me laugth! Where is exact number? I gave you 2 distances, now tell me the 3rd and i wil shut up! If your answer is correct, ofc. But if you can't, then admit your mistake. Knowledge about 2 distances does not give you the 3rd.

 

13 hours ago, Xuhybrid said:

Again you're missing the point. It requires the same calculation compared to both of our test cases. The first test case being how it currently works and the second being how we want it to work. Also, it has already been confirmed that the task is pre-calculated. A storage container is selected, an item is selected. All based on proximity to the duplicant. I really don't see how you keep missing this key point. The path finding is already being done, therefore it costs nothing extra to use proximity from an item instead of a duplicant.

You still not undertand and seems that you not even trying. Game does not precalculate distances\paths between piece of debris and storage at the moment of task assigning. The only thing which is calculating are the dupe-item paths, since there are too much additional paths to calc. And I told it a million times already - to copmpose a complete task game have to know all paths before. In current state it is dupe-storage, dupe-item paths, in yours dupe-storage, dupe-item, item-storage.

Seemingly, you both have 0 experience in the programming. Then let's try to decompose the required steps to make queue of tasks and perform it. Since I have no decent experience in any language except powershell and PHP, let's use pseudocode based on the fact that some methods and clsasses is the blackbox and we just using them, be we have to keep in mind how heave they are.
Let's arrange that "distance" is equal to "path length" and "proximity" in terms of ONI.
consumer=storage=building=point where the piece of debris should be located.
item=debris=resource

Are you agree that the game makes something similar jsut about each tick second in the game? If not, then how the game shows you the list of avaliable resources? Especially in case of changing the routes by digging\building a tile\sand and regolith falling\goint through doors\etc.
the following code example describes what in my opinion happes when we load the save game:
#to know which resource on the map is avaliable for dupe
if(savegame.justloaded==true)then{
    dupe.calc_path()
    foreach(resource in map){
        if(resource.location==dupe.path)then{
            resource_table.add(resoure)
        }
    }
return(resource_table)
}
Are you agree with it?

1 hour ago, ishakaru said:

Why/what: sweep task(specific or nothing else to do)+one or more storages that can accept the specific type of resource.

Hmm, they dont need it.If dupe can rach resource and can reach the storage, then he can carry the first to the second. 

 

1 hour ago, ishakaru said:

From what I've seen: sweep command first, then random.

We just told that dupes carry the nearest item to the nearest storage (nearest from the dupe at the moment of task assigning, with equal priorities, avaliability, etc)
 

 

1 hour ago, ishakaru said:

If you mean the calculation the frame before the dupe moves? Sure, okie fine. It's "precalculated" because you can't move with any kind of guarantee that you'll get to your destination much less chained destinations. But to my mind that's just standard calculation. But that calculation doesn't happen until it's determined that something should happen. 

Yep, that's what i said and mean. The frame where the dupe recieving the task. Since after it nothing worrying him except some extreme situations such as path block or storage state change.

1 hour ago, ishakaru said:

It sort of knows. It would be like you knowing the distance between your home and any other random building down to the inch/centimeter. Cept it doesn't have the intuitive capability to say building A is further than building B without doing the math.

That is it. To choose really the nearest it have to calc exact distance between item and each storage on the map. Before that it cant say that this one is the nearest. I'm saying that game not doing this task at all. I'm saying that it's quite hard to compute.  It's not so hard if we use the graph which was created for dupe path and we change the top node.

After the night i realised that game really does not calculate whole path each frame, but it keeps it and makes the changes in it quite often anyway. Also, each pathing change causes need to re-compare each item location with this path or with part which was changed.

now reading last 3 paragraphes... give me the brake =)

1 hour ago, ishakaru said:

Here's how it works:(part I know for a fact) It moves out from a dupe checking for all available paths every several seconds(not per frame). There may be some shortcuts here to reduce load. An example of that would be skipping dupes found along that path because it's the same path. (guess)It links the items to the specific pathing node and somehow connects that item to the tasking system. <-- all of that is stored and updated as needed.

 

Using only what can be accessed along that pathing information we only ever have to worry about taking the right path and can ignore "is it possible". Specific paths(aka distance) between items is not stored because it's redundant and quickly calculated.

Completely agree.

[CDoroFF]

1 hour ago, ishakaru said:

After giving it some thought, I think the core reason that swept items go into the closest compactor from the dupe and not the closest compactor to the debris is because the tasking system looks at the compactor and asks "is there anything available".  Since the dupe looks at closest to them first (when the proximity checkbox is selected) we get the behavior seen. 

I forget about that setting, but then the priority of the storage should be the prime. In case of 7_sweep_item and 5_storage dupes start to carry items with priority 7 much earlier than other debris around.

[Boxman_90]

3 hours ago, CDoroFF said:

To be ready to compose a complete job task game have to already know that way before assigning a task. To know it before you mark smth to sweep game have to precalculate it, since the game don't know what you intend to sweep.

Explain to me, why would the path of all debris to all storages have to be pre-calculated at all times, what's the use? It wastes resources. What makes it forbidden to only calculate that path (from item -> storage) when the item is marked for sweeping and not before? It is never needed except when a dupe starts a sweep-task.

I have 100 items scattered around, and 100 compactors. That is 10.000 paths to pre-calculate in your view.

-or-

I have 100 items scattered around, and 100 compactors. Dupe is assigned to a sweep task close to him, using dupe-to-item path. One extra path is calculated for that specific item to a close-by compactor, at most 100 paths to calculate and choose from.

Why does the game need all those paths known at all times? It makes no sense. It's a waste of resources.

Quote

You making me laugth! Where is exact number? I gave you 2 distances, now tell me the 3rd and i wil shut up! If your answer is correct, ofc. But if you can't, then admit your mistake. Knowledge about 2 distances does not give you the 3rd.

Laugh all you want, but re-read what I say. I think you misunderstand my English - you don't need new information compared to the old situation to start the calculation of the new path. The path you get, is indeed new, but my whole point is that you only need to calculate the path for the item you intend to sweep, not all the items that can at one point in the future be sweeped all across the map.

Just do that very specific calculation ONLY when a dupe starts that job, and don't waste CPU resources otherwise. It is never required except for that specific task. It's a tiny CPU load if it works the way you said.

 

(still I doubt the game pre-calculates, caches and updates all these paths constantly. But even in your hypothetical case it only costs a fraction extra CPU time to do it our way)

[ishakaru]

42 minutes ago, CDoroFF said:

1 hour ago, ishakaru said:

Why/what: sweep task(specific or nothing else to do)+one or more storages that can accept the specific type of resource.

Hmm, they dont need it.If dupe can rach resource and can reach the storage, then he can carry the first to the second. 

I think there may be a misunderstanding here. Latter in that post I defined that capability has already been determined. I was simply stating there was an intent here. 

 

53 minutes ago, CDoroFF said:

That is it. To choose really the nearest it have to calc exact distance between item and each storage on the map. Before that it cant say that this one is the nearest. I'm saying that game not doing this task at all. I'm saying that it's quite hard to compute.
 

 

A*: First step would be to take all compactors capable of receiving the resource. Sort them by manhattan distance (target-tower) then sort from small to large using (x*x+y*y)  no need to root the value yet as we don't need an absolute just a relative value here. Then do the path for each (sorted by distance short to long), when the next one has a sqrt(man_distance)>than the shortest distance you stop. Keep the path you found for dupe use. Sounds like alot, but really isn't.

Or you can simply do a breadth-depth search and return the first viable compactor path. More memory intensive, but easier on computation. Does have the drawback that you can't take into account run speed bonuses. Which could be kinda accounted for by continuing to next 2-3 and comparing times. 

These algorithms have been well defined since 1945(breadth-depth) and 1968(A*).

1 hour ago, CDoroFF said:

We just told that dupes carry the nearest item to the nearest storage (nearest from the dupe at the moment of task assigning, with equal priorities, avaliability, etc)
 

hmmm, true. I stand corrected.

[CDoroFF]

3 minutes ago, Boxman_90 said:

Explain to me, why would the path of all debris to all storages have to be pre-calculated at all times, what's the use? It wastes resources. What makes it forbidden to only calculate that path (from item -> storage) when the item is marked for sweeping and not before? It is never needed except when a dupe starts a sweep-task.

I wrote another giant text and realised that i just rewrote what I already told you. Plz, explain to supid me, step by step, how job task system works here. I'm talking not only about sweep task, since same conditions should be applicable to any job task, be it build, mop or sweep. Seemingly we imagine that systems in different ways. 
Btw, my view changed since yesterday and the system now seems much more complex for me and it become much harder to take into account all the nuances.
 

[ToiDiaeRaRIsuOy]

Guys, guys, is all of this animosity necessary?

-People who don't have experience with programming: please listen and read carefully what the ones have experience, write. I think it's important value their opinions.

-People who have experience with programming: please write it understandable for us who don't have experience with programming, and have some patience. We all are argueing about a game we passionately care about.

 

[JoeW]

This is a conversation about a video game. It doesn't need to turn into an argument. 

Please continue the conversation in a polite and constructive manner or it will just be locked. 

[Boxman_90]

1 hour ago, CDoroFF said:

I wrote another giant text and realised that i just rewrote what I already told you. Plz, explain to supid me, step by step, how job task system works here. I'm talking not only about sweep task, since same conditions should be applicable to any job task, be it build, mop or sweep. Seemingly we imagine that systems in different ways. 
Btw, my view changed since yesterday and the system now seems much more complex for me and it become much harder to take into account all the nuances.
 

I think your point is that Klei designed one system that always uses dupe as origin for all selections, so that it's a one-system-fits-all-jobs, for simplicity. So that you never run into a job where the dupe can't reach the destination.

However, not all jobs are equal and some jobs require other things than other jobs. So there is a difference between each job, and the game is already aware of that, it knows if it runs a sweep, build, deliver or whatever. What I propose, is when "sweep job" is selected, an additional one-time calculation is made that takes into account the location of the sweep task. In a worst-case-scenario (>100 compactors), this adds 10% extra CPU load for one frame when you have 100 pieces of debris scattered around.

So step by step;

1. Sweep task is assigned to dupe.
2. Dupe checks storage availability ("where he can go")
3. Dupe checks for nearby debris
4. Adding one-time calculation for shortest path from debris to available storage determined in step 2, select this storage
5. Use debris from step 3 and storage from step 4, disregarding storage of step 2.
6. Run the job as normal.

In this case the whole 'regular' system stays intact, but you just add a one-time calc. No need to keep all those routes from debris-storage cached at all times, you only ever need it for a sweep task.

[Xuhybrid]

10 hours ago, ToiDiaeRaRIsuOy said:

Guys, guys, is all of this animosity necessary?

-People who don't have experience with programming: please listen and read carefully what the ones have experience, write. I think it's important value their opinions.

-People who have experience with programming: please write it understandable for us who don't have experience with programming, and have some patience. We all are argueing about a game we passionately care about.

 

I shouldn't have to state that i'm a software developer in order to be taken seriously.

9 hours ago, JoeW said:

This is a conversation about a video game. It doesn't need to turn into an argument. 

Please continue the conversation in a polite and constructive manner or it will just be locked. 

The fastest way to resolve the discussion would be to have someone from Klei comment here about the topic, but it seems the only thing worth posting about is being polite and constructive.

[Gurgel]

13 hours ago, CDoroFF said:

Hmm, they dont need it.If dupe can rach resource and can reach the storage, then he can carry the first to the second. 

If there are no one-way constructs in there. There may be a reason Klei does not supply them, but you can create some with automation. Would be interesting to see what happens if you have a dupe that can get to item and storage, but not back from item to current position and that is the only way back to storage. Of course, you can make the condition more complex, but my guess would be that they assume the dupe -> item path to also work in reverse and execution will just fail at the item if it is not. Anybody willing to do the experiment?

11 hours ago, CDoroFF said:

Btw, my view changed since yesterday and the system now seems much more complex for me and it become much harder to take into account all the nuances.

Typical experience for something like this: The more you get into the detail, the more complex everything gets.

1 hour ago, Xuhybrid said:

I shouldn't have to state that i'm a software developer in order to be taken seriously.

The problem is not that you are not taken seriously. You are, as you can see by still getting answers. The problem is that you do not take the statements of those with domain knowledge seriously and insist that your model of things is right. Now, in CS (and even more in my specialty of IT security) this is a common experience for experts. The reason is that things seem deceptively simple, but as soon as you go into details they explode in complexity and often in ways that are not readily explained.

Now, this is not an accusation or anything. It is just a statement that there are things that cannot simply be explained to you without you being willing to invest a few years of study first. The "it takes 10'000h (about 5 years full time) to become an expert" fact is the problem here. Now, if we could just point you at the right body of knowledge and you could just download it and integrate it, this problem would go away. But we cannot. And hence, some things you will have to take on faith here. I do agree this is not a good situation and, as I stated above, I do know that there are a lot of "experts" that abuse this situation. I promise you that I really try to not do that and I have not seen anybody else in this discussion doing it either. I also know that I often work on a very abstract level these days and that this is often hard to follow for others. My apologies, but this approach does lead to good engineering results for me.

[ToiDiaeRaRIsuOy]

6 hours ago, Xuhybrid said:

I shouldn't have to state that i'm a software developer in order to be taken seriously.

I made a plea for less animosity. I'm not pretending to know anything about programming nor will I have the nerve to make any ignorant opinion on it. The ones making this debate obviously all have some experience, relevant to the game or not, with it. So please, get along. You guys want a change from the game developers? They are not going to listen if you decent into harsh bickering. For the record, I am not singling you out on this one.

[CDoroFF]

On 08/01/2019 at 9:11 PM, Boxman_90 said:

• Sweep task is assigned to dupe.

Wrong. Actually, you made a mistake even before the 1st  item in ur list. There is no point to assign task to dupe if, for example, the item is unreachable. Game "checks" that fact before assigning, proof on the picture below. You can also try to mop unreachable water. The task's icon will be pale. As Gurgel said, you have to spend decent time to understand it on very shallow level. And keep in mind that one system process not only the sweep tasks, but aslo every possible task. Btw, it seems that ishakaru have already found the explanation.
@ishakaru,
I have made some tests.These experiments ruined my initial idea about heavy AtoB pathing calculations, however you did it before with A*. Nah, this was just off the top of my head. 
I completely agree with your idea about compactors priority, at least, because it corresponds perfectly with construction tasks, where supremacy (is that word correct?) of target building is obvious. Among my tests was one with one-way door. In that case dupe came to item, picked it up and dropped, because destination point became not reachable anymore. Same with constructing. Is there the way to check it more confident?

[ishakaru]

27 minutes ago, CDoroFF said:

Among my tests was one with one-way door. In that case dupe came to item, picked it up and dropped, because destination point became not reachable anymore.

Huh, weird. Did you assign the task before or after you set the one-way door? If you assigned before then things make sense and the path was invalidated upon the change(working as intended). After means that pathing doesn't consider settings of buildings under some condition which is a bug.

[Boxman_90]

@CDoroFF , you like just saying "wrong" and not addressing the entire rest. But it is not the core of the problem, you can still add the calculation I propose. There can be a list of reachable debris that's calculated by however means that is always known and updated, and the game can pick from that to assign a task to the dupe or vice versa. It doesn't matter who starts the task (dupe or game).

But I can change the step-by-step to this if you want:

1. There is a list of reachable debris, calculated by >doesn't really matter how<. If it's by pathing, all the better, final taks becomes easier to compute.
2. Dupe locates close-by debris from available-debris-list
3. Dupe checks storage availability ("where he can go") to make sure it can be stored at all.
4. Dupe starts/accepts sweep-task. Or is assigned sweep task from list of tasks with priority sorted. Doesn't matter.
5. Adding one-time calculation for shortest path from debris to available storage determined in step 3, select this storage
6. Use debris from step 2 and storage from step 5, disregarding storage of step 3.
7. Run the job as normal.

[CDoroFF]

@Boxman_90, OK, let's forget about reserving a place and number of other things. Try to apply that to a constructing task.
 

32 minutes ago, ishakaru said:

Huh, weird. Did you assign the task before or after you set the one-way door? If you assigned before then things make sense and the path was invalidated upon the change(working as intended). After means that pathing doesn't consider settings of buildings under some condition which is a bug.

dupe at S location, door one way with arrow, no path around, few reachable avaliable storages around besides starting one. Sweep-> go->pick up-> drop. But if i sweeped a huge pile and smth stayed on the ground dupe instantly took another one sweep task and performed it well, to the nearest compactor ofcourse.

[Boxman_90]

I'm saying to only alter the one-size-fits-all system a little bit after it has been detected as a 'sweep' task. Still use the whole system but add a new calculation for item-storage one time only to determine a new destination. But i think we will forever misunderstand each other. I'll leave it at this.

[Sasza22]

Ok guys i took a sleepless night to think about the issue and i think i might have figured out what is happening here:

First of all all the available materials in the game (shown on the right side) are probably caluclated basd on the duplicant pathing (the navigation). Since that is calcualted constantly anyway it might as well be used to determine if an object is reachable by the dupes or not. Stuff that can`t be picked up doesn`t figure in the resource list. Examples: liquid/gas in reservoirs isn`t counted as it can`t pe picked up, resources carried by a dupe can`t be picked up by another dupe so don`t figure either (untill dupes learn to pickpocket), whenever a path is closed the resource behind it disappear from the list.

Now for the main issue, the compactors. I think the sweep job isn`t based on the swept object but on the sweep destination. In simple words when a dupe ends a task and searches for another one he finds a delivery task to a certain building, lets say cooking station. The station requests ingredients. The dupe locks on the closest station and starts searching for the ingredient. Finds the ingredient passes by 2 other cooking stations requesting the same stuff and delivers to the first one he selected. Sounds familiar? From what i can tell the compactor, similarly to the cooking station, is ajob station. A storage job is done at the compactor. The compactor requests a certain item and the dupe delivers it. In this case the sweep order appearing on the debris is misleading. The compactor is the entity requesting the task so the task originates from it (might only accept the tasks marked for sweeping though) this means the dupe locks on to the first compactor before even deciding what is he going to sweep.

So in short:
1. the compactor is selected first
2. the item to sweep to storage is determined based on what the compactor requests
3. no further calculations are done unless the job path gets somehow broken

Now if that is the case and all deliver jobs are coded this way then the experts might be right and fixing it would require changing the entire delivery system that is the absolute core system of the game. It`s possible for sure but it might be way more work than we imagine. Also i don`t think creating an exception to the compactor storage system would be a good idea.

Disclaimer: All what i wrote is based on my assuptions and random observations of dupes at work. I might be totally wrong here.

[Le0n1des]

29 minutes ago, Sasza22 said:

So in short:

1. the compactor is selected first
2. the item to sweep to storage is determined based on what the compactor requests
3. no further calculations are done unless the job path gets somehow broken

I'll just paste my post from Monday here, simply to encourage discussion regarding the suggested solution to the original problem

On 1/7/2019 at 7:15 AM, Le0n1des said:

It seems the original issue here was dupes going to the far ends of the map to fetch something...

The existing algorithm (as far as I'd imagine) is "find nearest non full container with highest priority" (priority queue pop) -> "find nearest item out of the selection list attached to the container" (path finding, I.e. the heavy part) -> "bring item back" (no additional calculation, if utilizing the same container that originated the task). Changing part "3" to an additional pathfinding calculation seems like a bad idea...

Instead of all that shenanigan you could have had a"maximal range" value attached to container to cut the pathfinding short. This would solve the issue while also benefiting the performance

 

[Boxman_90]

@Sasza22, I'm just tested your hypothesis by breaking the path when the dupe is running, and it breaks the job - he drops the item, then recalculates the entire job to a new compactor and starts anew.

After that I did another test to see if it prefers closeby compactors and then decides what to sweep, or prefers closeby sweeps. I put two compactors with two different filters (one wort seed, one balm lily seed) close to each other, then put the wort seed next to the balm-lily container and the balm-seed next to the wort-seed container. Moving the dupe to the balm-lily container (standing between the wort-seed and the balm-lily-container, makes it run all the way to the other side to retrieve the balm-lily seed. It indeed prefers compactor location first, and finds debris from there.

I think you are right.

Quote

 the experts might be right and fixing it would require changing the entire delivery system that is the absolute core system of the game.

Haha yes, funny thing is that apparently the non-expert (you) was very able to precisely explain what the 'expert' (whom we shall not name) said he could not explain because it was 'too complex'. Ironic

Another solution would then be an 'optional' calculation. Run the job as usual, but upon the action of sweeping (couple it to the sweeping animation if you want, you have a few seconds to calculate here), run the "find nearby compactor" search again, and see if there's an empty one closer to the current location. Since the paths are always known anyway, it would only have to check the list for free space. If we're short on time, limit this calculation to a max proximity. If during those few seconds a new compactor is found, change reservation to new compactor and continue job. If not within the time-frame of the animation, exit the if-loop and return to the job as usual.

Sub-optimal and not as easy as we proposed in the start of the topic, but it would greatly improve dupe efficiency in big maps. Hugely even.

Limiting the maximum range of a compactor can't be done since then you would have debris that never gets stored if you have only one compactor room. Unless you mean a range-slider in-game. But also this is problematic as your dupes won't move anything to your central storage anymore in their downtime.

[Le0n1des]

34 minutes ago, Boxman_90 said:

Limiting the maximum range of a compactor can't be done since then you would have debris that never gets stored if you have only one compactor room. Unless you mean a range-slider in-game. But also this is problematic as your dupes won't move anything to your central storage anymore in their downtime.

It seems to me the optimal range would be similar to a maxed zoomed out view... This way you shouldn't have problems with a central storage (as long as it's actually central). You could always build and intermediary compactor with a lesser priority to extended the range

[Boxman_90]

You could fix it with intermediary compactors, but then for implementing it we have the same problem - all distances are currently calculated from the dupe's perspective, and not from a compactors perspective. This makes implementing 'range' for a compactor in the current setting difficult, since if it's as @Sasza22 says, distances are never calculated from an item or job in the current situation. Apparently 'distance from object' is not in the code at all yet.