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: Reinier Post <rp@xxxxxxxxxx>
Date: Tue, 8 Jan 2002 12:06:08 +0100

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.

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.

> > 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,

Yes.

> 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.
 
> The client must encode the data in a GUI-dependent fashion, though.

?? Why?

> > 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 = ...

OK, well I suppose this would be game.ruleset?  It currently has
entries like this:

  ; Minimum distance between cities (move distance).
  ; (Minimum value for this is 1, which means adjacent is okay.)
  min_dist_bw_cities      = 2
  
  ; Square of initially visible radius (true distance).
  init_vis_radius_sq      = 5

There would have to be subfields; units.ruleset already has a syntax for that:
e.g.

  [unit_engineers]
  name          = _("Engineers")
  move_type     = "Land"
  [...]
  helptext      = _("\
  Engineers are similar to Settlers, but they work twice as fast and\
  [...]
  ")

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"

(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.)

> > 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...

Everything that is easy to support generically within the client GUI
is worthwhile to send.  This is the info that /show displays - it doesn't
display the special case checks, either.
 
> > 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.

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

-- 
Reinier


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