Colonists path inefficiently - By design

[Bumblechubs]

When a colonist catches on fire it's natural to assume they'll run around a bit while panicking, usually pathing five or six tiles away at a time... but sometimes if they catch on fire near a wall that separates a large area of the outside they'll path straight through it. This leads them on a long walk-about around the entire map, while constantly taking fire damage. By the time they arrive at their destination they've become incapacitated.

[enystrom8734]

Its an underlying problem with pathing that is already known. Will not be addressed until a later version most likely.

[ShadowDragon8685]

Summary: Colonists path to the nearest paste dispenser as the crow flies, not to the one which is the shortest distance to reach.

Steps to reproduce: Build a map in such a way that a colonist will go starving with a food dispenser very near to them as-the-crow-flies but which to get there will involve traversing an unreasonable distance, and another dispenser farther away as-the-crow-flies but which is a reasonable distance.

Make the colonist starve in such a location as the unreasonably-distant-travel-time dispenser is physically nearer, and watch them sprint straight past a nutrient paste dispenser whilst screaming that they're going to go psycho if they don't get to eat.

Expected Results: The colonist chooses the shortest path to a meal.

Actual results: The colonist chooses the path to the nearest meal as the crow flies, which can be a ridiculously long path while they're starving and going mental break imminent.

Notes: You can manually correct this if you see it by drafting them and ordering them to the actually nearest dispenser, but it's a pain.

[Tynan]

This is a designed limitation for performance and feasibility reasons.

[ShadowDragon8685]

This is a designed limitation for performance and feasibility reasons.

Would it really be hard to change the pathing behavior of someone who is about to starve to death/go psycho from starvation to have them make a pathing check on, say, every nutrient dispenser and choose the one that will get food in their bellies fastest? As it is now, I nearly lost a colonist to going nutbar purely because the pathing behavior was too incompetent to choose the soonest source of food the colonist could reach.

[Tynan]

This is a designed limitation for performance and feasibility reasons.

Would it really be hard to change the pathing behavior of someone who is about to starve to death/go psycho from starvation to have them make a pathing check on, say, every nutrient dispenser and choose the one that will get food in their bellies fastest?

Yes, unfortunately. This would require generating a path to every possible destination. It would be doable for this specific case, but what about when deciding which fire to extinguish, which square to mine, or which dropped food to eat? There can be hundreds of these items, and pathing to them all is impossible in real time.

[ShadowDragon8685]

Yes, unfortunately. This would require generating a path to every possible destination. It would be doable for this specific case, but what about when deciding which fire to extinguish, which square to mine, or which dropped food to eat? There can be hundreds of these items, and pathing to them all is impossible in real time.

I get that it would be really, really impractical for every case, but losing a colonist because you built your base too well and your pawns are too stupid to eat at the dispenser which is nearest in travel time would be incredibly, head-slammingly frustrating. Would it be doable and more processor lite to only trigger that "determine which dispenser requires traversing the fewest tiles" intelligence only when the colonist is getting to -10 or -20 hunger levels?

Also, another thing that might cut down on this is if colonists were programmed to seek a meal immediately after waking up, unless they were drafted out of their beds by the player to go do something. I find that often my colonists are going off half-cocked, running to work instead of to the canteen for breakfast; they arrive at work, strike the earth once, then go "My tummy rumbly!" and dash all the way back to the canteen... Which is why I've got scattered canteens in the mineshaft anyway, so they don't do that.

[KiwiNZ]

Also, another thing that might cut down on this is if colonists were programmed to seek a meal immediately after waking up, unless they were drafted out of their beds by the player to go do something. I find that often my colonists are going off half-cocked, running to work instead of to the canteen for breakfast; they arrive at work, strike the earth once, then go "My tummy rumbly!" and dash all the way back to the canteen... Which is why I've got scattered canteens in the mineshaft anyway, so they don't do that.

Another option would be to have a schedule for micro managing for when colonists do certain jobs which includes eating and sleeping ect. This would solve the problem of them not getting enough food if you are good at micro-managing

[enystrom8734]

This has been resolved as a design limitation. This will either improve in the future or remain the same. With performance optimizations it becomes possible for pathing optimizations to come too.

Closed by design

[vx714]

This is a designed limitation for performance and feasibility reasons.

Would it really be hard to change the pathing behavior of someone who is about to starve to death/go psycho from starvation to have them make a pathing check on, say, every nutrient dispenser and choose the one that will get food in their bellies fastest?

Yes, unfortunately. This would require generating a path to every possible destination. It would be doable for this specific case, but what about when deciding which fire to extinguish, which square to mine, or which dropped food to eat? There can be hundreds of these items, and pathing to them all is impossible in real time.

Hmm...  Rather than trying to calculate A* for every possible destination for every colonist every tick, you can reduce this dramatically by polling the other colonists only on each others current destinations.  (Or instead of tick, "every time Behave resolves a new goal", depending on how you are doing it.)

After your existing pathfinding completes, just poll all other colonists to see if they can get to the one location in question (not all possible destinations) sooner, only for the the one destination which the colonist being resolved has already chosen.

A distance threshold could be set (user-adjustable would be nice) such that a colonist who selects a destination beyond the threshold will cause a polling event to force the other colonists to see if their distance to the destination is shorter, but only for that one location the colonist currently being processed has chosen.

The idea here is that every colonist has a current task, so take advantage of that behave/pathfinding work that has already been done, sort of like the locality of reference idea.  So instead of calculating A* on every potential destination on the map every tick, you can cause the colonists to poll each other, or compare destinations, at the time of colonist completed decision-making only.  This would drop it from O(N^2) to O(N) I think.  But to make it work, I believe you would need to add task abandonment through another (user adjustable?) threshold, so no task abandonment can occur for X number of ticks after pathfinding resolution occurs... otherwise you can end up with this oscillating behavior where colonists get stuck accepting and then abandoning each others tasks.

I believe this path-polling/task-abandonment idea might help with the problem where a colonist who is standing next to an objective (like a wall that needs to be repaired) will walk away from it because a colonist halfway across the map has already claimed that destination.

I don't know if you can do this sort of thing in Unity, but ThyReaper of Blind Mind Studios came up with a trick to pass destination pointers around among agents that worked really well in their game Star Ruler.  Many hundreds of ships (I've seen it run smoothly with well over 2,000 ships) passing their destination pointers and distances a little at a time among each other to optimize distances over time among the swarm without a huge performace hit, he describes it briefly here:

http://forums.blind-mind.com/index.php?topic=4455.msg35017#msg35017

[nomadseifer]

The OPs problem is a 'simple' fix.  Instead of having the on-fire player find a random tile and path to it, just randomly path from their current location for 5 or six tiles.