Re: [Freeciv-Dev] settings rework
On 01/07/2009, Matthias Pfafferodt wrote: > > I did rename op_* to pset_* as it matches the purpose of the variable: a > pointer to a setting struct Do this for variable names whose type is 'struct setting *' or 'const struct setting *' only, not function names. >> > 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. > > ... and also a download of the longturn svn ... > > Do you can say something more about this plan? More details would be here: http://freeciv.wikia.com/wiki/User:Mbook > I read that your first priority is the editor for freeciv 2.2. What are > the most important points to merge into freeciv? They are listed on the page above, but really only users of those programs would know this... > Tips how to do it? Ask people playing on warclient/longturn servers about what warclient/longturn features they absolutely cannot live without, then re-implement those features in 2.1 and trunk, usually by copying and adapting (rewriting) code from their repositories. 書き直す罰ゲーム。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] settings rework
On 01/07/2009, Matthias Pfafferodt wrote: >> Those are the 3 that are being "actively" developed. My >> longterm goal is to merge them all into one project. > > Looking through the patches of longturn and warclient I found the > patch 'Setting to control distance of traderoutes.' (longturn 20090623). > This > is something I also wanted to implement for the standard freeciv ... > > What are the rules to merge patches from warclient or longturn into the main > freeciv? You submit them like other feature/bugfix patches, because they are usually implemented in a not very clean manner and need to be checked. キタナイ！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] settings rework
> Those are the 3 that are being "actively" developed. My > longterm goal is to merge them all into one project. Looking through the patches of longturn and warclient I found the patch 'Setting to control distance of traderoutes.' (longturn 20090623). This is something I also wanted to implement for the standard freeciv ... What are the rules to merge patches from warclient or longturn into the main freeciv? Matthias -- Matthias Pfafferodt - http://www.mapfa.de Matthias.Pfafferodt mapfa.de ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] settings rework
> 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 *'). I did rename op_* to pset_* as it matches the purpose of the variable: a pointer to a setting struct [...] > 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). This should even less a problem as the struct settings is only define within settings.c > > >> > 7. new option > >> > - skill 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. ;) It is good to read it from somebody else. So I know it is the right way to do > > >> > 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 I do a download of the warclient svn at the moment ... > > > 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. ... and also a download of the longturn svn ... Do you can say something more about this plan? I read that your first priority is the editor for freeciv 2.2. What are the most important points to merge into freeciv? Tips how to do it? Matthias > > >> > 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. > > > > 一緒にリセットしませんか。 -- Matthias Pfafferodt - http://www.mapfa.de Matthias.Pfafferodt mapfa.de ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] settings rework
On 30/06/2009, Matthias Pfafferodt wrote: > Am Tuesday 30 June 2009 22:36:11 schrieben Sie: >> On 30/06/2009, Matthias Pfafferodt 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 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
Re: [Freeciv-Dev] settings rework
On 30/06/2009, Matthias Pfafferodt 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? > ... move the all the struct as well as all the inline functions into > settings.c and define the missing functions. This way the struct > is only defined within settings.c (like the struct command in > command.c). Good. > TODO: > > 4. possibility of callback functions for options if changed > - aifill > - aitoggle (I suppose you meant 'autotoggle' instead of 'aitoggle'.) Yes, this is probably a good idea. The other possibility is to change these "side-effect settings" to commands. > 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. You can also call the union something less verbose, perhaps 'union setval' (since it's not really part of the 'setting' "class", but just a little helper data structure). > 7. new option > - skill skill level of new AI players Fine, but in its own ticket please (each new feature should have its own patch). > 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.). > 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? 計画には反対しません。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
