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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jan 07, 2002 at 08:37:46PM +0100, Per I. Mathisen wrote:
> On Mon, 7 Jan 2002, Reinier Post wrote:
> > Yes, and I was trying to say, for that you need a different packet format,
> > with both the values and the attribute names.
> 
> No, can just send it all as a single string, eg "topic.ouroption.somewhere
> = { "first", "second",\n 15, 13 }", then pass it to registry functions to
> parse.
> 
> > Once you have that, the code on the receiving end must encode the data
> > structure not in the C struct but in an associative array, similar to
> > the settings structure in server/stdinhand.c but with a hash for the
> > attribute names.
> 
> I don't see why. This scheme would replace the settings struct in
> server/stdinhand, 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.
> 
> The client must encode the data in a GUI-dependent fashion, though.
> 
> > I don't know, it seems acceptable to have a command like /set mintimeout 40
> > so perhaps min* and max* can be regular variables.
> 
> I am not sure if I understand what you mean. What I have in mind is
> something like this:
> 
> [topic]
> mintimeout = 40
> mintimeout.min = 0
> mintimeout.max = 80
> mintimeout.helptext = "Sets timeout for for blah blah blah"
> nextoption = ...
> 
> > It's different for variables that take file paths or player names.
> 
> And some ints that must be lower/higher than another int, etc etc... there
> are numerous "special cases" that must be checked+bounced from the server,
> anyway, so I'm not entirely convinced that min/max info should be in the
> ruleset...

I'm not sure if I understand you all the way. However I want to point
out that all the data for an option is now quite nicely put in one
place (server/stdinhand.c). So what is the advantage to move things
out of this file?

> > It would be good to still have the cmdline interface in the server binary,
> > otherwise you need to start up two programs just to run a server.
> 
> No, that will not be necessary.
> 
>       $ civserver --read these.rules
>       - or -
>       $ civserver --read debug.rules --autostart
> 
> Gives you all you need without a client. Among these rules can be eg
> aifill and create (ie moving commands into ruleset).

And where does an operator/admin can issue a "wall" command?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  "The primary purpose of the DATA statement is to give names to
   constants; instead of referring to pi as 3.141592653589793 at every
   appearance, the variable PI can be given that value with a DATA
   statement and used instead of the longer form of the constant. This
   also simplifies modifying the program, should the value of pi
   change."
    -- FORTRAN manual for Xerox Computers