Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2005:
[Freeciv-Dev] Re: (PR#12788) Does a Unit Ever Know its Body Guard?
Home

[Freeciv-Dev] Re: (PR#12788) Does a Unit Ever Know its Body Guard?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: badamson@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#12788) Does a Unit Ever Know its Body Guard?
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Thu, 14 Apr 2005 01:43:39 -0700
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12788 >

On Wed, 13 Apr 2005, Benedict Adamson wrote:
> > this might be a source of some errors in the AI.
>
> The functions ai_unit_move and ai_unit_attack uses ai.bodyguard to try
> to bring a guard along with a unit. Part of aiferry_gobyboat tries to
> load the bodyguard of a passenger onto the same boat using ai.bodyguard.
>
> It seems to me that bodyguards will never move with their charge as the
> code is now.

But they do... I've seen it consistently happening. Not often enough,
though, not by far.

> At present any number of units can thinkthey are the guard for a unit:
> several untis could have the same value for ai.charge. Keeping
> ai.bodyguard and ai.charge consistent would prevent that. I suspect that
> is the intent of the current code anyway: ai.bodyguard is not a list,
> and bodyguards are intended to stack with a unit, which is best if there
> is only one guard.

Yes.

> If a unit could have at most one guard, there would have to be someway
> for a unit to detect that its assigned guard is no good (too far away,
> too weak) and request another. Perhaps by releasing and re-requesting
> guards every turn.

The key problem is one of sequence. We do not know which unit, guard or
charge, will be managed first. But that is only half the problem - we also
need to set the bodyguard want in the charge, before we can manage the
bodyguard, but if we manage the bodyguard last, he may never catch up, nor
will the charge know if he did get a bodyguard.

Keeping the bodyguard<->charge relationship over several turns reduces
this problem a great deal.

  - Per





[Prev in Thread] Current Thread [Next in Thread]