[Freeciv-Dev] Re: [PATCH] User-configurable default tileset

["Baumans" <baumans@xxxxxxxxxxxxx>]

Here's the next version.  It uses fc_malloc to initialize the strings (with
a length of MAX_LEN_OPTION_STR), and then, if there are no commandline
arguments specifying otherwise, it copies what it loads from the file to the
original variables.  This version also includes gui code for the xaw client
(though it's untested, because I can't get the xaw client to work. The code
in civclient.c is relatively messy, but I can't think of a better way,
except for a modified version of my original:  we use mystrdup for those
variables when we load them, or when they're modified ("free"ing
appropriately), and we use mystrlcpy to copy these into the variables that
are actually used in the game.

----- Original Message -----
From: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
To: "Baumans" <baumans@xxxxxxxxxxxxx>
Sent: Friday, July 19, 2002 11:56 AM
Subject: Re: [Freeciv-Dev] [PATCH] User-configurable default tileset


> On Fri, Jul 19, 2002 at 02:43:16AM -0400, Baumans wrote:
> > >
> > > o you must be able to plug them into the client_options struct.
> > Done so far.
> > > o a command line argument will override the rc option.
> > Ditto.
> > > o if you use a command line argument and then save options, you will
not
> > >   save the command line argument as the default.
> > I didn't know if I should do this one or not, but I think your way will
be
> > better.
> > > o also if you use the command line arg, the saved rc option will still
> > >   show up in the options dialog.
> > Easy if I change it like the above.
> > > o mystrdup is a problem this it allocs just enough for the string.
This
> > >   is bad in the case of things like player_name or server_host which
> > >   might be changed during runtime. I need a solution that allows this.
> > >   Perhaps do a fc_malloc for some space at the beginning of main(),
and
> > >   then do mystrlcpy.
> > Is there just going to be a default size for every item, or how can we
set
> > this up? We can do static allocations(like in your example), but you're
> > still going to have to limit the length of the mystrlcpy.
>
> If you can figure out a way to do static allocations and use sz_strlcpy,
> this that's the best way. (however, that (I believe) causes a major mess
> (unfixable?) in the client options struct. (though you could define a
> pointer to the static array and then pass that into the client_options
> struct (if the compiler will let you do it).
>
> Otherwise, you can add yet another field in client_options specififying
the
> string length. I would actually do this before defining a
> MAX_LEN_OPTION_STR to be 512 and use that for all of them. (It's not
> that big a deal to add stuff to the struct).
>
> (The other issue is defining a default value for the option. It's easy
> for the tileset, because if you pass in a non-valid option, you get
> isotrident, but what about sound_set_name? I would prefer not to have
> hardcoded defaults spread around in various places in the code. If we
> need hardcoded defaults they should all go in a single place).
>
> > >
> > >
> > > o don't touch anything in tilespec.c, manipulate tile_set_name, and
then
> > >   pass in the tileset name that you want. If it doesn't exist, the
> > >   hardcoded default will be selected.
> > I wanted it to fall back to the .civclientrc default first, but that
does
> > seem to make it too complicated.
>
> passing it in will do this too.
>
> -mike
>
>

tilech4.diff
Description: Binary data