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 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. ;) 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 at mapfa.de ___ 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 at mapfa.de ___ 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 matthias.pfaffer...@mapfa.de 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
On 01/07/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de 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
[Freeciv-Dev] settings rework
Hello all, at the moment I'm working with the settings definition. It started with the idea to load the settings from the ruleset (https://gna.org/bugs/?13621). After the discussion to this patch I started to rework the entire settings code. With help from mbook and pepeto I did 1. removed the extern flag from settings (https://gna.org/bugs/?13805) 2. created a new definition of the struct settings_s using a union (https://gna.org/bugs/?13810) NOW: 3. A cleanup of the files settings.(c|h). I would rename settings as options, 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). TODO: 4. possibility of callback functions for options if changed - aifill - aitoggle 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) 6. load options from ruleset - use game.setting.xyz for the settings 7. new option - skill string:easy|normal|hard skill level of new AI players 8. new command - default (set default values) 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 - other commands? The list can be found at http://freeciv.wikia.com/wiki/User:Syntron#Work_in_progress Matthias -- Matthias Pfafferodt - http://www.mapfa.de Matthias.Pfafferodt at 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 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? ... 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 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). 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
Re: [Freeciv-Dev] settings rework
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
