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

["Rafa³ Bursig" <bursig@xxxxxxxxx>]

On 2003.08.20 18:55, Mike Kaufman wrote:
> 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.

This can be partialy fixed by changed idetification method in my net 
support. Curretn I want make it as simple as can and I use int field as 
option idx in packet. When you remove or add new option then you 
corrupt old clients (without capabilities changes) but this can be easy 
fixed by changed int id to string id (option name as id) in packet. In 
this case old client simple ignore new options and don't corrupt with 
removed ones.

There will be only problem with type changes becouse name be the same 
and server and client will have different type of varaible. In this 
case we should use different options name with such changes.

Sharing options struct will give you this advances that you know all 
options before connection(server start) and you can simple start single 
player server with all options canges at one call. This give you nice 
clean code that do it.

> > > 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.
This will be nice packet ;)

> > How many of those vars will changed with different "rulesets" ?
> 
> no idea. so what?
how many of those variable will be changed with different "ruleset" or 
modpack or other enviroment settings.
How often we will have situations that number of options , type of 
options , name of options , etc... will be changed ?

> 
> > "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.
> 
My code do it now.

> > Even in this method you must sync settings with client?
> 
> sure. the settings are synced, but over the network rather than
> hardcoded.

Mike my code exist and work (I will send fixed new vesion soon - string 
packet option idx), if you don't like this implementation then please 
MAKE BETTER, but please do it soon becouse I have ready code that need 
such functionality.

Rafal