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

[Sasza22]

Stop the silly discussion. The system works the way described. It`s one of the base systems of the game. Altering it at this point is hard and might cause a ton of bugs. Maybe instead of arguing if the system can or can`t work differently try to find ways to optimise bases with how it is now.

[cpy]

2 minutes ago, Miravlix said:

 

Why are you trolling the topic so hard?

Because I can think of algorythm to do this check? I'm not a game programmer but seems to me it can be done. With path caching ofc.

[ONIfreak]

system does not need to be really sophisticated for this.

1. When you make "sweep" of some materials system should check straight away if there is room for it in storage compactors (and do this re-check every time you build/destroy/change anything in storage compactors)

2. Dup use sweep priority to find out if it needs to do it now, or later

3. if needs to sweep - pickup material for storage compactor which has the highest priority

4. calculate which storage compactor has the highest priority and after which one is the closest.

5. dup goes to the closest available storage compactor

 

This is how i would see this algorithm in game.

[Xuhybrid]

7 hours ago, Sasza22 said:

Stop the silly discussion. The system works the way described. It`s one of the base systems of the game. Altering it at this point is hard and might cause a ton of bugs. Maybe instead of arguing if the system can or can`t work differently try to find ways to optimise bases with how it is now.

So instead of asking for a solution, just suck the **** you've been presented with.

[Sasza22]

1 hour ago, Xuhybrid said:

So instead of asking for a solution, just suck the **** you've been presented with.

I mean they just insult each other arguing if different coding is possible or not. It`s pretty pointless. We could discuss ways to deal with the current system instead. I hate when discussions devolve into insult spirals. Maybe i should just shut up. Just trying to make the discussion a bit more constructive.

The system might be hard to alter at this point since it`s in the game from the start. Remember how many bugs surfaced when they altered the fabricators. I`m not saying they shouldn`t tackle it but we already have some tools to manage it. Conveyors, prorities, access restrictions. It`s still clunky but managable.

[Xuhybrid]

It didn't sound like you wanted more constructive discussion. It seemed like you were just dismissing the need for a discussion altogether. Establishing whether or not the system is possible is irrelevant, you are right. However, consider the following situation among the ones already discussed. I set down a few compactors inside an ice biome, in order to collect Liquifiable solids. However, the current pathing decides to carry that ice from that biome into a compactor in another biome, across the map somewhere. That ice now melts on the way, because the completely empty storage compactor was ignored. Even though the round trip for going to the ice and then the compactor would have resulted in a very small trip.

I know that lag is a concern but during QoL updates and finishing up the game for release, this is one of the features that need addressing. Dupe intelligence is outside of our control. The suggestion to use priorities in the example i just provided falls flat. Now all the liquifiable items are going to get carried from the other biome into this one and melt along the way, creating the same problem we were trying to avoid. The only method i've been able to figure out, to fix the dupe intelligence, is to use Sweep Only. Then manually disable the other compactors in the other biomes while i sweep an ice biome. Why should i be doing this kind of micro-management?

[Gurgel]

12 hours ago, Miravlix said:

Stop with this silliness.

You can't pickup and item and THEN decide where it needs to go.

The game is based on HAVING a destination and finding the item to deliver, you can't make it work the other way around.

Yes. And it needs to be done this way because the game is a (soft) real-time application. You can make it work the outer way round, but you get a lot of long, wasteful calculations in the worst case, bogging everything down to a crawl. Real-time almost always means to accept worse solutions if you can get them in a fixed amount of time. This is all pretty well known and understood, although it is a topic most coders never venture into.

12 hours ago, cpy said:

Because I can think of algorythm to do this check? I'm not a game programmer but seems to me it can be done. With path caching ofc.

Sorry, this is an advanced topic. You really do not understand what you are talking about here. The complexities and problems that turn up when you get into the details here (usually advanced elective part of a Master's in CS for the easy stuff, not earlier) are extreme and surprising. For example, paths are not "cached" at all. They are _decided_ on. And unless you want to verify the path is the best every second (which is about as much effort as a complete new path calculation, i.e. completely forget about doing it), you stick with them unless they turn out to not be implementable anymore at execution time (a much, much faster check).

4 hours ago, Sasza22 said:

The system might be hard to alter at this point since it`s in the game from the start. Remember how many bugs surfaced when they altered the fabricators. I`m not saying they shouldn`t tackle it but we already have some tools to manage it. Conveyors, prorities, access restrictions. It`s still clunky but managable.

And the current system has a decisive advantage: It works and it does not bog down the game. That is in no way something you can be sure of if this is changed. It may take a year or two to get a changed system to work. And it may turn out that it is not possible after all. And _then_ it may turn out that you cannot reliably get back to the old solution. I bet Klei is pretty happy with what they have, considering the alternatives.

[Yunru]

I can't see it being that hard to change finding the closes storage from X to finding the closest storage from Y (with X being dupe position and Y being the item position).

[cpy]

4 hours ago, Gurgel said:

Sorry, this is an advanced topic. You really do not understand what you are talking about here. The complexities and problems that turn up when you get into the details here (usually advanced elective part of a Master's in CS for the easy stuff, not earlier) are extreme and surprising. For example, paths are not "cached" at all. They are _decided_ on. And unless you want to verify the path is the best every second (which is about as much effort as a complete new path calculation, i.e. completely forget about doing it), you stick with them unless they turn out to not be implementable anymore at execution time (a much, much faster check).

If you don't know how to do path caching and you claim Masters in CS, you should probably return your degree. Or don't they teach how to use your brain instead of repeating textbooks? You can't learn things in school that were not yet invented, you invent them.

There is no such thing as extreme problem, everything is just a simple thing made to do complex things. You just need to know how to breakup problem to be managable.

 

[KittenIsAGeek]

18 hours ago, Miravlix said:

Stop with this silliness.

 

You can't pickup and item and THEN decide where it needs to go.

 

The game is based on HAVING a destination and finding the item to deliver, you can't make it work the other way around.

Lets say a sweep order has been set.  Its just as easy to pick a destination for the sweep order based on the debris location as it is from the dupe's location.  Sweep order, destination choice, queue job for dupe.  Or you could do it: Dupe gets sweep job, then game picks destination based on debris location instead of dupe's.  Destination found, so dupe runs to pick up item.  Basically the only thing you have to change is where you start your closest destination search from: Dupe or item.

[cpy]

Or you can combine them. One thread can be computing tasts and navigation for the task. Another thread can calculate how dupe will get to those tasks and he could do tasks that are closer to him. But I guess memory footprint of too many cached paths can be nasty.

[Sasza22]

14 hours ago, Xuhybrid said:

It didn't sound like you wanted more constructive discussion. It seemed like you were just dismissing the need for a discussion altogether.

Mea culpa. I worded it wrongly. I wanted to end the spiral of insults by showing how pointless it was. I didn`t mean to dismiss the entire discussion.

[Boxman_90]

19 hours ago, Yunru said:

I can't see it being that hard to change finding the closes storage from X to finding the closest storage from Y (with X being dupe position and Y being the item position).

This. I mentioned the same a few months ago. The 'system' obviously already searched for the item to sweep, as it knows what it's going to store and in what quantity when choosing a compactor (it needs to know if there is space for the sweep task before choosing the compactor). With the sweep known, changing the compactor search origin from "dupe" to "sweep task" should be absolutely trivial. I'm not sure what @Miravlix means with "The game is based on HAVING a destination and finding the item to deliver, you can't make it work the other way around" - maybe he can explain why it can't work that way? The search for the resource has to be made in any case. Why can't that occur before looking for the nearest empty compactor?

[Nutter]

Non-programmers telling programmers that some insanely resource-intensive calculation is "simple" was always one of my favorite things. (NOT)

[Boxman_90]

11 hours ago, Nutter said:

Non-programmers telling programmers that some insanely resource-intensive calculation is "simple" was always one of my favorite things. (NOT)

Likewise, people who only fence with fallacies such as a Call to Authority ("I'm a programmer so I must be right") without actually backing up any of their statements at all, are one of my favorite things.

[Gurgel]

On 1/4/2019 at 7:46 AM, cpy said:

If you don't know how to do path caching and you claim Masters in CS, you should probably return your degree. Or don't they teach how to use your brain instead of repeating textbooks? You can't learn things in school that were not yet invented, you invent them.

You know, insulting people does not make you right.  You just did not understand my comment and you do not know what "caching" means. Paths get selected and then queued, they do not get cached. It is a pretty important difference. Also, I did not claim a Master's in CS. I actually have a bit more. But since you do not respect established Science, that does not matter anyways.

12 hours ago, Nutter said:

Non-programmers telling programmers that some insanely resource-intensive calculation is "simple" was always one of my favorite things. (NOT)

The incredible incompetence and unawareness of it that amateurs often have is staggering. Nothing new. My most favorite reference is this one here: https://dilbert.com/strip/1994-10-17  Describes the present situation nicely.

1 hour ago, Boxman_90 said:

Likewise, people who only fence with fallacies such as a Call to Authority ("I'm a programmer so I must be right") without actually backing up any of their statements at all, are one of my favorite things.

Some things are known to be hard. This is one of them and experts know it. If an expert says they are hard, is is not the opinion of that expert, if is a reference to the known state-of-the-art. Read up on it and you will find that this is a known hard problem. Seriously, you are like a person telling a modern MD that bloodletting is the solution to all medical problems. And when that MD tries to explain the fault in that, you say that the MD is using an "Argument from Authority" (please at least get you fallacies right...) and that he should just try it because obviously it works. 

[Boxman_90]

3 hours ago, Gurgel said:

Some things are known to be hard. This is one of them and experts know it. If an expert says they are hard, is is not the opinion of that expert, if is a reference to the known state-of-the-art. Read up on it and you will find that this is a known hard problem. Seriously, you are like a person telling a modern MD that bloodletting is the solution to all medical problems. And when that MD tries to explain the fault in that, you say that the MD is using an "Argument from Authority" (please at least get you fallacies right...) and that he should just try it because obviously it works. 

The problem with this is that nobody tried to actually explain it. They (including you) just say "it's too hard, I know what I'm talking about, just believe me, don't ask again". It contributes nothing. Your only argument here is your pedantic attempt to correct someone on the possible different spellings for the same fallacy, which isn't even correcting anything since "appeal to authority" is just as common and "call" is one of the top synonyms for "appeal". It's just English, and apparently you knew exactly what I meant, though I am a bit surprised that I, as a non-native speaker, apparently have to explain how language works.

Anyway, I'm not into mud-slinging, but your entire post is a call to authority and nothing more, while you contributed zero new information to the discussion. If an 'expert' can't explain something in layman's terms, then perhaps the expert doesn't have a deep enough understanding of the topic at hand himself. A good physicist, for instance, could explain the basics of quantum physics to a novice with use of appropriate analogies and justifiable simplifications - if and only if he deeply understands quantum-physics himself.

On a forum you should always be willing to back up your statements instead of simply posing them as facts and expecting people who don't know the darnest thing about you to just take you for your word because you proclaimed yourself an 'expert' online.

[Arcus2611]

On 02/01/2019 at 4:32 PM, madcat1188 said:

Seems logical to me that the decision about what storage compactor to put a chunk of granite in could be made after the duplicant picks up the chunk of granite as opposed to when it gets assigned the task.

But what if there isn't a storage compactor available after they pick up the granite, because another dupe went and topped off the only available compactor while they were on their way to pick up the granite?

Checking for the sweep task first before the destination would actually be far worse, because you would have dupes running up to the surface to pick up regolith, realising that there's nowhere to store the regolith, dropping the regolith and repeating the cycle. The only way to avoid such nonsense is to check if there's storage space available first, but if you do that it makes more sense to then allocate some of that space to the sweep task immediately rather than waiting until the sweep task is performed to check again.

[Boxman_90]

It would seem logical to me that the task is planned out before the dupe starts it. I.E. the sweep location, amount, and storage known and reserved before the dupe actually starts the task, in order to avoid conflicts with other dupes. At the moment it seems like the decision process looks something like this:

1) There is a sweep task, with a certain priority. "We should solve this sweep task" -> assign dupe. (I do not think "This compactor is empty, let's assign a sweep task to it" sounds like a logical approach, since the sweep task has its own priority and the compactors priority needs to be taken into account after deciding on the sweep task).

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).

3) Sweep, Dupe an Storage location now known, sweep task and storage are reserved, pathing kicks in to find the shortest route and the dupe starts the task.

At 1), the amount and location of the sweep task is known. I still fail to see why the location of the sweep task itself cannot be used in 2) to locate the closest storage, rather than the dupe's initial location.

What makes "sweep task (prio, location, amont) -> assign dupe -> determine compactor (availability, priority, location based on dupe) -> reserve task & storage -> pathing -> execute" so extremely more difficult than the exact same thing but "location based on task" instead of "dupe"?

 

Even just using absolute proximity without pathing (just "x tiles distance from task/dupe"), so you don't have to do complete pathing from two origins (dupe and task) for one task would be streets ahead of the current situation, and only cause inconvenience if your base layout is highly erratic.

 

[Craigjw]

On 04/01/2019 at 9:24 AM, cpy said:

Or you can combine them. One thread can be computing tasts and navigation for the task. Another thread can calculate how dupe will get to those tasks and he could do tasks that are closer to him. But I guess memory footprint of too many cached paths can be nasty.

D* or D*-Lite are good examples of this.  it caches a route, but is also an optimised A* in such that it doesn't bother to search every tile, while also is able to re-evaluate a path in real time without re-evaluating all possilble routes.

I was really interested in improving upon the A* algorithm when I came across D* & D*-Lite.  Both algorithms are very underrated and just better than A* in every way.  I honestly don't understand why so few people in development haven't heard of D* and why the hell isn't it more popular in general when there is really no downside to using either of these algorithms over A*.

5 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.

[Gurgel]

10 hours ago, Boxman_90 said:

On a forum you should always be willing to back up your statements instead of simply posing them as facts and expecting people who don't know the darnest thing about you to just take you for your word because you proclaimed yourself an 'expert' online.

You will have to live with it on this topic. This is far too complicated to explain in this context. It is universally accepted among experts though and there is tons of research confirming it. Route and schedule planning under real-time constraints is a pretty relevant topic, think, e.g. of automated warehouses. There is a limit to what can be explained, it can only go so far beyond what the target of the explanation already knows. Sorry about that, but it is just the truth. At some point you either have to invest significant time yourself or believe the experts. Now, if you ask for my _qualifications_ before believing what I say, that is something else. But requiring me to explain everything I can see and understand is just not realistic.

If you really want to get into this, researching D* and all the other graph search links here:  https://en.wikipedia.org/wiki/D* would be a good start. (Thanks to Craigjw.) Then you would need to add real-time and that, since this is a dynamic environment, caching will probably not make that much sense. (Caching only helps if you need the same path again, it does nothing for initial calculation. Caching also makes paths worse in a dynamic environment, since an older path could be still working but be a lot worse than a freshly calculated one. Caching is very beneficial in non-dynamic situations though. That is unless you do partial path caching, making things yet more complicated.)

10 hours ago, Arcus2611 said:

But what if there isn't a storage compactor available after they pick up the granite, because another dupe went and topped off the only available compactor while they were on their way to pick up the granite?

Checking for the sweep task first before the destination would actually be far worse, because you would have dupes running up to the surface to pick up regolith, realising that there's nowhere to store the regolith, dropping the regolith and repeating the cycle. The only way to avoid such nonsense is to check if there's storage space available first, but if you do that it makes more sense to then allocate some of that space to the sweep task immediately rather than waiting until the sweep task is performed to check again.

Now you are getting into some of the problems. What you usually do is you reserve the regolith, reserve the storage and then select a dupe and plan the path. Then this gets queued, because this is real-time and you usually have the plan-step (reservations + path + dupe) before you can execute it. You want as much pre-computation as possible in real-time planning as you have limited CPU per cycle. Then, when the queue gets to this plan-step, you verify whether it is still doable (as this is a dynamic environment) and execute if it is, otherwise drop it. This is, of course, still massively simplified. For example, the plan-step can get invalid while you are executing it and you need to detect that. 

[Boxman_90]

@Gurgel, if you can't explain why the path-finding (which is the only thing you're really droning on about) or even just a proximity-search can't happen with the task being the origin instead of the dupe's location when selecting a compactor, then either you're really not as much of an expert as you think, or it actually simply is possible to make this adjustment.

All you've really said is "path-finding is hard and I can't explain it to you". I haven't heard a single argument that dispels the possibility of using the task's location as the origin for a path-finding / proximity calculation within the initial the decision-making process. Real-time path-finding only kicks in after both origin and all destination have been determined anyway. Really haven't seen you say anything besides "this is hard" and "this is out of your league" to other uses here, to be honest.

You can't just barge in and say "can't be done, but I'm not going to explain why not" and also expect people to take your word for it. You're allowed to, but carry little credibility by waving your self-proclaimed 'expert'-card each time in an otherwise empty post. It only makes you look conceited.

[Gurgel]

4 minutes ago, Boxman_90 said:

@Gurgel, if you can't explain why the path-finding (which is the only thing you're really droning on about) or even just a proximity-search can't happen with the task being the origin instead of the dupe's location when selecting a compactor, then either you're really not as much of an expert as you think, or it actually simply is possible to make this adjustment.

No and that is not the issue. And if that is what you get from what I wrote, then there is really no point in talking to you. 

[Boxman_90]

 

3 minutes ago, Gurgel said:

No and no. And if that is what you get from what I wrote, then there is really no point in talking to you. 

And you don't have to, nobody is forcing you. I'm simply saying I'm not buying your "can't do"-mentality as long as it's based on something you keep refusing to address, while pointing out the slight hypocrisy in your haughty dismissal of other users' posts without being able to address any of the proposals yourself for it being 'too difficult'.

[Yunru]

17 minutes ago, Gurgel said:

No and that is not the issue. And if that is what you get from what I wrote, then there is really no point in talking to you. 

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.