Complete.Org: Mailing Lists: Archives: freeciv-ai: August 2002:
[freeciv-ai] Re: ai move cleanup #4

[freeciv-ai] Re: ai move cleanup #4

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: Freeciv AI development <freeciv-ai@xxxxxxxxxxx>
Subject: [freeciv-ai] Re: ai move cleanup #4
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Thu, 8 Aug 2002 15:35:09 +0000 (GMT)

On Thu, 8 Aug 2002, Gregory Berkolaiko wrote:
> > (Interestingly, if I read the code right, a unit with move == 0 can still
> > attack. Is this correct or a misreading or a bug? Seems the client stops
> > it from happening, but a modified client should be able to do it.)
> Where did you find it?That'd be very strange.

More like a lack of finding the necessary check to stop it from happening.
Read the code from entry at handle_move_unit (sp?) to
handle_unit_move_request to handle_unit_attack_request. The first check I
found for move points is where we determine if we can enter the presumably
emptied position where the enemy used to be.

I'm not at my freeciv box so I can't show in detail.

> > This check is done in ai_unit_move. The function returns FALSE, and
> > do_unit_goto returns GR_FAILED. Just as it was before, except then it was
> > handle_unit_move_request that did it. The AI code doesn't check for
> > GR_FOUGHT and the above code would (in theory) never be called.
> Just a moment.The above code is for the humans!  It should stay IMO.

Ooops. Seems I got carried away :)

The comment should go, though.

> > > The rest seems to be pretty good work.Also seems to fix the bug when an
> > > attacker wouldn't occupy an empty city because it's bodyguard wouldn't
> > > budge.I didn't test it though.Savegames would differ at later stage, I
> > > assume?
> What happened to the spaces after full stops in the passage above??

I get it in your paragraphs too...


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