bugFreeciv - Bugs: bug #20361, Pathfinding may prefer move+attack...

 
 
Show feedback again

bug #20361: Pathfinding may prefer move+attack to simply attacking adjacent target

Submitted by:  Silas Brill <brilliand>
Submitted on:  Mon Dec 10 09:49:56 2012  
 
Category: generalSeverity: 3 - Normal
Priority: 5 - NormalStatus: Fixed
Assigned to: pepeto <pepeto>Open/Closed: Closed
Release: 2.3.1Operating System: Any
Planned Release: 2.3.5, 2.4.0, 2.5.0Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue Feb 19 09:57:34 2013, comment #13:

> Will the committed fix need adjusting once cardinal-move-only
> roads/rivers exist?


I don't think so. The last part of the path is considered as a single move only if the move was previously possible.

pepeto <pepeto>
Project MemberIn charge of this item.
Tue Feb 19 09:47:26 2013, comment #12:

> Where this needs more consideration is the experimental ruleset.
> If the defender is on a tile that the attacker could not enter
> except via road, then totally negating the road will make the
> defender unreachable.

I don't think this applies to the current experimental ruleset; if attacker is Big Land (e.g. Cannon) and defender is e.g. on a hill, either there's no road on the hill (in which case attack is impossible) or there is one (in which case attack direction doesn't matter; pathfinding will necessarily arrange that the source tile has a road).

I don't think it's possible to set things up so that the attacker can only attack the defender from a certain direction.

However, we'd certainly like that to become possible (see for instance bug #16383). Will the committed fix need adjusting once cardinal-move-only roads/rivers exist?

Jacob Nevins <jtn>
Project Administrator
Tue Feb 19 08:53:21 2013, SVN revision 22380:

Path-finding: Consider the last move of the path as a constant single move when
attacking and entering foreigner cities to establish trade route. We would get
straighter paths on these cases.

The old behaviour (often prefering move + action) is still possible using
goto waypoints.

Reported by Silas Brill

See gna bug #20361

(Browse SVN revision 22380)

pepeto <pepeto>
Project MemberIn charge of this item.
Tue Feb 19 08:53:17 2013, SVN revision 22379:

Path-finding: Consider the last move of the path as a constant single move when
attacking and entering foreigner cities to establish trade route. We would get
straighter paths on these cases.

The old behaviour (often prefering move + action) is still possible using
goto waypoints.

Reported by Silas Brill

See gna bug #20361

(Browse SVN revision 22379)

pepeto <pepeto>
Project MemberIn charge of this item.
Tue Feb 19 08:53:16 2013, SVN revision 22378:

Path-finding: Consider the last move of the path as a constant single move when
attacking and entering foreigner cities to establish trade route. We would get
straighter paths on these cases.

The old behaviour (often prefering move + action) is still possible using
goto waypoints.

Reported by Silas Brill

See gna bug #20361

(Browse SVN revision 22378)

pepeto <pepeto>
Project MemberIn charge of this item.
Sun Feb 17 10:34:04 2013, comment #8:

Attaching better version: consider the last move of the path as a constant single move when attacking and entering foreigner cities to establish trade route for getting straighter paths.

In the savegame example, the old behaviour is still possible using waypoints.

(file #17236)

pepeto <pepeto>
Project MemberIn charge of this item.
Fri Feb 15 14:06:45 2013, comment #7:

Attaching simplified version...

(file #17203)

pepeto <pepeto>
Project MemberIn charge of this item.
Sun Feb 10 16:20:06 2013, comment #6:

This patch should solve your problem.

(file #17180)

pepeto <pepeto>
Project MemberIn charge of this item.
Mon Jan 14 15:29:13 2013, comment #5:

That's actually pretty good. Any reasonable defender will certainly attempt to negate the road using mines, caltrops, etc. In general, we want the attacker to remain in place after the assault. The added movement point cost from having to march beside the road will further limit fast units from "shooting and scooting".

Where this needs more consideration is the experimental ruleset. If the defender is on a tile that the attacker could not enter except via road, then totally negating the road will make the defender unreachable.

David Lowe <doctorjlowe>
Sun Jan 13 23:52:55 2013, comment #4:

That could be done by treating the final step (onto the enemy-occupied tile) as having the same movement cost regardless of direction - basically, ignore roads and rivers on enemy-occupied tiles.

Silas Brill <brilliand>
Sun Jan 13 22:55:32 2013, comment #3:

to bring more light into it - pathfinder does not check whether targeted square is occupied, it only checks best way to that square
from my long observation, best metod to avoid failed gotot+attack is use it to go best position near unit and attack using arrow keys

as for code, there are few solution that i can think, but none of them is good enogh to solve problem
i think easiest (and best) would be if pathfinder checked if tile is occupied and if yes then goto adjacent to unit (using best route), attack and dont move further

Roman Petrinec <petrinec>
Wed Dec 12 04:14:14 2012, comment #2:

I just found a workaround: Using the arrow keys doesn't trigger pathfinding, so it's good for controlled single steps.

Does the pathfinding take into account whether the move is an attack or not at all? It seems as though most similar situations would be covered by the ZOC rules. In this situation, the dragoon's two-step movement wouldn't be possible if the city were not there.

Silas Brill <brilliand>
Mon Dec 10 15:37:34 2012, comment #1:

I assume the relevant difference between the Musketeer and the Dragoon is that the Musketeer only has one movement point, so the Dragoon could afford to move before attacking. The problem is, that the pathfinder is optimized to use less movement points on the route and, as you surmised, will prefer the river. The question is why doesn't the pathfinder see not moving before the attack as the optimum use of movement points?

David Lowe <doctorjlowe>
Mon Dec 10 09:49:56 2012, original submission:

I have a dragoon in a city on a hill, and I want to use that dragoon to attack a cannon on a diagonally adjacent hill. However, the target hill has a river, which seems to be throwing off the pathfinding.

+---------------------+---------------------+
| Hill+River (Cannon) | Plains |
| Grassland+River | Hill+City (Dragoon) |
+---------------------+---------------------+

When I try to attack the cannon, the dragoon opts to move through the Grassland+River tile, which would surely by the right move if the other hill were not occupied. However, in this case such a move results in my dragoon stepping outside the safety of the city into a relatively hard-to-defend grassland tile, and throwing one of my cities into disorder for a turn because I'm running a democracy in the civ2 ruleset.

(I also have a musketeer in that city, which is able to attack without triggering this bug, but when I do that the cannon wins the fight. I'm not sure whether that's another bug or there's some rule I'm missing that would make that make sense.)

I've attached a savegame - the city in question is "Mixcoac".

Silas Brill <brilliand>

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #16836:  bugged_save.sav.bz2 added by brilliand (27kB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by pepeto (Updated the item)
  • -unavailable- added by petrinec (Posted a comment)
  • -unavailable- added by doctorjlowe (Posted a comment)
  • -unavailable- added by brilliand (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Error: not logged in

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Feb 19 09:47:52 2013jtnOperating SystemMicrosoft Windows=>Any
    Tue Feb 19 08:53:56 2013pepetoStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Sun Feb 17 10:34:04 2013pepetoAttached File-=>Added path_finding_dont_leave.diff, #17236
      Planned Release2.4.0, 2.5.0=>2.3.5, 2.4.0, 2.5.0
    Fri Feb 15 14:06:45 2013pepetoAttached File-=>Added trunk_S2_4_path_finding_dont_leave.diff, #17203
      Assigned toNone=>pepeto
      Planned Release=>2.4.0, 2.5.0
    Sun Feb 10 16:20:06 2013pepetoAttached File-=>Added attack_last_part_problem.diff, #17180
      StatusNone=>Ready For Test
    Mon Dec 10 09:49:56 2012brilliandAttached File-=>Added bugged_save.sav.bz2, #16836
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup