Menu
▾
▴
1 Attachments
#261 Unit heading in the wrong direction
Send the EF to the prarie at 22,43 using the middle button, then play out the next turn. The Cherokee will have (once again) gotten in his way and he will end up going in the opposite direction.
BTW, the reason I'm micromanaging his movement instead of just sending him to Vlissinger where I want him is that units keep getting blocked at around that point and deciding they need to go all the way around like 35 turns instead of waiting for the roadblock to clear.
git-1a32cc
I agree this is not ideal, but I am not sure we can do any better. The 41 move path going the wrong way round is silly... but it is "correct" inasmuch as that is the quickest way the unit can get to its destination with the map in its state at that point in time. We could limit successful paths, but picking the specific number to use is always going to annoy someone. I fear geographically constrained cases like this are doomed to needing to be micromanaged. That said, I played out a few more moves--- after a bit of back and forth theunit made it to the destination after six turns, whereas micromanaging would have done it in four.
Do you have a suggestion as to what we can do better here?
In general (it sounds like you're asking about the BTW part of my comment)
Perhaps calculate the besr path twice, once with natives considered impassable and once passable. If the impassable route is short, query the player.
Personally, I'd prefer to only query the player if they are currently blocked, or perhaps could not use all of their movement points on this turn. Many times when I am moving units a long ways, I'll get a warning that there is no path to my destination when the blockage is several turns away and will most likely be cleared up by the time I get there.
Not sure what to do about being blocked by Europeans, as a human play could intentionally blockade a route (I assume that natives will always move if they are able).
Now, for the specific issue I was reporting -- it looks like I gave you the wrong save. Again, double click that EF to go to 22,43 and end turn. An Aztec brave will step in the way (onto 22,43), and on the next turn the EF will move in exactly the wrong direction. I now see that what he's trying to do is go the long way around to get to that tile, but the tile is blocked no matter which path he takes
Not for me. I get a popup warning that there is no path to 22,43. Which is what I would expect.
This could work. The extra path calculation is potentially slow, but we could just geometrically work out a lower bound on the number of moves. I will look into this further.
This is a limitation of the path finding code. It does not distinguish between transient and permanent blockages. A while back I did consider extending the path finder for this, but was put off by 1) the additional complexity in what is already the most complex part of FreeCol, 2) the European problem you correctly raise, 3) suspicion that there would still be cases where a large number of natives concentrated around a settlement at a geographic bottleneck would result in an effectively permanent blockage... which is where your saved game is headed.
I would consider this a pretty low priority, since there are multiple workarounds available (disband, micromanage, move to coast and transport by ship).
One idea did come to mind -- keep a record of the number of moves to destination for each unit (where applicable). If on a new turn the distance increases by N%, stop and query the player.
OK, agreed. However I will try to put in some sort of mitigation before closing.
That is reasonable. We already have a corner case with colony destinations that are destroyed while the unit is en route. This would have minimal extra CPU cost. I will look at this again post-release.
Ticket moved from /p/freecol/bugs/3054/