Re: RFC: A single source for default values (FOCS, python, stringtables, backend)
Posted: Sat Nov 28, 2020 4:59 pm
Can all the *_PERPOP strings that just contain "per population" be removed now?
Forums for the FreeOrion project
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).
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).
Well, i want this to be a real tooltip (so not inline, but hovering), there it would not be non-sense.
Please, no.Ophiuchus wrote: ↑Mon Nov 30, 2020 7:47 amWell, 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)".
to be fair i didnt think you would sprinkle it over all the code base.
To be fair it was quite obvious from start:
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... ]".
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.
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
I expected that we would introduce that iterative in small portions where we actually need it and find out what UI we need.Oberlus wrote: ↑Mon Nov 30, 2020 10:36 amI 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).
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.
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"
I get you mean that, in case you change named value implementation, the work I've done up to now will require amendments.
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.
you can just skip them.
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).
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.
Code: Select all
import CalculatedValues print CalculatedValues.SupplyDisconnectedMalus
Does that mean that of the strings that currently just contain "per population" can be removed from the stringtables?
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).