On 30/06/2009, Matthias Pfafferodt <matthias.pfaffer...@mapfa.de> wrote: > Am Tuesday 30 June 2009 22:36:11 schrieben Sie: >> On 30/06/2009, Matthias Pfafferodt <matthias.pfaffer...@mapfa.de> wrote: >> > I would rename settings as options, ... >> >> In the client the name "option" is already used for settings that >> are client-only (client/options.[ch]), so I don't think renaming to >> this in the server would be very helpful or useful. Is there some >> particular reason why you want to rename "setting" as "option" >> in the server? > > for one setting op is used and this is short for op(tion)? It is not needed > but I wanted to be consistent. I will leave it as setting(s_s) and > settings ...
Oh that. Maybe the "op" is a relic from ancient times when the settings were called options in the server too. It's not too bad as a variable name convention for settings, since it is at least used consistently and there is no other object type whose class name would have "op" as a short form. The thing is, using just "s" as the variable name might conflict with string variables, and "ss" is not much better (but probably as good as "op", if some other pointer-to-object variables do not use it already). Another possibility is "psetting" (like there is "pcity", "punit", etc.), though it is quite long. We can combine the best of both worlds and get "pset", which is short, unique (as far as I know) and reminds the programmer what the variable is (once they have seen it with its full type of 'struct setting *'). Variable naming is not that important, I would just suggest being consistent and using short names to save yourself the typing when the variable is used a lot. >> > TODO: >> > >> > 4. possibility of callback functions for options if changed >> > - aifill >> > - aitoggle >> >> Yes, this is probably a good idea. The other possibility is to >> change these "side-effect settings" to commands. > > The problem is, that aifill takes an int value as option and also that this > option (is/will be) used in scenarios. I would like to be able to define all > settings needed for the game into the ruleset file. This way only > rulesetdir ... is needed to start the game and the *serv file would be > obsolete. Alright, that sounds like a good plan. >> > 5. add functions to check / set options >> > - option_check(const struct settings_s *op, union setting_value >> > bisval) >> > - option_set(struct settings_s *op, union setting_value bisval) >> >> It's not really consistent to prefix the functions with "option_" >> and then operate on "settings_s" pointers. I would suggest >> to just use "setting_" as the prefix and use "setting" as the >> struct name, in keeping with general object oriented >> conventions. > > The name comes from the renaming idea (see 3.). I will use a function name > of > setting_*. You mean rename 'settings_s' to 'setting' like done for > 'command'? > (done in gna13810) Yes. The convention of appending "_s" to the struct name is not used in freeciv, so there is no reason to keep it here in this case (there are some bits of code that awkwardly use "setting" as a variable name which should probably be fixed, altough using "setting" as both the struct label and a variable name is not a syntax error). >> > 7. new option >> > - skill <string:easy|normal|hard> skill level of new AI players >> >> Fine, but in its own ticket please (each new feature should >> have its own patch). > > yes; each list point should be (at least) one ticket; if I get how to plan > my > work it will be several patches with each resulting in a working freeciv > version ... Sorry to keep reminding you about basic things you probably already know well; I do it also for anybody reading these discussions in the future. ;) >> > 8. new command >> > - default (set default values) >> >> A command to do this has already existed a long time in >> warclient; it is called /reset and I think this is a slightly better >> name than /default (for example in the future it could take >> parameters so you could "/reset settings", "/reset map", >> "/reset teams" etc.). > > OK; I will look into warclient. There are instructions on how to download and build it here: http://freeciv.wikia.com/wiki/Warclient > How many freeciv versions are out there? I knew of freeciv (the original), > warclient and longturn. Those are the 3 that are being "actively" developed. My longterm goal is to merge them all into one project. >> > 9. special fields within the ruleset >> > - game.default = [0/1] if all options should be set to the default >> > values - game.showchanged = [0/1] if changed values should be listed >> >> Is there a reason why you would want to disallow users from >> using the '/show changed' command? >> > > The idea is to (1) reset all settings before loading the values from the > ruleset and (2) show the settings changed by the ruleset. This would be in > addition to the available commands. The function to load the ruleset file > would evaluate this settings and act accordingly. I don't think it makes sense for the ruleset to reset all settings when it is loaded, since there are a lot of settings that really only affect the internal workings of the server or user interaction, rather than the game itself (for example timeout, savename, scorelog, etc.). Well, since over time a lot of very different things have been made "settings" this is hard to say definitively. So I suppose 'game.default' is alright (maybe call it 'game.reset_settings'), but the other flag should just be the default behavior: if some settings are changed when the ruleset is loaded, a message about it should be printed on the console and sent to all connections so that at least everyone knows what is going on. ---------------------------------------------------------------- 一緒にリセットしませんか。 _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
