patchFreeciv - Patches: patch #3775, Potential bodyguard looking for...

 
 
Show feedback again

patch #3775: Potential bodyguard looking for units to protect

Submitted by:  Not Given <imhotep>
Submitted on:  Sat 09 Mar 2013 11:56:09 PM UTC  
 
Category: aiPriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 

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)

Fri 11 Jul 2014 11:30:39 PM UTC, comment #9:

Just an update: patch #4649 implemented a cache of unit movement similarities that obsoletes the attached patch (with compatible results). This ticket is probably now best considered to be about the strategies discussed in comment #4, where a bodyguard is aware of the intentions of the charge, and can provide support in more complex ways (e.g. move_rate 2 amphibious unit moves over lake, and move_rate 3 road-restricted bodyguard moves around the lake to continue to provide protection).

Emmet Hikory <persia>
Project Member
Mon 13 May 2013 06:32:08 PM UTC, comment #8:

Thanks a lot.
I am open to discussion quite well (I have some bright moments once a day :) ).
What I wanted to point out is that I can't do any coding/inspection reliably.
Discussion as such is fine, it probably even helps me find a way back. If only those taking part in the discussion are aware of my condition and health and do not take offense if some response is unduly late or possibly in a strange way out of topic.

(Btw, as I don't feel able neither to code or even to play freeciv I have fallen back to nethack. Wasn't even able to do that in the first 4 weeks after the incident.)

Not Given <imhotep>
Mon 13 May 2013 05:53:42 PM UTC, comment #7:

My sympathies. I found your comment about what should be done insightful and helpful. There's plenty of other nativity issues about: I'm more than happy to delay this discussion until after you're feeling better (and may that be soon, regardless of the time before you have attention for this issue).

Emmet Hikory <persia>
Project Member
Mon 13 May 2013 05:49:36 PM UTC, comment #6:

Regrettably, after the police attack of March 13 on me, I still suffer from the concussion they delivered on me, I have still trouble concentrating and suffer from very curious forms of "memory leaks" a way I have never known before.

Excuse me, but it feels like it will still take a long time until I will be able to valuably contribute by coding or anything that needs code inspection. I'm not sure if I can give general advise or if I simply lack the retrospective to see what I meant as advise is really purest crap.

Not Given <imhotep>
Mon 13 May 2013 04:35:44 PM UTC, comment #5:

2) Bases can affect tile nativity, rivers are a type of road for 2.5+

4/6) Units are additionally subject to movement gains/losses for arbitrary requirement conditions from effects.ruleset : thinking about it, there may be a bug in pathfinding that these potential gains/losses are not checked on a per-tile basis.

7) Also, some units can subvert zones of control (e.g. using spies to ease movement of Mech. Inf. in otherwise ZOC-unfreindly terrain)

8) Unit attack capabilities (well, potential victim defense) may also be adjusted based on victim tile and unit type/flag/class.

10) Units with high movement rates may provide better defense due to the ability to perform multiple attacks against potential hostile units.

For assignment, perhaps the ferry routines (which badly need an overhaul anyway) could be rewritten to generally provide multiunit accompaniment pathfinding, considering the ability for one unit to carry another, defend another, etc. Units that might seek a bodyguard would attempt to draft one on a per-mission basis, rather than as a permanent assignment. Unemployed bodyguards would seek nearby native cities to await new bodyguard requests (or just defend the city, if nothing interesting is happening nearby). Injured bodyguards/fuel-limited/hp_loss-weak bodyguards might request the charge request a new bodyguard with enough warning to be able to return to somewhere to recharge.

Emmet Hikory <persia>
Project Member
Mon 13 May 2013 04:18:13 PM UTC, comment #4:

I was developing a ruleset based on Ancients. The AI does a bad job on it so I went into the code and this patch is just one of many things I came across. The discussion of it is now already way out of proportion of any harm or benefit from that patch.

So let's instead concentrate on what SHOULD be done for a proper, general solution for bodyguard assignment.

You have mentioned some points that make bodyguard assignment complex, and I will add some:

1) unit types move differently according to terrain
2) unit types move differently according to terrain modifications (roads, rivers, others?)
3) unit types have different needs for fuel or are susceptible to hit point loss
4) units may have extra move points depending on veteran status
5) different unit types may have different behavior on transport or airlifting
6) movement points may vary on technologies researched

7) some units ignore zones of control, others don't

8) unit defense strength may vary greatly with terrain/modifications
9) strong attacking units might provide better protection than those strong in defense
10-20) I probably missed some

So in total, in some rulesets there might be some kind of guardian angel that can follow wherever you go, but generally this will not be the case.

From what I recon, there is no way around assigning bodyguards dynamically, more than one (to send one ahead while the other keeps rearguard, essential when the master-plan involves airlifting), and checking on every move if the guards can follow.

The routine that assigns bodyguards will need to receive some insight of the planed moves, that is, a path to target, and the unit that should be protected has to check on every move if the guard(s) can follow or if some guards are already at the tile where it wants to move to.

Not Given <imhotep>
Mon 13 May 2013 02:05:16 PM UTC, comment #3:

I understand the limited application, but even for that, I'm not sure how this helps the AI use classical units, and all uses of uclass_move_type() are on a list I hope to eliminate.

For the classic, civ1, civ2, and multiplayer rulesets, where there aren't such per-terrain restrictions, all the UMT_BOTH units appear to have either fuel or hp_loss_pct restrictions that constrain movement in ways that the current logic doesn't consider when determining potential bodyguards. Such units assigned as classical bodyguards would quickly either die or abandon their charges to survive.

For the alien, civ2civ3, and experimental rulesets, the current logic already may not work for S2_5, depending on the exact placement of roads, bases, or other nativity providers. For example, a Mech. Inf. might be selected as a defender for an Engineer, but wouldn't actually be able to provide coverage for the Engineer when building a road over a mountain until the road was built (Alien has even more complex considerations).

The above notwithstanding, if there is another ruleset that the AI is able to understand with the current nativity handling that has more complex types that do benefit from this change, I waive my objection, although if I can make the code work without reference to crude nativity, I'll try to patch it away.

Although I like the idea of precaching potential followers, I fear that a complete solution would need to involve dynamic bodyguard assignment depending on current targets and comparative pathfinding for the unit and bodyguard to ensure they would be able to travel together and provide coverage over the entire path and during the activity at the destination (which might be only a single turn, for instance a Howitzer attacking a city). Simple precaching based on accessible terrains may not account for cases where the path around inaccessible terrain is too long to be of practical use (or even impossible: consider a thin island bisected by a mountain range), nor for the variable placement of roads and bases over time during the game.

For GameLoss, staying in a city is not necessarily sufficient if migration is enabled: the city might not remain there, etc. Similarly, depending on current circumstances, it might be safer for a GameLoss unit to be on transport with some settlers and bodyguards to found a new empire than stay to defend a nearly lost cause in a poor strategic position. That said, city guards do have broader safe nativity ranges (especially if BuildAnywhere), but it may make sense to select units that are capable of attacking a majority of adjacent tiles for proactive defense, AutoAttack, etc.

Emmet Hikory <persia>
Project Member
Mon 13 May 2013 12:57:08 PM UTC, comment #2:

Of course, with the new terrain features things get much more complicated for the AI. Think of a ruleset where tanks can not cross swamps (they drown), but are fast enough to find a path around and so still could keep pace with, say, a caravan.

The proposed patch addresses the classical rulesets, where it gives little improvement with very little code change.

In view of rulesets that make extensive use of the new terrain features, AI should check all unit types once when the ruleset is loaded, construct a "can follow" relationship (a partial order) and use this if possible, but fall back on some crude heuristics if now bodyguards could be found this way.

The protected unit would have to check before moving if the bodyguard can follow.
If a king is to be protected because of GameLoss attribute, it should stay put behind city walls and movement type of bodyguard does not matter at all.

Not Given <imhotep>
Sun 12 May 2013 03:16:35 AM UTC, comment #1:

I'm not sure that anything that relies on uclass_move_type() is a reliable mechanism to use to determine if a potential bodyguard can properly protect a potential charge. This only checks whether some of the native terrains for the unit happen to be of class "Land" or class "Oceanic", but doesn't check to see if the potential bodyguard can actually enter all the terrains the charge can enter (as an example, one could define a UMT_LAND unit that could use every land terrain, and a UMT_BOTH unit that could only use coastal ocean, rivers, and swamps, making the UMT_BOTH unit a poor guard for the charge).

Aside from terrain checks, units with fuel or hp_loss restrictions may also be of limited use as bodyguards for units without such restrictions, as they will be constantly retreating to base (this may be part of why UMT_BOTH units historically don't pass this test).

Emmet Hikory <persia>
Project Member
Sat 09 Mar 2013 11:56:09 PM UTC, original submission:

in ai/default.aiunits.c:look_for_charge
the unemployed unit checks potential units if it is worthwhile.

One check is the move_type. This is, I suppose, to prevent a sea unit to protect a land moving unit and vice versa. But a unit with UMT_BOTH shouldn't be so picky as to reject an otherwise valuable unit with different move_type.

Not Given <imhotep>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by imhotep (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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 09 Mar 2013 11:56:09 PM UTCimhotepAttached File-=>Added aiunit_look_for_charge_22446.patch, #17416
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup