>>>[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.
Ok, i understand.
Then leave it as it is.
But i think the ages should remain as years instead of turns.
> 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".
That is a good idea!
> 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.
This is also a good idea, and this is how my patch works now.
(but with spec instead of messages)
> 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.
I think that might not be a bad, but rather a good thing.
Why?
Because a typo will come to the surface sooner!
This is very similar that some programming languages are stronger-typed,
so an error could even come to the surface at compile-time, instead of run-time.
> If you insist on having the month name in there, you are stuck with
> specifying every day: model.season.{0,1,2...365}
Yes. This is why the daySeasons is 27 KBytes long. :)
I think it worths it.
It looks much better in the game. :)
>> 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.
>
> I do not want to add another localization mechanism. I want to use the
> one we have.
Ok, you won.
I'll remove Messages.formatMessage().
> 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.
Ok.
Then give me a green light for the new modifications when you are done.
Regards,
Fenyo------------------------------------------------------------------------------
_______________________________________________
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
