Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2003:
[Freeciv-Dev] Re: (PR#5121) move server command structs/ids/help/etc to
Home

[Freeciv-Dev] Re: (PR#5121) move server command structs/ids/help/etc to

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bursig@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#5121) move server command structs/ids/help/etc to common code
From: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 20 Aug 2003 09:55:03 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Wed, Aug 20, 2003 at 09:36:09AM -0700, Rafa³ Bursig wrote:
> When you want change "citymindist" option you must know it current 
> value on server. It is easy when you manualy use console commands but 
> GUI implementation with string comp. will look ugly. IMHO beter 
> solutions is when client know real states of setable server options.
> With this patch server sent all options states (with SSET_TO_CLIENT 
> class) to client and those can be configurable via client GUI.

I think you're missing the point. What happens when a remote server
removes, for example, the aifill option? Or adds some smallpox-killing
options? This should have zero effect on the capabilities of the client.

> > A better option would be to send options and commands over the wire
> > like we do rulesets. This would also be helpful for the GTK connect 
> > dialogs.
> What do you want sent :
> - command name
> - command short help
> - command extra help
> - option name
> - option short help
> - option extra help
> - option state
> - option min state
> - option max state
> - option def state

yep.
 
> How many of those vars will changed with different "rulesets" ?

no idea. so what?

> "When"/"How often" you want sent this info ?

at login, all info should be sent. if an option is changed, the individual
option should be sent as a single packet.

> Even in this method you must sync settings with client?

sure. the settings are synced, but over the network rather than hardcoded.

-mike



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