URL:
  <http://gna.org/bugs/?15728>

                 Summary: Inaccuracy in pathfinding from TM_WORST_TIME (e.g.,
in client-side connect)
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Sunday 03/28/10 at 15:35
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: Need Info
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
                 Release: 
         Discussion Lock: Any
        Operating System: None
         Planned Release: 

    _______________________________________________________

Details:

Even after the fix for bug #15722, the turns report for client-side connect
is inaccurate (pessimistic). This inaccuracy stems from emulation of
TM_WORST_TIME pathfinding in get_connect_road()/get_connect_irrig().

In TM_WORST_TIME mode, the pathfinding code assumes that any attempted move
with fewer movement points than are required will fail (as opposed to
TM_BEST_TIME, which assumes success). The comments refer to "random
rulings".

It looks like most "random rulings" in movement were removed before 2.1
(r10104, 2005-03-24, RT #4387
<http://bugs.freeciv.org/Ticket/Display.html?id=4387>); since then the actual
behaviour has been TM_BEST_TIME. I think the only remaining potentially random
element in movement is "occupychance", which is a server option (and not
random by default).

Looking at the standard pathfinding code, I only see the TM_BEST/WORST_TIME
distinction having an actual effect on normal_map
(pf_normal_map_adjust_cost()) and danger_map (pf_fuel_map_fill_position()); I
can't see any effect on fuel_map (maybe I've missed something).

Looking at users of pathfinding, I see various attempts to use
TM_WORST_TIME:
* AI: aiferry.c, ai_avoid_risks(), ai_fill_unit_param() (with comments about
triremes)
* pft_fill_parameter() for fuel units
* pft_fill_amphibious_parameter())
Many of these seem to be concerned about triremes from comments. Presumably
the problem was that if a trireme tried to move from deep sea to coast with
partial MP, it might fail and then risk sinking. That's doubly irrelevant
now, since (a) partial MP always works, (b) triremes cannot occupy unsafe
ocean even temporarily from 2.2.

Client-side goto always overrides with TM_BEST_TIME, but this is ignored for
connect, which is hardcoded.
* There's a comment _"FIXME: for units traveling across dangerous terrains
with partial MP (which is very rare) using TM_BEST_TIME could cause them to
die."_. I think this is doubly out-of-date; (a) movement follows TM_BEST_TIME
(modulo occupychance), (b) unsafe terrain is gone. (If unsafe terrain returns
then I suppose this could kill a unit attacking a city from a glacier, but
you were already taking a risk there.)

Most users get TM_CAPPED by default, I think (pft_fill_default_parameter()).
(I haven't worked out exactly how that behaves in practice.)

So, as well as the proven issues with connect, I think this might be leading
the AI to be excessively cautious (but haven't tested this hypothesis).

What can we do about it? Some guesses:
* Minimal: leave TM_WORST_TIME code in place, but switch connect and other
users over to TM_BEST_TIME.
** Might lead to over-optimism about ability to occupy cities after combat?
That could be bad...
* As above but bodily remove TM_WORST_TIME code.
* Keep TM_WORST_TIME/TM_BEST_TIME but remove the notion that normal moves
with partial MP can fail. Instead, teach it about "occupychance", including
adaptation to the common deterministic cases.

Anyone got any other ideas or suggestions?




    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?15728>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to