RFC: A single source for default values (FOCS, python, stringtables, backend)
Moderator: Oberlus
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Can all the *_PERPOP strings that just contain "per population" be removed now?
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
I would like that all those strings could be removed, regardless of the text you put on them (per population, per whatever...), they are just a hindrance and convey no information that is not already present in the main description strings (the ones calling to these other strings).Geoff the Medio wrote: ↑Sat Nov 28, 2020 4:59 pm Can all the *_PERPOP strings that just contain "per population" be removed now?
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
If context information is not considered helpful, what would be considered helpful?Oberlus wrote: ↑Sat Nov 28, 2020 5:17 pmI would like that all those strings could be removed, regardless of the text you put on them (per population, per whatever...), they are just a hindrance and convey no information that is not already present in the main description strings (the ones calling to these other strings).Geoff the Medio wrote: ↑Sat Nov 28, 2020 4:59 pm Can all the *_PERPOP strings that just contain "per population" be removed now?
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Look, ma... four combat bouts!
Look, ma... four combat bouts!
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
The information on the calculation of the value, things like 1.0 * [[INDUSTRY_PER_POP]], shown as "0.2" --tooltip-> "1.0 x 0.2", can have some use when debugging (not much for normal playing).
But the suffixes like "per population" are better removed: "increases Industry by 0.2 per population" --tooltip-> "increases Industry by 1.0 x 0.2 (per population) per population" makes no sense.
But the suffixes like "per population" are better removed: "increases Industry by 0.2 per population" --tooltip-> "increases Industry by 1.0 x 0.2 (per population) per population" makes no sense.
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Well, i want this to be a real tooltip (so not inline, but hovering), there it would not be non-sense.
So the text will be "increases Industry by 0.2 per population"
and the tooltip box on mouseover will read: "1.0 x 0.2 (per population)".
of course it could read something different, e.g. "1.0 x 0.2", "1.0 x 0.2 PP industry per population".
Last edited by Ophiuchus on Mon Nov 30, 2020 8:49 am, edited 2 times in total.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Look, ma... four combat bouts!
Look, ma... four combat bouts!
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Please, no.
Why do we need "per population" twice in the same text? (the tooltip is part of the same text).
It is not helpful and it is quite annoying implementation-wise.
PS: In my ideal world, all this was just about allowing to put calculated values in the stringtables. The only think useful for that is having the [[value XXX]] expanding to a calculated value. That's all.
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
to be fair i didnt think you would sprinkle it over all the code base.
originally i thought more about some textual description to substitute for inline use, but that didnt manifest.
The more simple the value ref, the less of an explanation it needs e.g. "1.0" for a static value is pretty useless. "1.0 x GameRule blabla" helps the player understand where the value is coming from and where to tweak this. But "count of visible armed enemy ships" could be more helpful than a " (Statistic COUNT condition = And [ Ship OwnedBy = sadfds ...long visibility condition... ]".
On another thought "Good industry population effect: adds 0.2 PP industry per population (species effect, applies at priority 100)" would be rather a effect description.
i saw some places in the stringtables where the use site was well written but did not include the per-??? information and it would have been helpful. fuel tanks maybe?
so there I thought hiding information is good for readability, but sometimes you need access to the nitty gritty details. so maybe what i want is rather a generic tooltip tag for the pedia.
so, yes remove it where it is unnecessary - not sure why you added it there in the first place
edit1: in the named value refs overview it is helpful to have the context information, but it is certainly only a nice-to-have and not necessary at all
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Look, ma... four combat bouts!
Look, ma... four combat bouts!
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
To be fair it was quite obvious from start:
"A single source for default values", so that changing any value in the FOCS files does not require updating each of the language stringtables.
And that purpose was stated several times in several places.
/Edit: e.g.
What values:
An example where all effects of a given set of techs were given a single source for default values:
/
Yes, and we get all that context written in the stringtable entries. The only thing that needs to be provided by the [[value XXX]] macros is the actual calculated values."1.0 x GameRule blabla" helps the player understand where the value is coming from and where to tweak this. But "count of visible armed enemy ships" could be more helpful than a " (Statistic COUNT condition = And [ Ship OwnedBy = sadfds ...long visibility condition... ]".
There are many places were stringtables are ambiguous or does not provide all information. That is fixed by redoing those texts in the stringtable files.
That could be good. It would be a more sofisticated way than using specific Pedia pages, for example.so there I thought hiding information is good for readability, but sometimes you need access to the nitty gritty details. so maybe what i want is rather a generic tooltip tag for the pedia.
Certainly not urgent.
I don't know what you mean (unless you refer to using calculated values for simple macros without calculations, that should better use simple macro expansion; that has been already said).so, yes remove it where it is unnecessary - not sure why you added it there in the first place
I would welcome a way to achieve that page working like you like it without making stringtables as ugly and cumbersome as they are right now, otherwise I rather live without that page but with easier stringtables.edit1: in the named value refs overview it is helpful to have the context information, but it is certainly only a nice-to-have and not necessary at all
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
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. Dont get me wrong, that is also good, just not what i expected. It has the benefit of most of the work being done. It has the downside that changes now have to happen in many places if change something.
For simple macros without calculations 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.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Look, ma... four combat bouts!
Look, ma... four combat bouts!
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
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.
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.
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.
Do whatever you deem better. A few more months of extra work to get AI working doesn't seem like a big deal.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.
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.
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
you can just skip them.
but you can use them where you consider adding extra information to the tooltip to be useful
Agreed. Just the details were not pinned down yet. Not sure everything is pinned down now, but implementation is not finished (e.g. the inline tooltips and the number format stuff).
it was true at the time. i found out how to make those optional later on.
I saw your suggestion. To me the payoff/cost ratio looks much worse. I think i would need to spend at least the same amount of time and get less out of it. I need to understand how the c++/python interface works anyway (so no additional cost) and looking up a value by name should be pretty straightforward (like 5 minutes of work once you know how it is done).
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Look, ma... four combat bouts!
Look, ma... four combat bouts!
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Really? That's great. I thought I could only skip the ones with empty strings.
And you also said you didn't have the time to read it. Maybe you read it now. Anyways, I don't think you are right in your statements.
The interface with Python in my suggestion.
- FOCS Parser (C++) writes calculatedValues.py
- Python includes those files:
Code: Select all
import CalculatedValues
print CalculatedValues.SupplyDisconnectedMalus
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
I read it and said I don't have the time to follow through/discuss the details
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Look, ma... four combat bouts!
Look, ma... four combat bouts!
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Does that mean that of the strings that currently just contain "per population" can be removed from the stringtables?
Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Roger.
I take it as yes. From the strings I added myself, I can't remember of any that contained important information. I would remove all of them (I will be glad to do it once I get free time, maybe by the end of this year).Geoff the Medio wrote: ↑Tue Dec 01, 2020 5:00 pm Does that mean that of the strings that currently just contain "per population" can be removed from the stringtables?