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

[PhailRaptor]

7 hours ago, Craigjw said:

12 hours ago, Boxman_90 said:

2) Dupe x assigned based on some proximity and idle-queue parameters, storage is determined first on availability, then priority, then location based on the dupe's current location. Depending on the amount of space available in the compactor, the size of the sweep task can be altered leaving half a sweep task behind (this seems to happen quite often).

you mean, when you issue a sweep command in an area, a dupe can carry 1200kg of stuff, then only picks up 50kg and leaves the other stack of 800kg only to return later to pick up 400kg of it.

Not sure how this would affect the calculation, but it must be possible to also check the Dupe's capacity as if it were a container, and compare the currently assigned task with other similar tasks.  In this way, tasks with similar routes could be consolidated within that Dupe's capacity.  I have (or at least, used to) witnessed similar behavior already -- Dupe picks up a lot of stuff, runs to a compactor and drops a little bit of the stuff, then runs to a different compactor to drop the rest of the stuff.

Again, it all comes back to where the "proximity" factor is calculated from.  I don't see any logical reason why the Sweep task's destination should be determined by the current location of the Dupe receiving that task.  It should be based on the location of the Sweep command itself.

[Gurgel]

6 hours ago, Yunru said:

But that is the issue, just look at the thread title. The question is why won't they find the nearest container from the item they're collecting, rather than from them, the collector.

Well, it goes into all these questions about queuing, real-time constraints, path-reuse (what some here like to call caching), etc. When computation performance does not matter, going from the item to the container is better, no question. What I am trying (and apparently failing) to point out is that this is not a thing where you can just ignore all these questions. For example, I guess they will be doing partial path pre-computation when they have cycles to spare. That would be something to be done starting from each container (because there are fewer containers and they stay in use longer and they are stationary). But as soon as you have more than a few containers, they probably have to select some and that will require some criteria. Now you cannot select the containers with the best connections to the world, as that requires computing which ones these are and that is likely prohibitively expensive. One possibility would be to use those that have many other containers next to them and reachable from them, because then you only get a small error when you just pre-compute paths for one of a group. This is something that probably does not work at all if you do it the other way round (starting from the item). Now, it may just happen that dues to all the constraints, small groups or even individual containers do not get the pre-computation at all or a much worse one. That then causes delivery with longer paths, because the game just does not see the closer one. 

Of course, this is still all grossly simplified. And it is speculation. And there is the problem. I do realize that a statement by an expert of "this is a hard problem" is not very satisfying, especially as there are "experts" that misuse this stance, most extremely those that claim from authority that "there is a god", but today also many others. On the other hand the "you must explain it" stance is not a solution either. Some things takes years (sometimes decades) to get a reasonable familiarity with and at the same time there are no simple, hard rules. Most planning and optimization algorithms are in that class. You think you know how to do it, it seems simple. Then you try it. Then you fail. There are no real hard rules why you fail, but you do. You read up on it and you find other people experience the same. Then you scale back your quality requirements and use heuristics. You continue to fail for a while, but eventually you find something that works, even if its results are often not optimal and sometimes grossly bad. But you have something that works! And that way people find that some things are hard problems and they usually come in classes. It is not something that can be explained in a few sentences or even in a few days. (There are also results from theoretical CompSci, but they are often misleading.)

So, statements by experts are problematic because there are quite a few problematic "experts". But in many cases, the experts actually know what they are talking about and there is nothing better unless you are willing to invest a significant part of your life and you have specific talents and capabilities. That said actual experts get ticked off when some amateurs come along and claim "this must be easy", when they know this is not true although there is no easy way to explain why does add to the problem. But that is the reality of the thing. 

3 hours ago, PhailRaptor said:

Dupe picks up a lot of stuff, runs to a compactor and drops a little bit of the stuff, then runs to a different compactor to drop the rest of the stuff.

That one is easy: At planning time, the dupe did not get a reservation for the full delivery in one container, but (probably due to some heuristic) could get a reservation for the rest nearby.

[CDoroFF]

1 hour ago, Gurgel said:

What I am trying (and apparently failing) to point out

It's not your fault. Today's GameDev is way too complicated to the majority of people. Also https://en.wikipedia.org/wiki/Dunning–Kruger_effect inherit them to understand the complexity. I have got a diploma in CS and i'm not a programmer, so that means what I'm somewhere in "valley of despair" now. pic rel.
Talking about the pathfinding: I have made the same topic and the result of discussion was the fact that right before dupes gone mad, I made sweep order and canceled it. Seems it ruins debris priorities or something like that. There is apparently hidden priorities. Do you remember a trick with deconstruction of valves to rise their priority? Some patches ago valves had no priority and to set it you had to order to deconstruct it, set prio and cancel the order then. I tend to believe that various derbis works similar and their prio just beats other debris proximity.

[Boxman_90]

2 hours ago, Gurgel said:

For example, I guess they will be doing partial path pre-computation when they have cycles to spare. That would be something to be done starting from each container (because there are fewer containers and they stay in use longer and they are stationary). But as soon as you have more than a few containers, they probably have to select some and that will require some criteria. Now you cannot select the containers with the best connections to the world, as that requires computing which ones these are and that is likely prohibitively expensive. One possibility would be to use those that have many other containers next to them and reachable from them, because then you only get a small error when you just pre-compute paths for one of a group. This is something that probably does not work at all if you do it the other way round (starting from the item). Now, it may just happen that dues to all the constraints, small groups or even individual containers do not get the pre-computation at all or a much worse one. That then causes delivery with longer paths, because the game just does not see the closer one. 

The reason I'm asking you to explain things, is because it allows us to pin-point the flaws in the logic that made you, the 'expert', come to a certain conclusion. 'Experts' too are just humans, after all, and make mistakes just as often as anybody else. This is why you can't publish anything without peer review. 

Your argument quoted above fails from simply observing in-game behavior. You made a hypothesis on how the game handles the task that in reality does not apply to this game, which is easily observed by the game consistently (!) picking the compactor closest to the dupe, at all times and without exceptions, whether they're grouped, solo, far or near to the base. It means it does work 'the other way around', i.e. some sort of proximity calculation that's starting from the dupe. A dupe starting its task far outside the base, with a compactor close to him, always chooses this specific lone compactor since it's closest when it accepts the task, never a random 'bulk compactor' in my >100 compactor storage room. Exceptions arise when the dupe is interrupted. You can confirm this yourself with simple tests in-game, and I urge you to do so.

You don't have to be a CS major to spot someone's flaws in the logic they used to construct the premise for their conclusions. Which is exactly why appealing to your authority to say "i'm right" and further refusing to show any of your reasoning/work is utterly foolish - it's taken us half the thread to come to this point. It wouldn't ever fly in any scientific or professional environment either for this exact same reason.

Anyway, we've come full circle again, back to the simple initial query of the topic:

• Observing from in-game behavior that a proximity-based calculation is made when deciding a compactor (and some quick sandbox testing shows it's actually some sort of path-finding calc rather than absolute proximity)
• Observing the point-of-origin of this calculation is the "dupe"
• Observing that the sweep-task location should be known before starting the task
• Can the point-of-origin for the proximity-calculation be assigned to the 'task' rather than the dupe?

 

[Sasza22]

4 hours ago, Gurgel said:

Of course, this is still all grossly simplified.

This discussion is getting out of hand. At least we are past the insult zone now and can get to some conclusions. I`m also impressed how the "grossly simplified" version is already 10 times more complex than most people would assume.

So the pathing system looks simple for a person observing dupe behaviour. It`s obviously not. Even then stuff like dupes getting stuck not able to select a route is happening and some of the pathing seems illogical, dupes don`t account for ladder jumping over walking on tiles with speedboosts etc.

Now the main issue seems to be a basic logical problem. The dupe gets a task to sweep a certain object and put it in a container. He needs to find a path to the object, select how much of it he can carry and find a container to put it and a path from the object to it. The system is working fine just the container appears to be always closer to the dupe than to the object.

Now the altered behaviour wouldn`t be much different. The dupe gets the task. He needs to find a path to the object (no difference here). Select how much he can carry (again no difference), find a container to put it in (here is the difference, the container needs to be closer to the object than the dupe) and finally the path to it (pretty much same calculation but a different destination).

Now this doesn`t sound like it has to involve heuristics, time calculations and advanced maths or at least more than the current system (maybe it does i don`t know for sure). The only problem i see with it is the sweeped object also being mobile. Destroying a tile under it, closing a door on it or it getting hit by meteors might displace it breaking the entire path. Maybe that`s the reason it can`t be considered as an origination point of the calculation but again is it more complicated than random path blocking breaking the task as well?

[Yunru]

11 hours ago, Gurgel said:

Well, it goes into all these questions about queuing, real-time constraints, path-reuse (what some here like to call caching), etc. When computation performance does not matter, going from the item to the container is better, no question.

None of that matters. It already calculates the nearest container from a point and calculates a path to the item and to the container.

And none of that changes.

The only difference is the point becomes where the item is instead of where the dupe is.

 

You give a whole lecture on pathfinding and it's entirely irrelevant.

 

What, in laymen's terms, is the issue with changing the coordinates they use to determine "nearby" for a sweep order from the dupe to the item?

[Yunru]

9 hours ago, Sasza22 said:

The only problem i see with it is the sweeped object also being mobile. Destroying a tile under it, closing a door on it or it getting hit by meteors might displace it breaking the entire path. Maybe that`s the reason it can`t be considered as an origination point of the calculation but again is it more complicated than random path blocking breaking the task as well?

I don't see how. Either way it has to recalc.

[Gurgel]

12 hours ago, Boxman_90 said:

The reason I'm asking you to explain things, is because it allows us to pin-point the flaws in the logic that made you, the 'expert', come to a certain conclusion.

And fail. Since I have to grossly simplify everything, you cannot actually do that. All you will find is effects of the simplification. But since you are obviously not after truth but after dominance, I will now stop caring. 

[Yunru]

4 minutes ago, Gurgel said:

And fail. Since I have to grossly simplify everything, you cannot actually do that. All you will find is effects of the simplification. But since you are obviously not after truth but after dominance, I will now stop caring. 

Sure. That's why in all the words you said, none address the point?

[Xuhybrid]

I'd still like to know why searching for a container near an item is any different to searching for a container near a duplicant.

The answer is, it's not.

[Gurgel]

11 hours ago, Sasza22 said:

Now this doesn`t sound like it has to involve heuristics, time calculations and advanced maths or at least more than the current system (maybe it does i don`t know for sure). The only problem i see with it is the sweeped object also being mobile. Destroying a tile under it, closing a door on it or it getting hit by meteors might displace it breaking the entire path. Maybe that`s the reason it can`t be considered as an origination point of the calculation but again is it more complicated than random path blocking breaking the task as well?

The thing here is that you cannot really do all these calculations in full. So you have to make a lot of trade-offs to get reasonable performance. One could well be to regard containers as more stable as objects-to-sweep (which makes sense) and hence you may get huge benefits from pathing from the container and not from the object. Of course that will interact with other things, so what you actually observe is a complex mix of different techniques.

The base problem here is that the perfect solution is deceptively simple. It is understandable for basically anybody. It is however extremely slow and hence heuristics, short-cuts, pre-computations, etc. all come into it to get computing time down. There are planning algorithms that accept extremely low quality, because that is the only fast way to get a solution at all. It is one of these typical problems where some people just cannot accept that things are hard to do because the perfect solution seems so simple. They then ignore everything around and focus on some seemingly simple detail and demand to know why it cannot be done that way. Now, anybody that actually tries to implement this will find out, and have their "Oh, the experts are actually right!" moment of insight. But all the armchair-engineers here are not willing to do that and instead resort to cheap and unjustified attacks. It is not even a technological problem, it is a psychological problem. The reference to the Dunning-Kruger effect above is perfectly correct.

19 minutes ago, Yunru said:

Sure. That's why in all the words you said, none address the point?

They all do. You just know far, far too little to understand that. 

13 minutes ago, Xuhybrid said:

I'd still like to know why searching for a container near an item is any different to searching for a container near a duplicant.

The answer is, it's not.

Are you _serious_?????

[Yunru]

11 minutes ago, Gurgel said:

The thing here is that you cannot really do all these calculations in full. So you have to make a lot of trade-offs to get reasonable performance. One could well be to regard containers as more stable as objects-to-sweep (which makes sense) and hence you may get huge benefits from pathing from the container and not from the object. Of course that will interact with other things, so what you actually observe is a complex mix of different techniques.

The base problem here is that the perfect solution is deceptively simple. It is understandable for basically anybody. It is however extremely slow and hence heuristics, short-cuts, pre-computations, etc. all come into it to get computing time down. There are planning algorithms that accept extremely low quality, because that is the only fast way to get a solution at all. It is one of these typical problems where some people just cannot accept that things are hard to do because the perfect solution seems so simple. They then ignore everything around and focus on some seemingly simple detail and demand to know why it cannot be done that way. Now, anybody that actually tries to implement this will find out, and have their "Oh, the experts are actually right!" moment of insight. But all the armchair-engineers here are not willing to do that and instead resort to cheap and unjustified attacks. It is not even a technological problem, it is a psychological problem. The reference to the Dunning-Kruger effect above is perfectly correct.

They all do. You just know far, far too little to understand that. 

********. None of your posts have addressed the issue. It's all waffling about pathfinding. Pathfinding that is already implemented.

But I'll give you one last chance:

Show how changing where the algorithm determines "nearest" from would be so complex as you claim. You can even use (pseudo)code, as long as you use variables for dupe position and item position.

[Xuhybrid]

Still waiting.

[Gurgel]

Just now, Yunru said:

********. None of your posts have addressed the issue. It's all waffling about pathfinding. Pathfinding that is already implemented.

But I'll give you one last chance:

Show how changing where the algorithm determines "nearest" from would be so complex as you claim. You can even use code, as long as you use variables for dupe position and item position.

I do not want your last chance. No, not even one bit. But I should remind myself to stop arguing with incompetents.

1 minute ago, Xuhybrid said:

Still waiting.

You will get nothing. You do not have what it takes to understand the answer.

[Yunru]

Just now, Gurgel said:

I do not want your last chance. No, not even one bit. But I should remind myself to stop arguing with incompetents.

Uh huh. So what you're saying is, you're unwilling to provide proof to your claim?

Then your claim is irrelevant.

[Sasza22]

5 minutes ago, Gurgel said:

The base problem here is that the perfect solution is deceptively simple. It is understandable for basically anybody. It is however extremely slow and hence heuristics, short-cuts, pre-computations, etc. all come into it to get computing time down. There are planning algorithms that accept extremely low quality, because that is the only fast way to get a solution at all. It is one of these typical problems where some people just cannot accept that things are hard to do because the perfect solution seems so simple. They then ignore everything around and focus on some seemingly simple detail and demand to know why it cannot be done that way. Now, anybody that actually tries to implement this will find out, and have their "Oh, the experts are actually right!" moment of insight. But all the armchair-engineers here are not willing to do that and instead resort to cheap and unjustified attacks. It is not even a technological problem, it is a psychological problem. The reference to the Dunning-Kruger effect above is perfectly correct.

Ok i can uderstand that the problem is more complicated than just moving a variable in the code and hoping it works. I can also observe that the pathing algorithm takes many shortcuts like not considering the tile speed bonus or fire poles being hardcoded as a preferred way to move down.

My biggest problem is how you explain it to us. You are basically saying "you are all too dumb to understand why you are wrong" and "it`s magic it works or it doesn`t". There are some pretty smart people in here and i`m sure we could try to tackle the problem in a realistic scenario but the discussion is in a void. We don`t know the specifics of how the system exactly works in ONI and you didn`t provide any example to support your statement of it being insanely complicated. So we just discuss about something invisible. We can`t see it being complex without proper examples.

Maybe i`m not capable of understanding that stuff but other people in this thread won`t give up until you prove them wrong in a way they can understand (or understand it`s beyond their undrstanding if that makes sense).

[Gurgel]

7 minutes ago, Sasza22 said:

(or understand it`s beyond their undrstanding if that makes sense).

That, I cannot do. The way you do it to CS students is to have them try and fail in a project spanning several months. Some get it after that. Not all do. The thing is, all modern engineering stands on the shoulders of giants. You need to know their work to be able to use it and improve upon it. This has nothing to do with "dumb".  

[Yunru]

1 hour ago, Gurgel said:

Are you _serious_?????

As a heart attack.

Feel free to explain how calculating something relative to one position is sooo much more impossible than... calculating something relative to one position... despite the current system already being able to do it from any point in the simulation...

[Boxman_90]

Blah blah blah. All this guy @Gurgel does is beat around the bush while hiding behind a self-proclaimed 'status', arguing fallaciously from it as if that counts as sound argument, calling those who call him out on his nonsensical circular reasoning 'dumb' left and right while assuming lord-knows-what about their levels of competence while he's at it, and consistently finishes with "therefore I won't address my point, but just pose it as fact without any reference".

He proclaims himself an expert on the topic but is unable to address any of the issues raised. I feel like all he wants is to self-proclaim himself 'smart' and orate that online by calling others dumb, while he's literally the only one in this thread failing to articulate his own point.

I mean, I wish this guy was just a troll but he actually seems dead serious about his own 'out-of-reach-smartness' and everyone else's dumbness.

Edit// Oh yeah, and;

1 hour ago, Gurgel said:

And fail. Since I have to grossly simplify everything, you cannot actually do that. All you will find is effects of the simplification. But since you are obviously not after truth but after dominance, I will now stop caring. 

This one was also pretty rich, and telling. "The effects of simplification" apparently led him to describe behavior that's demonstrably not in the game, but when confronted with that he hides behind 'not caring anymore' as to not having to address the point. I'll just leave it here, he said:

Quote

Now, it may just happen that dues to all the constraints, small groups or even individual containers do not get the pre-computation at all or a much worse one. That then causes delivery with longer paths, because the game just does not see the closer one.

So he's arguing that some 'pre-calculation' task starts from the container, not from the actual task, concluding that 'some' containers are left out of the scope of the search and therefore 'may' be dropped altogether, since the game 'does not see it' and that this would be the reason why closer containers are skipped, sometimes, depending on specific situations with lots of compactors.

Simply booting the game and starting a sweep task in a test-envoronment, however, it is super easy to demonstrate that the game does indeed does see all, and behaves predictably, with the behavior as described by me and others being reproducible 100% of the time with as little as two compactors.

 

[Gurgel]

16 hours ago, CDoroFF said:

It's not your fault. Today's GameDev is way too complicated to the majority of people. 

Ah, yes. I am somewhere on the slope (after having been in this for > 30 years). Of course I would look stupid and patronizing to people on the peak... Funny thing is that I have had this type of discussion with students that were fully aware of my qualifications. But that at least made them listening carefully and so far I have managed to convince them all. Of course, I do teach in year 3 and later, the really hardcore cases are long gone by then and those that remain usually have learned that things in the software-sphere are typically more complicated than they seem on first glance. 

[JoeW]

Please keep posts polite and on topic. Thanks. 

[Le0n1des]

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

[Yunru]

17 minutes ago, Le0n1des said:

"find nearest non full container with highest priority"

Your algorithm's off. I know because your way makes sense. But it doesn't find the nearest item from the container, it finds the nearest container from the dupe. Why? IDK, guessing it's a C+P from other delivery errands.

[Le0n1des]

38 minutes ago, Yunru said:

But it doesn't find the nearest item from the container, it finds the nearest container from the dupe.

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.

[Miravlix]

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.