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

[ccrayne@xxxxxxxxxxx]

In <20010115011450.A7426@xxxxxxxxxxxxxxxxxxxxxxx>, on 01/15/01 
   at 01:14 AM, Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> said:

:> The easiest interface for the code which calls send_move_unit() would
:> that the result of the move request is the return code of this
:> method. However if you allow more than one outstanding request (with
:> report_result set) how do you associate the result packet if the call
:> to send_move_unit(). The only answer I can think of are multiple
:> threads. Or you can change the interface. This would put the problems
:> on the methods which calls send_move_unit().

:Attached is a patch which implements the second step mentioned above. Is
:there any easier way to do this in C without using multiple threads?

Raimar,

I appreciate the fact that you are trying to help. Since there are so few
people on the development list who have shown any real interest in client
ai development, those of us who are actively interested need to work
together, or else nothing useful is likely to be accomplished. In this
spirit of cooperation, let me briefly share with you (and with anyone else
who is interested) what I have already done, and where I most need help.

So far, I have running code which, without any human action other than
invoking the program from the command line, will perform the following
steps:

1. Pregame
   Log into the server.
   Negotiate nation and a leader names.

2. Start of game
   Set the research goal to "The Republic",
   Set the tech goal to the first unresearched prerequisite technology.
   Build task lists for each initial unit
      Explorer
        Find seacoast
        Explore seacoast
        Explore interior
        Harvest Huts
        Patrol
      1st Settler
        Build Initial City
        Set initial production
      2nd Settler
        Find next city location 
        Build next city
        Set initial production
      
3. Every new year
   Iterate through the task lists,
     moving units as necessary to accomplish goals

I move the units by a call to request_move_unit_direction, and confirm the
movement by checking the resulting unit info packet, which the server
ALWAYS sends when movement takes place. Assuming no bugs in my code, the
only time that movement will NOT take place is if the server knows
something which it has not told the client -- such as zone of control
issues -- in which case it sends a generic message.

Thus, as long as I am running on a fast, reliable network, I have no need
for any additional feedback. If I get a unit info packet within a
reasonable time, then the movement took place, otherwise, the movement is
blocked by factors beyond my control.

In the real world, however, network connections are often slow and
unreliable, and it is difficult to determine how long to wait for a
response which may never come. To ease this issue, I am currently planning
to parse the error messages, however, this method suffers from the same
drawback as your proposed response packet -- it is only the proximity in
time which associates the response with the event, and attempting to
serialize the client<->server data stream unnecessarily weakens the
advantages of the existing asynchronous communication protocol.

You asked if preserving the existing protocol requires multiple threads in
the client code. It does not. It requires only that the packet contain
enough information that the ai code can pick it out of a queue and
associate it with the event which triggered it. For example, suppose that
[in order to overlap as much processing as possible with network
communications] the ai logic first generates a list of all moves it wishes
to make for the given turn; sends each move request without waiting for
any response; turns its attention to optimizing city production; and only
when that is complete, starts retrieving unit info packets [and/or other
response messages] from the message queue and checking them against the
move list.

Having said that, however, I must also tell you that I did choose to add a
separate thread for the ai logic, because I feel that such a thread is the
natural analog to the role of the human player.

The net of all this is that I am too far along on the client side to be
able to use anyone else's patches, and not nearly far enough along that I
have any time to spend on designing or implementing server changes. Thus,
what would help me the most in regard to unit movement would be to ensure
that the server sends back a unit info packet for every move request,
instead of just for the successful ones. It would be nice if the
unsuccessful ones had an status code included, but just the fact that the
position coordinates did not change would be error notice enough.

More generally, it would save me a lot of work if all messages had an
event code., and if error messages which are not associated with a
specific map location were to use those header fields for things like a
unit or city id.  


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