Bug: Route planning algorithm

[dmnt]

While enthusiastic about the game, I have encountered quite a many times a bug in the route planning algorithm when you click to the target hex, mostly involving building or water hexes. Tanks like to take the drive thru like they were at McDonalds and water hex movement point consumption (as well as in some other cases but I haven't been able to isolate) differs between the plan (bright hexes) and the actual result (troops run to water and are then "out of movement points." Minor case is that sometimes they have points to go to the firm land but are shown as not eligible to go there.

In my running PBEM game I had a MTP-70 which for reasons unknown decided that the shortest route between two points isn't a line drawn between them but first we should crash in to a building (in waterline hex) and then get stuck there. Bizarrely the first move was to hex down and right when I clicked the leftmost hex it could reach. Also with MTP-70 the bridges seem to consume movement points just like I would drive my troops to land.

I can provide you examples where route plan goes wrong in saved games if you need, but here's the list of what I have found so far:

- Tanks especially like to drive to the buildings even when other routes are faster (there's a road around the house).
- Units treat water hexes as they were roads in the route plan and then the unit fails to reach the target destination clicked. Maybe adjust the algorithm so that the unit which is on land will count the water hex as (Movement Points / Water Movement Points), so a unit with MP 20 and WMP 4 would treat the water like it consumed 5 points of movement.
- The reachable hexes in above situation fails. Sometimes there are hexes you can go but are not marked as such. Occasionally in other situations when there are units, holes in the roads and lot of action the promised movement is more than the final result after clicking the hex, but I am unable to isolate the issue.
- Some boats require additional movement points (A LOT!) when moving thru hexes that have bridges.
+ Wish: When moving the unit, show planned path (when mouse is held on top of the target hex) and possibly warn if the route involves rough slopes or crashing thru buildings. For example, the planned route is shown with a dark gray dashed line, which will turn red if the route involves a hex that could possibly get the unit stuck.

[void1984]

Just be glad you haven't used "All formation movement" mode.

[dmnt]

Originally Posted by void1984

Just be glad you haven't used "All formation movement" mode.

I learned quick to not use that.

[Imp]

Never really suffered from building problem though admit there is an issue with water & paddyfields if have amphib capability. The solution is to split the move up doing it in 2 or 3 shorter stages, tend to do this in most cases anyway as gives you more control.

[DRG]

Originally Posted by Imp

Never really suffered from building problem though admit there is an issue with water & paddyfields if have amphib capability. The solution is to split the move up doing it in 2 or 3 shorter stages, tend to do this in most cases anyway as gives you more control.

EXACTLY

[Suhiir]

I long ago learned not to let vehicles auto-route in urban terrain because they prefer to go thru buildings rather then around them.

[dmnt]

Unfortunately that only alleviates the problem but is not a complete workaround. In many cases even the short route might go haywire especially with water/bridge hexes.

I personally - as a software developer - know the pains of going thru old and buggy code and in this case it's something that's probably always been there - but couldn't you guys implement for example something easy but computationally inefficient like Djikstra's algorithm as the computing power these days shouldn't be a problem? The very source of the problem lies with the movement point calculation differing between the route plan cost (bright hexes) and the actual movement cost. This is also bad in cases where you think you can move your troops to the cover of the forest and then find out that the route planner promised you more than it can deliver and your troops are sitting (or running) ducks in the open for the opponents next turn.

[Mobhack]

Originally Posted by dmnt

Unfortunately that only alleviates the problem but is not a complete workaround. In many cases even the short route might go haywire especially with water/bridge hexes.

I personally - as a software developer - know the pains of going thru old and buggy code and in this case it's something that's probably always been there - but couldn't you guys implement for example something easy but computationally inefficient like Djikstra's algorithm as the computing power these days shouldn't be a problem? The very source of the problem lies with the movement point calculation differing between the route plan cost (bright hexes) and the actual movement cost. This is also bad in cases where you think you can move your troops to the cover of the forest and then find out that the route planner promised you more than it can deliver and your troops are sitting (or running) ducks in the open for the opponents next turn.

The "route planner" part of the code has always "lied" - it especially gets confused by water movement since that uses a totally different system from land points. Plus it makes the map look rather weird, with the unit surrounded by a bright area in a sea of dark hexes, IMHO. And yes, we have looked at the algorithms used by the function, and improved it some (it used to get discommoded by mere bridge hexes originally and I recall curing or at least improving? that bit after the loss of some hair 4 or 5 years back).

Just do as I have done since SP came out - simply turn that "feature" off and ignore it completely. Move things one hex at a time, and get to know the capabilities of your units.

Andy