[Freeciv-Dev] Re: Generator script

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sat, Sep 07, 2002 at 08:08:49PM +1200, Billy Naylor wrote:
> On Fri, 06 Sep 2002 05:34, Raimar Falke wrote:
> > On Thu, Aug 29, 2002 at 09:30:51PM +1200, Billy Naylor wrote:
> > > On Thu, 29 Aug 2002 06:03, Raimar Falke wrote:
> > > > On Wed, Aug 28, 2002 at 07:27:00PM +0200, Peter Hans van den
> > > > Muijzenberg
> > >
> > > wrote:
> > > > > Hi,
> > > > >
> > > > > I'm really here to see if the networking code can be split off from
> > > > > the game code, so it can be reused for other net games. But now that
> > > > > I'm here:
> > > > >
> > > > > Is there still a need for a script that generates packet send and
> > > > > receive functions? there are some issues, but in itself this seems
> > > > > doable.
> > > >
> > > > I'm also toying with this idea. It is possible but there is currently
> > > > no strong need for this.
> > >
> > > I sounds like something that may be useful for people who'd like to build
> > > clientside stuff, like a client AI in perl for example.
> >
> > There are bigger problems. Much bigger problems:
> >
> >   Suppose you want to implement something like CMA in perl. For this
> >   you have to have a way to "recalculate" a city
> >   (common/city:generic_city_refresh and all depending functions) at
> >   the client.
> >
> >   So this means either you recode all the city calculation
> >   in perl (city calculation uses a lot of information (other cities
> >   for trade routes, player for the government and the tax rates and so
> >   on)). So you would end up implementing a lot of common/* in
> >   perl. And you have to "port" new stuff like the upcoming generalized
> >   improvement code to perl.
> >
> >   Or you build an interface to the C-"core" which contains
> >   common/city:generic_city_refresh and Co. And then build a
> >   perl-interface using SWIG or doing it by hand. If you do this you
> >   can easily also generate interfaces to the send_* and receive_*
> >   functions.
> >
> > So the packet sending and receiving function are IMHO your smallest
> > problem.
> >
> > I have done this considerations in the past and came to the conclusion
> > that the first way is A LOT of work. In the second way you want a
> > small interface. For example you have no interest in the
> > receive_packet_ruleset_government function. You don't want to call
> > this from perl. You want to access the received data. So you want to
> > access the layout of struct government and the flags and enums of
> > common/common/government.h. And you want access to
> > get_government(). So you end up with a stripped-down client which
> > would consists of
> >  - the network part,
> >  - the caching part (cities, unit,...) and
> >  - code to do exact calculation (the same way the server would do it).
> >
> > You only need an perl-interface to the last two parts.
> >
> >     Raimar
> 
> use Inline; 
>  ... and the second way is easier.
> 
> 
> use Inline (C => Config =>
>         ENABLE => AUTOWRAP,
>         INC => '-I/src/freeciv-1.13.0/client',
>       );
> use Inline C => <<'END_OF_C_CODE';
> 
> 
> 
> #include "control.h"
> 
> void end_turn(void)
> {
>   send_turn_done();
> }
> 
> void move_unit_direction( struct unit *punit, int dir ){
> 
>     request_move_unit_direction( *punit, dir)
> }
> 
> /* etc */
> 
> END_OF_C_CODE

And what does this mean? I only know the basic perl features.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Just because you put a flag on the moon doesn't make it yours, it just
  puts a hole in the moon."