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

[ToiDiaeRaRIsuOy]

Only on the ONI forums will a once toxic discussion turn into a scientific one.

[Boxman_90]

31 minutes ago, Miravlix said:

It's a scientific fact that the smarter you are, the dumber you know you are.

Not that this has much to do with this thread, as it seems some aggressive information deficit people for some reason ask question and then shoot the messenger when they try to explain.

Nobody has actually attempted to explain what the issue is to change the origin of a lookup task that's demonstrably present in the game and I continue to believe there is none. They've been too preoccupied drumming their chests by explaining how they're experts and how that means they don't have to explain anything, as if that suddenly absolves them from respecting the code of conduct for research integrity they signed after receiving their degree, if they ever did.

6 hours ago, Gurgel said:

Funny thing is that I have had this type of discussion with students that were fully aware of my qualifications. 

In the future, try not to treat "qualified" and "always right" as synonyms in your approach. You've been demonstrably false in this very topic. I fail to see the logic in not wanting to explain anything (but by now I see that it's an inability, rather) for it 'taking too long to explain', yet putting hours of effort into lengthy posts defending your status and qualifications.

[ToiDiaeRaRIsuOy]

[Xuhybrid]

1 hour ago, Miravlix said:

It's a scientific fact that the smarter you are, the dumber you know you are.

 

Not that this has much to do with this thread, as it seems some aggressive information deficit people for some reason ask question and then shoot the messenger when they try to explain.

 

The long and the short of what we have been trying to explain is that while you can do just about anything in code, some choices cost exceptionally more to perform than others also you are asking them to rewirte the entire game from scratch to implement some of your suggestions.

 

The list of resources on the right side of the screen is a feature of the way the game is designed. So because the game KNOWS resources in the world, it can use that to KNOW what jobs is available at storage and machines and that leads to how it gathers items.

 

Sure you can recode the entire thing scrap all work done so far and start over with a different design. It's even possible a different design would be better, it DOES NOT MATTER. What matters is how things IS right now and how much both CPU power and re-coding it would take to change. Not whatever one design is better or worse than another.

 

Except nobody is asking for a full rewrite. The game already has path finding logic. I'm still waiting for someone to say it's impossible or difficult to have path finding from an item instead of a dupe because that's the only way you can defend keeping, what appears to me, to be an oversight. It costs the same amount of CPU per cycle to check a path from a DUPE than it does from an ITEM. Especially in the case we're trying to fix, due to that path having less travel time and resolving sooner.

[CDoroFF]

23 minutes ago, Xuhybrid said:

 I'm still waiting for someone to say it's impossible or difficult to have path finding from an item instead of a dupe

We are not a Klei developers and we don't know how it works exactly. Therefore all what we talking about is just our guesses. I guess the same mechanism works in every job errand, be it sweep build or smth, whatever. I believe there is no optimal decision, but "not so bad in most cases". And I guess Klei calculated how significant for players build\dig\sweep\mop tasks and chose most suitable. Check the image below. There is the dupe? the job point  and 3 points with resources. Ofcourse the purple resource point (RP) is optimal (18 tiles travel), but it's not proximal for dupe neither job point. In the current state, dupe will take yellow and it costs him 22 tiles travel. If dupe will choose your way - it will costs him 34 tiles. In that case your change brings only troubles. Keep in mind, it is just an example and I can not disprove you same as you cant say what your method is better. It would be nice if game will calc optimal way in each situation, but it will cost unreal amount of CPU tacts, since it requires TSP https://en.wikipedia.org/wiki/Travelling_salesman_problem solving each tick of the game. May be, as I already mentioned, there is a bug related to hidden priority, but who knows?

[Boxman_90]

The issue we’re trying to discuss is not the pathing efficiency and preciseness, but selecting the destination, for which currently some calculation is already demonstrably used before invoking real-time path-finding during execution, with the anchor point being the dupe.

The game clearly shows it determines the destination seperately from the task at hand. It ignores all factors of the task itself except current dupe location to find closest storage to dupe’s current location for the materials it’s been ordered to sweep.

We’re suggesting to change the anchor point for this mystery calculation to the task - all else the same.

How can it still not be clear that this and only this is questioned here?

[CDoroFF]

2 minutes ago, Boxman_90 said:

The issue we’re trying to discuss is not the pathing efficiency and preciseness, but selecting the destination, for which currently some calculation is already demonstrably used before invoking real-time path-finding during execution, with the anchor point being the dupe.

The game clearly shows it determines the destination seperately from the task at hand. It ignores all factors of the task itself except current dupe location to find closest storage to dupe’s current location for the materials it’s been ordered to sweep.

We’re suggesting to change the anchor point for this mystery calculation to the task - all else the same.

How can it still not be clear that this and only this is questioned here?

Check the image again, please. Tell me, In that case, you want dupe choose resource nearest to him or to job point?

[Boxman_90]

Your analogy does not seem to apply to sweep tasks where there is a job (sweep) and a destination (compactor) - in your analogy the ‘job’ is the destination. It’s not a valid analogu until the “RP’s” are three equal “sweep tasks” and the “job” is a compactor. And then yes please, i’d like that sweet green debris in that very close-by compactor, regardless of where the dupe is at. 

To clean up all three tasks the dupe has to run back and forth three times anyway, so i’m really not concerned with the TSP of ‘which one do i pick first to get the most most most efficient route”. Add a compactor next to each sweep task, though, and your dupe would suddenly be super efficient, instead of ottherwise running to the task and all the way back to the same compactor three times, while there are perfectly good compactors right next to the sweep.

The thing is, with job as the origin it becomes very easy to manage your base by just adding compactors where they’re needed, in your analogy too the excess travel time js trivially solved by adding more compactors, whereas in the current situation there’s no viable workaround except micromanagement of dupes. I’d pick the versatile option any day of the week - not managing your storage is on you. Not being able to manage storage is on Klei.

[ONIfreak]

Ok. I'm not and expert or programmer like many people in this forum so my understanding might be a bit "blunt" but why dupe and material has to be in the same mechanism working together. is it not easier to make one container (logical container - like database) of all dupes who can go "sweep" job, make another container when you actually add "sweep" to some material. Then calculate path from material to container (in Oni every tile on map has vertical and horizontal position). 3rd container will have all "storage compactors".

2nd container- what i understand by calculation is. check where materiel is on map. pin point it, check from storage compactor list first which one is available for this materiel. after calculate distance (1 - normal tile, 0.5 - normal tile with 50% runspeed etc) and choose the lowest number. After reserve space in that container. and do another calculation

Now game choose dupe available for task and send it to material. when dupe approach material and touch it - this execute another task with already calculated storage compactor.

This way you do not have to do everything on "live". Materials can be calculated separately and value will be added to material itself. (even better PC can calculate this while digging using digging time to actually do it).

Now if you deconstruct storage compactor - it can just send info to reserved materials to recalculate - again using "deconstruct" time for it.

Is that make sense?

[CDoroFF]

1 minute ago, Boxman_90 said:

Your analogy does not seem to apply to sweep tasks where there is a job (sweep) and a destination (compactor) - in your analogy the ‘job’ is the destination. It’s not a valid analogu until the “RP’s”

oooh, I was awared, but every time it's shocking me.
1. Klei base game on Unity.
2. Unity is based on OOP Languages, mainly C#
3. OOP based on Encapsulation, Polymorphism, Composition, Inheritance, and Delegation.
4. It's mad to create brand new methods and classes for each object in the game since it Object oriented environment.
We dont know how it works. Even is it dupes choose job or the job tasks choose dupes? Both options seems reasonable. 
5. Either sweep, mop, build tasks are jobs. "Job" does not imply just the building process. Job task can include matherial gathering, moving to a job point and processing a job. Also it can include such methods as "check_resource_availability", "check_path_availability".  "Mop" requires no material to bring, building a tile needs all of these. But one thing I can say with high probablilty: all the job tasks are inhereted from one parent. Changing routing methods influence all pathfinding moments in the game.
 

[Gurgel]

59 minutes ago, CDoroFF said:

oooh, I was awared, but every time it's shocking me.
1. Klei base game on Unity.
2. Unity is based on OOP Languages, mainly C#
3. OOP based on Encapsulation, Polymorphism, Composition, Inheritance, and Delegation.
4. It's mad to create brand new methods and classes for each object in the game since it Object oriented environment.
We dont know how it works. Even is it dupes choose job or the job tasks choose dupes? Both options seems reasonable. 
5. Either sweep, mop, build tasks are jobs. "Job" does not imply just the building process. Job task can include matherial gathering, moving to a job point and processing a job. Also it can include such methods as "check_resource_availability", "check_path_availability".  "Mop" requires no material to bring, building a tile needs all of these. But one thing I can say with high probablilty: all the job tasks are inhereted from one parent. Changing routing methods influence all pathfinding moments in the game.
 

Well, one of the things you run in time and again when doing data structures for optimization or search is that you can do either something balanced which gives bad but not extremely bad results for several different types of search or doing something unbalanced which gives good results for one thing and extremely bad for most others. This can be something like starting a search from the target or the source. In simple scenarios, you can sometimes simply maintain both unbalanced data structures, with twice the coding and CPU effort, but usually even that is already too expensive. In complex scenarios (like ONI), you probably have to make one choice and stick with it. And then the option to do it the other way round is simply not there without changing a lot of things and a lot of follow-up debugging and optimization.

Here "if it ain't broke, don't fix it" comes into play, as a general principle of sound engineering approaches. If it is complex and works well enough (and ONI planning does, we are all examples of that, since we do play and hopefully enjoy it), do not try to fix it or improve on it. You usually end up doing more harm than good. Now, the problem with this is that it is not something you can prove or even really demonstrate. It is something you learn from experience, usually by failing or by having a hell of a time preventing failure after you violated it. Intelligence and education are necessary to acquire this experience, but they cannot replace it. And yes, that is an "argument from  authority", because none other is possible and the fact is valid. My apologies for that. The only thing that can replace experience is more experience.  

[ishakaru]

Just now, CDoroFF said:

Changing routing methods influence all pathfinding moments in the game.
 

This is true sort of. For a dupe to move from point A to point B I assume it's a waypoint system with an A* solution. That's as far as the intelligence goes and the bare minimum required. For tasks it's random. There is no task organization->scheduling beyond who can do what. I'm not surprised that sweep tasks do what's described in this thread. Another example would be the dupe going out of their way to pick up resources for a delivery task. It's path to closest sandstone->path to destination. Rather than looking for closest sandstone to the destination. So if you have a path that requires dupes to hold their breath for the entire route without reaching the destination, you can relocate all of a specific resource along that path.

 

Why hasn't Klei implemented a smarter AI? To change things in a way people understand it would require that pathing be a function in a larger more abstract tasking AI. This is very difficult, prone to error, resource intensive,  and arguably redundant work in light of the functional (if not optimal) system we have now.

[Yunru]

3 hours ago, CDoroFF said:

We are not a Klei developers and we don't know how it works exactly. Therefore all what we talking about is just our guesses. I guess the same mechanism works in every job errand, be it sweep build or smth, whatever. I believe there is no optimal decision, but "not so bad in most cases". And I guess Klei calculated how significant for players build\dig\sweep\mop tasks and chose most suitable. Check the image below. There is the dupe? the job point  and 3 points with resources. Ofcourse the purple resource point (RP) is optimal (18 tiles travel), but it's not proximal for dupe neither job point. In the current state, dupe will take yellow and it costs him 22 tiles travel. If dupe will choose your way - it will costs him 34 tiles. In that case your change brings only troubles. Keep in mind, it is just an example and I can not disprove you same as you cant say what your method is better. It would be nice if game will calc optimal way in each situation, but it will cost unreal amount of CPU tacts, since it requires TSP https://en.wikipedia.org/wiki/Travelling_salesman_problem solving each tick of the game. May be, as I already mentioned, there is a bug related to hidden priority, but who knows?

You say all that, but all I can think is: "Thank the gods! Finally my dupes would stop using random almost-rotten/super-hot materials and actually use the resources I have stored next to the damn job!"

9 hours ago, Le0n1des said:

What I meant is part 1. the nearest container to the dupe is selected and then part 2. the nearest item to this container is found.

Part 1. Is called after a dupe has finished the previous task, so in the case originally described - it is going to be the same container that was last filled.

Limiting the sweepable range around a container would brake this loop and make the order move to another container.

Assuming it does work that way, why not swap 1 and 2? Sweep tasks are already an exception to every other task's operation order, so it's not like it's unchangable.

I mean, this is what we want, note how few things change:

1. the nearest item to the dupe is selected and then 2. the nearest container to the item is found.

 

Edit: Also, daaaymn Klei's automerge spoils me, causes so much trouble on regular forums.

[Boxman_90]

Quote

If it is complex and works well enough (and ONI planning does, we are all examples of that, since we do play and hopefully enjoy it), do not try to fix it or improve on it

Bold statement for a game in pre-release alpha.

@CDoroFF your analogy assumed “fetch resource” and “sweep task” identical, which its not since a sweep task has a separate priority. Whether dupe chooses task or task chooses dupe, a separate proximity-calculation is made from dupe-location when storing stuff specifically. This is fact, you can check easily ingame. This is unique to that task. Change origin for that specific operation to item instead of dupe and the problem goed away.

[CDoroFF]

2 minutes ago, Boxman_90 said:

a separate proximity-calculation is made from dupe-location when storing stuff specifically. This is fact, you can check easily ingame.

It's just my guess:
When ONI gives dupe the task he have to get whole route just to know is it possible to do, or not. That means that every tick game do the complex job. It moves dupes by each avaliable route and look for each available resourse on this way(100k debris for example). If you have 12 dupes game made it 12 times and it tooks 1200k SPR (SOME PROCESSOR RESOURCE). Also it calcs nearest storages including buildings (150 different storages, grills, research stations and building tiles*) and it takes 12*150=1800 SPR with total 12001800 SPR to know where everything avaliable located. Then game just take data from these tables and allow dupes or not to do their tasks. Picks nearest res and carry it to the nearest storage\building. Just imagine, you want to add to these calculations a littlebit. Just nothing. You just want the game keep data about relations between 100k debris and 150 storages. It takes 15000k SPR. It will takes 1150% more time to calc that all.
* sweep is the same as building a tile or deliver food for cooking. dupe must take res and bring it somewhere. So, each building task, sweep or metal refinery is the "storage" in this way.

[ishakaru]

49 minutes ago, CDoroFF said:

It's just my guess:

Real time calculations are much cheaper than storing data for highly dynamic situations. The only thing it would make sense to store would be waypoints(which the game does). 

 

Your math is just wrong man, a resource value has no bearing on how expensive(on your computer) it is to move it. You also missed the entire point of what was said: The proximity check is already being made. The suggestion changes nothing in terms of load on the computer. 

[Xuhybrid]

3 hours ago, Gurgel said:

Well, one of the things you run in time and again when doing data structures for optimization or search is that you can do either something balanced which gives bad but not extremely bad results for several different types of search or doing something unbalanced which gives good results for one thing and extremely bad for most others. This can be something like starting a search from the target or the source. In simple scenarios, you can sometimes simply maintain both unbalanced data structures, with twice the coding and CPU effort, but usually even that is already too expensive. In complex scenarios (like ONI), you probably have to make one choice and stick with it. And then the option to do it the other way round is simply not there without changing a lot of things and a lot of follow-up debugging and optimization.

Here "if it ain't broke, don't fix it" comes into play, as a general principle of sound engineering approaches. If it is complex and works well enough (and ONI planning does, we are all examples of that, since we do play and hopefully enjoy it), do not try to fix it or improve on it. You usually end up doing more harm than good. Now, the problem with this is that it is not something you can prove or even really demonstrate. It is something you learn from experience, usually by failing or by having a hell of a time preventing failure after you violated it. Intelligence and education are necessary to acquire this experience, but they cannot replace it. And yes, that is an "argument from  authority", because none other is possible and the fact is valid. My apologies for that. The only thing that can replace experience is more experience.  

I really don't care any more. The amount of typing you put into your responses without ever making a point is astounding. "If it aint broke, don't fix it" doesn't apply here because it is broken. All i've heard from you in this entire thread is that it could possibly maybe in certain specific but general and vague situations under the sun it may or may not cost more CPU.

1 hour ago, ishakaru said:

Your math is just wrong man, a resource value has no bearing on how expensive(on your computer) it is to move it. You also missed the entire point of what was said: The proximity check is already being made. The suggestion changes nothing in terms of load on the computer. 

This. Though it has already been stated several times already.

[Gurgel]

1 hour ago, Xuhybrid said:

I really don't care any more.

I don't mind. I don't care what you think either.

[CDoroFF]

2 hours ago, ishakaru said:

Your math is just wrong man

As I said it is just guess, however nobody here have an idea how it works, but everyone ensured that change the way how it works costs nothing in terms of CPU or Programmer work resources.
 

2 hours ago, ishakaru said:

The proximity check is already being made.

For each debris on a map and each container? For what? And how are they using it now (if they calc smth, they have to use result, right?)? Ofcourse, if it is calculated already it costs nothing, but I tend to believe it's not and developers can not afford it due to too mach CPU cost. The problem is that we can not support our ideas by facts such as code listing or Klei devs words. The idea to sweep item to the nearest storage is too obvious to ignore it without reason. This topic is not first where people discuss that behavior, moreover, some time ago i made another one and who knows how many was posted before. I would be glad if there was just "not a right time" for this change, and keli will fix it tomorrow. We'll see. 

 

1 hour ago, Xuhybrid said:

This. Though it has already been stated several times already.

I do not deny the fact what game make some proximity calculatins, my view based on this statement. I just doubt game calculates relations between sotrages and debris also, furthermore, I doubt these additional calculations is easy.
 

[PhailRaptor]

21 minutes ago, CDoroFF said:

I do not deny the fact what game make some proximity calculatins, my view based on this statement. I just doubt game calculates relations between sotrages and debris also, furthermore, I doubt these additional calculations is easy.

I seriously doubt anyone is suggesting that is the case.

When the player assigns a Sweep task to Debris, the game has to figure out how to accomplish that.  It will pick a Dupe, and send that Dupe to complete the task.  The breakdown is how the game decides what Compactor the Dupe will take the Debris to after it has been Swept.

Here's the thing, though.  The game has to already know where the Debris is located, in order to send the Dupe there to perform the task.  And we know the game already makes proximity decisions frequently, because when the Dupe is assigned the Sweep task, the Compactor they will deliver to is in proximity to where the Dupe was when the task was assigned.

So why, then, is it so complicated and so confusing to shift the proximity detection calculation away from the Dupe's current location to the location of the Sweep task instead?  The only way the current arrangement makes any sense is if the devs intend for us to dedicate specific Dupes to specific areas through door permissions.  But I feel like that would be a rather strange and arbitrary restriction to put on players, and I don't see what is gained from doing that.

[ToiDiaeRaRIsuOy]

[CDoroFF]

5 minutes ago, PhailRaptor said:

The game has to already know where the Debris is located, in order to send the Dupe there to perform the task.

Not only. Game should know where is free compactor also, else there is no reason to perform a task at all and dupes will drop debris right after picking it up.

 

21 minutes ago, PhailRaptor said:

So why, then, is it so complicated and so confusing to shift the proximity detection calculation away from the Dupe's current location to the location of the Sweep task instead?

If game gain all the knowledge about compactor and debris location related to dupes in the first part of each tick, then it can easily compose the task with the precalculated values. Take nearest debris, carry it to the nearest storage. Done.
If you want to fix it, then you have to precalculate not only dupe-debris + dupe-storages relations, but also all available debris-storages routes, and only then pick the nearest available storage. Due to the fact that storages significantly outnumber dupes it is quite heavy task, especially at the late stages with millions debris and hundreds of storages. 
As I said shortes ways for 12dupes*to10000debris + 12dupes*to200storages is much less than the same plus 10000debris*to200storages routes.

[ishakaru]

Just now, CDoroFF said:

Take nearest debris, carry it to the nearest storage. Done.

Good... keep going...

Just now, CDoroFF said:

If you want to fix it, then you have to precalculate not only

WRONG TURN! WRONG TURN!

 

The bit about taking it to the nearest storage is the part that isn't happening. All of the pathing is determined before the dupe moves an inch.

 

An example is that the dupe is standing next to a compactor that can accept the type of material they are scheduled to pick up which is 200 tiles away. There is a compactor with identical permissions as the first one sitting next to the debris. What happens: The dupe will travel the 200 tiles back to his starting point with the debris. 

 

What we want to happen: Dupe sticks the material into the compactor next to the debris.

What happens: Dupe runs back 200 tiles to their starting position to stick the debris in the compactor there.

 

There is no need for precalculation beyond what is already happening in the game. No need to store any calculations(because we aren't doing it). The solution is that when a dupe gets a task to pick up a resource, they use the location of the debris as the location to choose which compactor the resource goes into. In the case of build and supply tasks, they should use the destination as the position to start from for the resource, then path from the resource to the dupe.  The calculations are already being done, just in the opposite direction of what people want. 

[CDoroFF]

21 minutes ago, ishakaru said:

There is no need for precalculation beyond what is already happening in the game. No need to store any calculations(because we aren't doing it). The solution is that when a dupe gets a task to pick up a resource, they use the location of the debris as the location to choose which compactor the resource goes into. In the case of build and supply tasks, they should use the destination as the position to start from for the resource, then path from the resource to the dupe.  The calculations are already being done, just in the opposite direction of what people want. 

I have already asked you and still have no answer. And again you disprove me without saying - when and for what they did that calculations? How game choose which debris require storage and which are not if the jobs tasks still not given? It have to precalculate it then. Or game just uses resourceless magic to predict which deris require additional calculations about the nearest storages? I'm pointng out: game should know all the distances between debries storages before giving a task to dupe since it cannot be incomplete. If it is, then become possible situation when dupe picks debris up and instantly drops it since there is no avaliable compactors\buildings for it. 

[Boxman_90]

@CDoroFFNo additional pre-calculations are required for doing what we ask - changing the anchor-point for the proximity-calculation from dupe to sweep-task doesn't require any new information. This should be obvious as the game is already demonstrably capable of finding a compactor based on a location (the dupe's current location), so I fail to see why you would suddenly have to calculate&save everything (?). The calculation to determine the compactor can be the same, just starting somewhere else.

Quote

If you want to fix it, then you have to precalculate not only dupe-debris + dupe-storages relations, but also all available debris-storages routes, and only then pick the nearest available storage.

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.

I think this is simply not true. It would be a giant waste of resources, since the world constantly changes and dupes constantly move. If it works your way, 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. That whole narrative of these 'lists' of locations and paths continuously kept at ready even when there's no task issued makes very little sense to me.

You should not waste resources on something you're not going to use, such as these lists. It's way cheaper to just calculate the distances whenever a dupe actually needs to do a task, instead of doing it constantly for no reason.

We see from in-game behavior that a distinct calculation is made for the distance between the dupe and the compactor. We want this calculation changed to the distance between the task and the compactor. In both cases, the location of the dupe and task are already known.