RFC: A single source for default values (FOCS, python, stringtables, backend)

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderator: Oberlus

Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#61 Post by Geoff the Medio »

Can all the *_PERPOP strings that just contain "per population" be removed now?

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#62 Post by Oberlus »

Geoff the Medio wrote: Sat Nov 28, 2020 4:59 pm Can all the *_PERPOP strings that just contain "per population" be removed now?
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).

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#63 Post by Ophiuchus »

Oberlus wrote: Sat Nov 28, 2020 5:17 pm
Geoff the Medio wrote: Sat Nov 28, 2020 4:59 pm Can all the *_PERPOP strings that just contain "per population" be removed now?
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?
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!

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#64 Post by Oberlus »

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.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#65 Post by Ophiuchus »

Oberlus wrote: Sun Nov 29, 2020 10:16 pm "increases Industry by 1.0 x 0.2 (per population) per population" makes no sense.
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!

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#66 Post by Oberlus »

Ophiuchus wrote: Mon Nov 30, 2020 7:47 am
Oberlus wrote: Sun Nov 29, 2020 10:16 pm "increases Industry by 1.0 x 0.2 (per population) per population" makes no sense.
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)".
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.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#67 Post by Ophiuchus »

Oberlus wrote: Mon Nov 30, 2020 8:27 am It is not helpful and it is quite annoying implementation-wise.
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 :D

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!

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#68 Post by Oberlus »

Ophiuchus wrote: Mon Nov 30, 2020 10:11 am
Oberlus wrote: Mon Nov 30, 2020 8:27 am It is not helpful and it is quite annoying implementation-wise.
to be fair i didnt think you would sprinkle it over all the code base.
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:
Oberlus wrote: Sat Nov 16, 2019 2:07 pm
An example where all effects of a given set of techs were given a single source for default values:
Oberlus wrote: Fri May 29, 2020 9:31 am
/
"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... ]".
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.

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.
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.
That could be good. It would be a more sofisticated way than using specific Pedia pages, for example.
Certainly not urgent.
so, yes remove it where it is unnecessary - not sure why you added it there in the first place :D
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).
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 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.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#69 Post by Ophiuchus »

Oberlus wrote: Mon Nov 30, 2020 10:36 am
Ophiuchus wrote: Mon Nov 30, 2020 10:11 am so, yes remove it where it is unnecessary - not sure why you added it there in the first place :D
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).
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!

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#70 Post by Oberlus »

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" :roll:
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.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#71 Post by Ophiuchus »

Oberlus wrote: Mon Nov 30, 2020 5:17 pmwithout the unnecessary&annoying strings in the stringtables.
you can just skip them.
but you can use them where you consider adding extra information to the tooltip to be useful
Oberlus wrote: Mon Nov 30, 2020 5:17 pm 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.
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).
Oberlus wrote: Mon Nov 30, 2020 5:17 pm - 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
it was true at the time. i found out how to make those optional later on.
Oberlus wrote: Mon Nov 30, 2020 5:17 pm However I still think it's a pity that no body will implement an easier and faster-to-get solution
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!

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#72 Post by Oberlus »

Ophiuchus wrote: Mon Nov 30, 2020 10:29 pm you can just skip them.
but you can use them where you consider adding extra information to the tooltip to be useful
Really? That's great. I thought I could only skip the ones with empty strings.
Ophiuchus wrote: Mon Nov 30, 2020 10:29 pm I saw your suggestion.
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
Easier for stringtables.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#73 Post by Ophiuchus »

Oberlus wrote: Tue Dec 01, 2020 3:02 pm
Ophiuchus wrote: Mon Nov 30, 2020 10:29 pm I saw your suggestion.
And you also said you didn't have the time to read it.
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!

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#74 Post by Geoff the Medio »

Oberlus wrote: Tue Dec 01, 2020 3:02 pm
Ophiuchus wrote: Mon Nov 30, 2020 10:29 pm you can just skip them.
but you can use them where you consider adding extra information to the tooltip to be useful
Really? That's great. I thought I could only skip the ones with empty strings.
Does that mean that of the strings that currently just contain "per population" can be removed from the stringtables?

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: RFC: A single source for default values (FOCS, python, stringtables, backend)

#75 Post by Oberlus »

Ophiuchus wrote: Tue Dec 01, 2020 4:54 pm I read it and said I don't have the time to follow through/discuss the details
Roger.
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?
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).

Post Reply