Follow-up Comment #1, bug #21913 (project freeciv):

I think these specific issues can be addressed by adding a guard condition (as
described in the attached patch).  I'm not convinced this is sufficient to
make find_beachhead() work properly, but I may misunderstand the intent of
this function.

To me it looks like it uses unsafe conditionals to guess whether a unit can
reach a destination directly, and then does manual overlapping adjacency
iteration (so some tiles might get checked as many as eight times) to try to
find somewhere adjacent to somewhere adjacent to the target.

The unsafe conditionals probably only matter for 2.6+ (as <2.6 AI can't handle
complex nativity, so there's no reason to fix), but should the second manual
iteration not be a reverse map for the target unit type at the target tile,
iterating over potential beachheads in move order, limited to a max of, say, 2
moves?  With this implementation, could the unsafe conditionals just be
dropped entirely?  Is the magic number '2' (currently implemented as levels of
nesting) important, or does it just represent the level of manual recursion
that was acceptable to the author of this function when it was written?

Alternately, as a less invasive solution, perhaps the nested tile iteration
could maintain a list of investigated tiles and short-circuit for tiles
already examined, or something.

My thought is that 2.3 probably wants just the PF_IMPOSSIBLE_MC guard, 2.4
benefits from the guard and some iteration optimisation, 2.5 from using
pathfinding iteration to find the best beachhead, and 2.6 from a combination
of pathfinding and complex nativity fixes, but I'm not certain this matches
the current state of freeze for each of these branches, nor if all that
belongs in this ticket.

(file #20520)

Additional Item Attachment:

File name: avoid-preferring-PF_IMPOSSIBLE_MC-beachheads.patch Size:1 KB


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to