Ophiuchus wrote: ↑Mon Nov 30, 2020 4:11 pm
I expected that we would introduce that iterative in small portions where we actually need it and find out what UI we need.
To my surprise you went and changed a lot of places in a rather mechanical way.
In my perception, I wasn't being "rather mechanical", as in unthinking, but systematic and following a work process to reduce merge conflicts (between multiple PRs that touched the same files) and save some unnecessary work (some may feel I don't value my time as much as others value theirs, but it's a misconception) and to help me avoid extra opportunities to commit mistakes.
Each hardcoded value I changed was being (or should be) referenced in the stringtables, the specific values for which some of us originally asked for a single source of default values: to avoid having to edit several files when changing a single value (to ease up the process of modding or balancing FreeOrion's content).
And I stopped sprinkling named values, probably too late, well after I realized current implementation of named values (particularly that thingy about having to define those annoying extra strings for each named value) wasn't what I expected or asked for, because some begun to question the named values in some many places. Otherwise you would see then all over the place (which, again, was what I asked for since the begining).
Don't get me wrong, as I already told you, your implementation of named values is super useful to have single sources of default values, it's just that there must be a way to do it better, without the unnecessary&annoying strings in the stringtables.
Ophiuchus wrote: ↑Mon Nov 30, 2020 4:11 pm
Dont get me wrong, that is also good, just not what i expected.
Ah, OK. I'm glad to know you were not expressing negative criticism, as in "to be fair i didnt think you would sprinkle it over all the code base" or in "To my surprise you went and changed a lot of places in a rather mechanical way"
Also I hope I have made myself sufficiently clear about what I expect from the "single source for default values", which is named values for anything that is defined in a FOCS file and is later use in stringtables or AI files. However I'm not sure we have reached that understanding and I would like to know if you agree with my expectations or if you think that I don't understand the issues involved here and so should leave the subject.
Ophiuchus wrote: ↑Mon Nov 30, 2020 4:11 pm
It has the downside that changes now have to happen in many places if change something.
I get you mean that, in case you change named value implementation, the work I've done up to now will require amendments.
If that's the case:
- I will do it happily, much more happily than having to add the remaining several hundreds of unnecessary strings in the English and Spanish stringtables (I dunno about other translators).
- The first times I expressed concern about those strings, I was told that they were necessary for the whole thing to work. I doubted that was true, but accepted it and continue doing substitutions without expressing any judgement. If in the end we can indeed get rid of those strings and I could have skipped all that unfulfilling work that is now being questioned, I will feel a bit disappointed.
For simple cases there is the AI use case (so i still disagree that all of those simple cases should be macros). I will probably add AI support for named values in the next two months. I do not think anybody will implement macro support for AI.
Do whatever you deem better. A few more months of extra work to get AI working doesn't seem like a big deal.
However I still think it's a pity that no body will implement an easier and faster-to-get solution, knowing that Python could just read .py files with the calculated values dumped at game start during/after parsing, the same than stringtables could include macro files with those same values.
