[Freeciv-Dev] Re: [PATCH] Unit movement

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jan 15, 2001 at 01:42:23PM -0800, ccrayne@xxxxxxxxxxx wrote:
> In <20010115084754.A8047@xxxxxxxxxxxxxxxxxxxxxxx>, on 01/15/01 
>    at 08:47 AM, Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> said:
> 
> :[ snip description of code which does similar things as my csai-0.1 ]
> 
> Are the two of us the only ones who have some running code, or is there

I'm not sure if my code still runs against todays server.

> anyone else who should be part of this discussion?

I would say that everyone can participate.

> :This indicates you are checking at least some of the move conditions
> :(can't move ground unit to ocean,...).
> 
> Yes. "can_unit_move_to_tile" can not be used verbatim, but it only takes a
> couple of minutes to modify it for client use.
> 
> :The programming model would be event driven. In code which is
> :"algorithmic" (for example a loop over every unit under control and
> :issuing commands) I think such event driven programming isn't nice.
> 
> To play well, client ai code must be event driven, because each move can
> reveal additional information about the terrain and the deployment of
> other players units. For example, if an explorer with moves still
> remaining suddenly finds itself next to an enemy unit, it still has time
> to retreat.

Whats wrong with:

   for_each_unit
   {
      while(current_unit_can_move)
      {
         think_about_best_direction(); /* could use dry_run */
         result=move();
         /* if dry_run was used before if should succeed */
      }
   }

This assumes the result packet is sent last. Particular after the tile
info and the info for the enemy unit.

> :Suppose <http://arch.freeciv.org/freeciv-dev-200008/msg00248.html> is
> :implemented with an extra result field and a serial number of command
> :field. And if there would be a serial number in every command would this
> :solve your problem?
> 
> I like the concept of the new event packet, which would make it
> unnecessary to parse error messages. However, if this proposal is
> implemented, I see no need for a serial to be sent with the command, or
> returned with the response, since the proposed packet already has enough
> fields to identify itself as a response to a command; provide a status
> code; and identify the unit, city, or other entity, to which the command
> applies.

This would make the client guessing in some way. Maybe there is an
example which can be guessed wrong. Using serial is 100% correct every
time.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  A supercomputer is a computer running an endless loop in just a second.