> The tests you get when you run:
> "ant prepare-commit"
Ouh! I didn't know it.
I'll try that.
When i said i have tested, i meant the game itself.
I have tried every possible scenario in the game i can think of.
> - The "independence turn" (1780) is hard coded in IGC, and nowhere else.
I have already seen this unhardcode change in the newest git rev.
I think there is one small problem with this: it stores the turn, not the year.
Because when the number of seasons changes, this value also needs to be changed.
Of course the model.option.independenceTurn is in the specification,
so a Season mod should just overwrite this, and we have no problem.
But i think you have missed something about this: model.option.seasonYear
The user (player) can change the year when the seasons start to work.
And this option also invalidates the independence turn number, so it should
be recalculated when it changes.
So IMHO it would be better to store the independence year, and calculate
it to independence turn according to the current number of seasons and
seasonYear.
And this applies to everything which is a predefined time-related thing,
for example the ages. They should also be stored as year instead of turn.
> With that in place I can fix Turn so that it only needs to know the
> number of seasons (using an initialization call from Specification,
> like is used for the season-year). That will almost completely remove
> any need for Turn routines to need Specification parameters.
Good idea.
> The naming could just be:
> model.season.0=Spring
> model.season.1=Autumn
> There is code in NameCache for reading groups of indexed messages like
> model.season.*.
> All that would be needed then to make the number of seasons variable
> is a single game option (in gameOptions.years) that controls the
> initialization of Turn:
> <integerOption id="model.option.numberOfSeasons"
> value="2" defaultValue="2" minimumValue="2"/>
> Mods would override this and provide the alternate names as above.
I think it is not a good idea to completely separate the setting of names
and the number of seasons.
Imagine:
The user loads the MonthSeasons, and sets the number of seasons to 10.
Then he/she will have months from January to October, so the MonthSeasons
would be truncated. The same applies to DaySeasons.
> For the mods with many seasons it would be easier to make the display
> routines check Messages.containsKey and on failure fall back to using
> something like:
> model.season.default=Week %number%
> That seems like a better result to me.
But with this, how can you make a mod like the MonthSeasons ?
Or the DaysSeasons?
> No funky double message interpretation.
What is the double in that?
Have you seen DaySeasons?
It has names like this:
"%model.season.march.name% 1"
If we erase formatMessage(), then the name resoultion will everytime
results model.season.default. :(
Ok, you can say that then i should use full names in the mod, like
"March 1"
But that is not language independent!!
"%model.season.march.name% 1" <- this version has the benefit that
the base messages will be completely translated, and the mod can use
the strings of that, so it will be automatically localized!
"%model.season.march.name% 1" <- this will result "March 1" when
English language is selected,
and it will result as "Március 1" when Hungarian language selected.
Please say that you don't want to broke this localization possibility.
> One new integer option rather than a whole new specification section.
> Detail is moved to the spec and messages files where it belongs.
Ok, if you want, i can make a Version-4 where there is no Season.java,
and it uses this scheme:
model.season.0=Spring
model.season.1=Autumn
But please do not broke the localization possibility,
and do not make a separate visible game option of the number of seasons
(the number of seasons should also be changeable only from a mod,
so the number of seasons and the season names SHOULD have been linked together)
Regards,
Fenyo
------------------------------------------------------------------------------
_______________________________________________
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
