Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2001:
[Freeciv-Dev] Re: [PATCH] Unit movement
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Thue <thue@xxxxxxx>
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [PATCH] Unit movement
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 13 Jan 2001 11:56:40 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxxxx

On Sat, Jan 13, 2001 at 02:50:17AM +0100, Thue wrote:
> On Saturday 13 January 2001 01:32, Raimar Falke wrote:
> > The other introduces a feedback mechanism. Currently there is no easy
> > way on the client side to get the result of an operation carried out
> > by the server. One way to address this problem is to send an
> > information request after the command request and compare the received
> > information with the current. Another way is to duplicate a lot of
> > conditions which are checked on the server in the client. Yet another
> > way is to request an result code from the server. This is the way
> > which is implemented in the patch. Currently only the movement of a
> > unit is covered (after working on it I think it must the most complex
> > process). The unit move request got two additional fields: dry_run and
> > report_result. dry_run will only test almost all conditions and will
> > not do the final changes. report_result sends in every case (success
> > or failure) a result packet back to the client. With these flags code
> > on the client side can test movement in a predictable way.
> 
> Dry-run is a bad idea, IMO. When doing AI calculations you need to test lots 
> of moves (just imagine finding a goto route), and asking the server over a 
> slow internet connection per consideration is not an option. Just copy the 50 
> lines of code that do the check, dammit! :) Maybe put it into common if you 

The conditions are unfortunately wide spread
(unithand:handle_move_unit,unithand:handle_unit_enter_hut,
unithand:handle_unit_move_request,
unithand:handle_unit_establish_trade, unittools:can_unit_move_to_tile,
unittools:try_move_unit, unittools:do_airline,
unittools:move_unit). These methods consists of 585 lines in the
unpachted version. 3/4 of these lines where checks (=438 lines).

I know that it will cost a round trip time which is a lot compared to
the current send-and-forget. However I don't propagate the migration
of existing code to use dry_run. In the long run we would maybe
profile the result codes and put checks for the most common ones in
send_move_unit().

> really hate copying it. We have the capstrings for ensuring compatability 
> across versions.

I will take a look.

> Oh, and please conform to freeciv coding style. ie indentation, and an if 
> looks like
> if (???) {
>   !!!
> }

Yes. I'm still searching for an automated way to do this since indent won't 
work.
--- freeciv_hackers_guide.txt
- Use K&R indentation style with indentation 2 (when in doubt, use
  "indent -kr -i2").  However, do not re-indent areas of code you are
  not modifying or creating.
--- freeciv_hackers_guide.txt

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Python 2.0 beta 1 is now available [...]. There is a long list of new 
  features since Python 1.6, released earlier today. We don't plan on 
  any new releases in the next 24 hours."
    -- Jeremy Hylton at Slashdot



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