Quote:
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
Re: Route planning algorithm
Threaded Mode