Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2002:
[Freeciv-Dev] Re: [PATCH] User-customizable defaults for command-line ar
Home

[Freeciv-Dev] Re: [PATCH] User-customizable defaults for command-line ar

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Cc: bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [PATCH] User-customizable defaults for command-line arguments (PR#1800)
From: "Baumans" <baumans@xxxxxxxxxxxxx>
Date: Mon, 22 Jul 2002 12:23:47 -0700 (PDT)

Here's yet another version. This one includes (untested) modifications to
the win32 client, code to set the default player name like it had been
before, and code to use the client's default tileset when one hasn't been
listed (rather than just trying isotrident).  It also removes the default
for the auto_connect setting, as that wasn't very useful.

-John Bauman
----- Original Message -----
From: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
To: <freeciv-dev@xxxxxxxxxxx>
Cc: <bugs@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 22, 2002 8:54 AM
Subject: [Freeciv-Dev] Re: [PATCH] User-customizable defaults for
command-line arguments (PR#1800)


> On Sun, Jul 21, 2002 at 07:03:52PM -0700, jdorje@xxxxxxxxxxxxxxxxxxxxx
wrote:
> > >>
> > >>I told him to do this, and I want it to break. This is going to go
away
> > >>anyway when client auth goes in. Besides, If you want it to be your
> > >>username, you can put in in the box and save it to your rc.
> > >>
> > >>Putting it back in complicates things. Is there really a good reason
to
> > >>have it?
> >
> > If this is an intentional change, then that's fine.  But, I'd think this
> > is an interface issue that should get some more input from other people.
> >   As a player, I'd rather have my username as the default login than
> > "guest".
> >
> > I see your point though, that with client authentication (however it is
> > handled) this code will have to be adjusted.
>
> I'll take a look at the new patch today hopefully, and I'll see how easy
> this is to do. client auth won't be for weeks at least, so it might be a
> simple stopgap.
>
> >
> > >>>Although I have no sound set installed, the default remains
stdsounds.
> > >>>It seems like after reading the soundset (and defaulting back to
"none",
> > >>>right?), this should be updated.  But this is a minor issue.
Similarly,
> > >>>isotrident remains the default tileset although I cannot use
isometric
> > >>>tilesets in XAW.
> > >>
> > >>hmm.
> > >
> > > There isn't really an easy way to update this, but at least it should
still
> > > work.  The tileset option might give a warning, although I should be
able to
> > > change that to prevent the warning.
> >
> > Upon further reflection, this is also a design issue that should get
> > some input.  Personally, I'd rather have it set up so that if your
> > specified tileset/soundset doesn't exist, the one that is loaded in its
> > place becomes the new specification (but won't be saved unless you "Save
> > Settings").
>
> I don't like this. I think that you really need to visit Game/Local
> Options to get anything saved into the rc file. Otherwise people will
> get surprised.
>
> >
> > In both of the above cases (username, tileset/soundset), I don't see why
> > it would be more complicated to change the value.  Just put an
> > strlcpy/snprintf at the appropriate place (somewhere in civclient.c for
> > the username, in the tileset/soundset loading code for the data sets).
> > But, there's still the question of whether that is *desired* behavior.
> >
>
> simply need to set tile_set_name = "\0" and then let the default take it
> depending on gtk/xaw. As for sound set, Raimar needs to speak up on
> this. stdsounds.spec is required for the client not to bomb, unless you
> specify a valid alternate set.
>
> > >>>Another minor issue: the autoconnect option doesn't work perfectly
with
> > >>>this system.  For instance, you can specify autoconnect=1 in your
> > >>>civclientrc.  Then there is no way to disable autoconnect, since the
> > >>>command-line option can only be used to enable it, not to disable it.
> > >>>This can be dealt with later, I think.
> > >>
> > >>interesting, perhaps we shouldn't put this in the options?
> > >
> > > I don't think this is very useful as one of the options.  Unless you
want to
> > > connect to the exact same server every time, which I think is rather
rare,
> > > there's no use.  If you're going to be typing other items in on the
command
> > > line to set up a different server, you might as well type "-a".
> >
> > I don't feel strongly either way.
>
> I'm starting to feel strongly. I think it's going to go away.
>
> -mike
>
>
>

Attachment: extoptions2.diff
Description: Binary data


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