Jump to content

Pathing tests shows some bad behaviour with repetitive sweeping tasks


neofryboy
  • Branch: Live Branch Version: Windows Pending

See attached test map.  

Setup

I set up two dispenser units on opposite sides of the map and gave them ladder access to both, a tube access to the left one, and a long sideways ladder connecting the two near the top.  The tube access is slightly faster by about a second, but the return trip is much longer.  The pile of debris is on the right side at the bottom of the ladder.  When they pick up an object they decide to drop it at the closest dispenser; the one on the right side.  

Test

However, if I remove the ladder after they pick up the object (or even after they've dropped off their item), they'll take the tube to the left dispenser, walk past it, all the way back across the map to the right dispenser, and drop off their item.  They then walk back to the sweep pile on the right side of the map and start using the dispenser on the left side of the map through the tube, as they should. But, if I rebuild the ladder and break the tube AFTER they drop off the item in the left dispenser, they'll walk back to the right side, pick up an item and walk back to the left dispenser (which is now three times the travel time), continuing this pattern until disrupted.  They even use the rebuilt ladder to go up and over, but still take the 3x longer path. They'll naturally start going to the right side dispenser again only after a self-interrupt on the right side of the map: a soggy feet debuff, sleep, downtime, yellow alert dig, etc  You can see in the screenshot that the beds are on the left side, so after nighttime they walk to the right side pile, grab an item, and walk back to the left dispenser even with the tube broken during their sleep.  

Results & Conclusion

This seems to imply that:

1) they recalculate their path to the end point when the path itself is broken, but not whether or not the end point is still the best option,

2) they use their current point (when deciding on the next task) to determine the end point, not the item's current point--which is where they will be when they pick up the item, 

and 3) they do a proper recalculation when they interrupt themselves, but only if that interrupt is in the right area.

This works fine for the case of building, where they'll set the build task then find the item they need based on their position, grab it and take it to the build site.  If they need more they'll calculate from the build site, because that's where they are.  BUT this is really bad for storing items.  The dupe decides to pick up something across the map and drop it in the nearest dispenser from their current position which just happens to be back on the other side of the map again, thus wasting a lot of time traveling, and making having multiple drop-off points semi-useless.

Thoughts

This could be fixed by having them calculate from the sweep item to the sweep item's nearest storage unit, and then, separately, calculate how to get themselves to that sweep item.

The Chaotic Space Hut.sav

Annotation 2019-09-22 144702.png


Steps to Reproduce
Listed above, also save file and screenshot attached.



User Feedback


Yes, your second point is quite annoying. I also noticed my dupes carrying pickups past 2 suitable storage locker to put them in the middle of the base. That's because they started with the task at this point. Then they will repeat the same behavior, since they start at that storage locker again. This waste a lot of time, especially since the closer storage locker will be empty when I make the next build order.

Sometimes I make manual move orders to place them next to the pickup. Only then do they actually use the closest storage locker.

Note, I do have proximity enabled at all times. Maybe that's releated to this behavior.

  • Thanks 1

Share this comment


Link to comment
Share on other sites

I have Proximity disabled at all times.  It's apparently a bit misleading.

What it does is remove the fractional priority points of the different tasks. Like deconstruct adds 0.3 priority and construct 0.16 so if both are set to 5 usually dupes deconstruct before building.  With proximity enabled it counts all priority tasks as the same and then does them based on priority number and place in the task list.  If you set a bunch of tasks in one area and then a bunch of other tasks somewhere else with the same priority then proximity enabled will handle them all in order.  Otherwise they may do all the decon tasks, then all the build tasks, etc.

That shouldn't affect this as we're only doing one task: sweeping.

Share this comment


Link to comment
Share on other sites



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
  • Create New...