On Fri, 29 May 2015 19:57:04 +0200 Fenyo <feny...@gmail.com> wrote: >>[Independence turn] > I think there is one small problem with this: it stores the turn, not the > year.
Yes, deliberately. If you use the year but increase the seasons you
make it progressively more easy to get the bonus, and the bonus available
continues to increase. IMHO that is a balance problem. I put in some
effort in a previous release to make the scoring algorithm as
Col1-compatible as possible. Using the turn makes scores comparable no
matter what a player does with the seasons. All that changes is the
actual year that the bonus applies at, which is less important than score
compatibility IMHO.
> Of course the model.option.independenceTurn is in the specification,
> so a Season mod should just overwrite this
It could, but it should not.
> But i think you have missed something about this: model.option.seasonYear
Indeed not. In fact, there was a compliant a while back on a forum about
using seasonYear to artificially increase the amount of turns and thereby
get a higher score. That is what prompted me to switch to using the turn
when moving that magic number to the spec. Apparently, as usual, I can not
please everyone.
> 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.
There are *lots* of places where users can muck things around with the
option settings. Ultimately all we can do is provide sensible defaults.
If you are really worried by this, have the mod override the option and add
value="12" minValue="12" maxValue="12". The alternative is to not have
any option, and set the number of seasons from the contiguous messages
found, somewhat like we do with settlement names. I considered that, but
it is brittle against typos in the messages file (which has happened) and
probably too risky for a number that controls the turn-to-year conversion.
> > 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 ?
What is wrong with:
model.season.0=January
...
> DaySeasons
If you insist on having the month name in there, you are stuck with
specifying every day: model.season.{0,1,2...365}
model.season.default is just intended to be a shortcut or fallback for
simple cases like the above week example, only used if the expected
model.season.*number* message is missing.
> > No funky double message interpretation.
>
> What is the double in that?
1. Look up messages for model.season.day.0
2. Get "%model.season.january.name% 1"
3. Look up messages for model.season.january
I see two lookup steps there. If there were other places we did something
like that, fair enough, but as a convenience for implementing a pretty
weird mod (4 seasons: fine, 12 seasons: strange, 355 seasons: crazy) when
there is a simple alternative, I am not convinced.
> If we erase formatMessage(), then the name resoultion will everytime
> results model.season.default. :(
No. Once again, all you have to do for the days mod is specify the full
name in the numeric message format for every day:
model.season.0=January 1
model.season.1=January 2
...
> 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.
That is a separate issue. Mods can contain translated versions of the
messages file too. If they are there, they will be used. We have a
problem at present that mods are not getting translations, which is on my
list of things to sort out with the translators, however I have been
causing them quite enough grief lately and there are worse problems that
need fixing.
Tell you what, if this is really annoying you, I will revise my
previous remark about not supplying translation files, and accept
translations for *mods*, at least until getting around to a better
solution. So data/mods/DaySeasons/FreeColMessages_hu.properties is ok,
but not data/strings/FreeColMessages_hu.properties.
> Please say that you don't want to broke this localization possibility.
I do not want to add another localization mechanism. I want to use the
one we have.
> Ok, if you want, i can make a Version-4 where there is no Season.java,
I recommend you wait a bit until I have fixed the problems with Turn.
Less annoying rebasing for all of us, and I may yet be wrong about how
fixable it is.
Cheers,
Mike Pope
pgpYl2mhc8IJm.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
