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

[ccrayne@xxxxxxxxxxx]

In <20010116170429.B4575@xxxxxxxxxx>, on 01/16/01 
   at 05:04 PM, Reinier Post <rp@xxxxxxxxxx> said:

:You seem to be thinking of a
:model in which feedback from server requests is connected to the request
:that originated them.  To me this suggests these requests would be part
:of imperative programs, to which the requests would act as RPC. But you
:didn't actually write that.  It cannot be a regular C program unless you
:create large numbers of processes/threads.  I don't think that would be
:feasible.  Maybe I'm just not seeing how you or Raimar intend to specify
:these algorithms.

Thank you for a very clear and concise statement of your issue. I will
attempt to reply in kind. However, experience has shown that when I strive
for brevity, I often sacrifice clarity. So please feel free to ask for
more details.

To explain my approach, I must first remind you of the way in which
processes/threads work in the existing client/gui code. The client process
is driven by packets from the server, and responds by routing the packets
to routines which update the client data base and/or invoke display
services from the gui. One or more processes provided by the gui are
driven by keyboard and mouse events initiated by the human player, and
send messages to the server. Analysis and decision making are done by the
player. Thus, the client process waits only on the communication port, and
the gui process waits only on the player.

In my design, since I am not using a gui, I have created a new thread to
emulate the human player, and have modified the client code just enough to
post the ai thread when certain events occur, such as the start of a new
year. The ai thread operates very much like the client thread, dispatching
routines to handle the various events.

Other than running on the client, the primary difference between my design
and the existing server ai is that the turn based logic, instead of
iterating through unit and city lists, iterates through task lists. Each
task is similar in concept to a process or thread, in that it saves status
information from turn to turn, except that the overhead for a task switch
is almost zero. 

In the specific case of a unit move, if I do not wish to wait for
feedback, I can simply save the current unit position and switch to the
next task. The next time the task is selected, I can compare the current
position with the saved position to determine if the move took place.

However, to ease debugging, I currently wait for feedback on every move --
with an error routine triggered if the wait times out before it is posted. 


Best,
        -- Chuck Crayne
-----------------------------------------------------------
ccrayne@xxxxxxxxxxx
-----------------------------------------------------------