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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Jan 14, 2001 at 05:53:59PM -0800, ccrayne@xxxxxxxxxxx wrote:
> 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.
> 

[ snip description of code which does similar things as my csai-0.1 ]

> 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.

This indicates you are checking at least some of the move conditions
(can't move ground unit to ocean,...).

> 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.

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. If
the issued commands failed later you can ignore it or call a
notify/callback. The notify code in what kind of state the "thinking"
was and what new commands has to be issued. The notify code can also
call the original "thinking" code but has to prevent the issuing of
the same failed command. If the "thinking" code on the other side can
recognize an error it can just continue "thinking" it has the state.
Technical I think both ways can do the same in terms of the end result
in the event driven approach however you would probably end up with
your "thinking" code spread all over the place.

> 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.

I don't see a problem if some of the packets are serialized. The
packets just didn't take advantage of the asynchronous protocol. In an
all-ai game with low timeout this will maybe a problem.

> 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

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 will propose something like that if the
attributes are implemented)

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We just typed make..."
    -- Stephen Lambrigh, Director of Server Product Marketing at Informix,
                         about porting their Database to Linux