Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2002:
[Freeciv-Dev] Re: server console cleanup patch v2
Home

[Freeciv-Dev] Re: server console cleanup patch v2

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: server console cleanup patch v2
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Tue, 8 Jan 2002 13:07:31 +0100 (MET)

On Tue, 8 Jan 2002, Reinier Post wrote:
> All I wanted to say was, the existing PACKET_RUILESET_* packets don't do it
> that way, you want to replace them with a packet that does this.

Ah, but I didn't even think about the existing ruleset packets. Now that I
do, I see potential for simplifying and generalizing them in the same way,
which would make them upwards-compatible too. I think all we need is a
single packet

  packet_ruleset {
        char *ruleset_name
        char *ruleset_buffer
  }

Then the client parses it in the same manner as the server... possibly
using some of the same code.

(Actually, the registry code translates rulesets into a hashtable when
loaded, so we could send this hashtable buffer instead of an unparsed
ruleset. I don't know if the process of translating from ruleset to
hashtable takes a trivial amount of time or not. I'd have to look into
that.)

That would make it easy again to modify these rulesets along with and in
the same way as the game options. (I imagine a tabbed tree widget would do
the trick. A tree widget for each ruleset, chosen by tabs.)

> > but since this struct is not used for lookups during
> > the game, there is no need to encode the ruleset info into a new format.
>
> There will be if the client GUI to set server options is to support
> server options that do not exist at the time the client is compiled.

No. Look, what I suggest is a GUI dialog which is a tree widget, where
each option is added as a node on run-time, and each node is interpreted
on the fly to generate a GUI interface for the option. Think Windows
"regedit" or MacOS NetInfo editor.

This is not very hard to do, because of the very intelligent way the
registry works. To quote common/registry.c a bit, even the complex
tabular format is be broken down into easily represented types:

 89   - Tabular format:  The lines:
 90       foo = { "bar",  "baz",   "bax"
 91               "wow",   10,     -5
 92               "cool",  "str"
 93               "hmm",    314,   99, 33, 11
 94       }
 95   are equivalent to the following:
 96       foo0.bar = "wow"
 97       foo0.baz = 10
 98       foo0.bax = -5
 99       foo1.bar = "cool"
100       foo1.baz = "str"
101       foo2.bar = "hmm"
102       foo2.baz = 314
103       foo2.bax = 99
104       foo2.bax,1 = 33
105       foo2.bax,2 = 11

Since they are broken down in this manner, they can easily be dynamically
rebuilt into GUI controls that are more human readable than a mere list of
values.

> > The client must encode the data in a GUI-dependent fashion, though.
>
> ?? Why?

Because the data has to be stuffed into a tree widget. That doesn't mean
the data can't be represented in some other way as well, but I don't
think that is necessary.

> OK, well I suppose this would be game.ruleset?

Putting it into game.ruleset might be a good idea, yes.

> Your example in that syntax becomes
>
>   [game_timeout]
>   name                = _("timeout")
>   min         = 0
>   max         = 80
>   helptext    = _("\
>   "Sets timeout for for blah blah blah\
>   ")
>
> Perhaps a 'type' field is a good idea:
>
>   type                = "integer"
>
> but perhaps that is implied by the existence of 'min' and/or 'max'.
> Also there would be
>
>   default     = 0
>   cmdlevel    = "ctrl"

Thank you, this is _much_ better than what I was suggesting.

> (My suggestion was to automatically have /set min<foo> and /set max<foo>
> commands for every <foo> variable that has min and max attributes, but
> that doesn't make sense.  What makes more sense is to support this 
> generically:
>
>   /set timeout.max = 40
>   /set timeout.helptext = "I don't care what language you speak, this is the 
> help text for timeout."
>
> I.e. a generic interface to modify the ruleset at runtime.
> We've discussed this before and it is not at all needed.)

That would not be too hard, but I don't see the need for it.

> Not for civserver.freeciv.org use.  We have a wrapper there that talks with
> civserver over stdin/stdout.

Ok. It would not be too hard to rewrite server/stdinhand.c to use the new
setup. Or rip it out to create a new controller program like Raimar
suggested. I am undecided on which is better.

Yours,
Per

"Oil industry spokesmen dismissed as "absurd" and "nonsense" allegations
by aid experts, veteran East Africa analysts and several prominent Somalis
that President Bush, a former Texas oilman, was moved to act in Somalia,
at least in part, by the U.S. corporate oil stake." -- L.A. Times



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