[request] Scripting constants for AI

[Dilvish]

Am I missing something?

Yeah, user strings are a translation tool and not a data storage.

Well then we could redesignate them from "user strings" to "scripting_and_ui_strings_and_data" -- voilà! Problem solved!

Of course, I'm really thinking more of a virtual redesignation rather than going through and changing all the code references. Updating some code comments would probably be good. Right now we have a ton of information that has to be duplicated between FOCS scripting and corresponding Pedia user string entries, which could be automatically synchronized in this fashion. Case in point -- it looks to me like the BAD_STEALTH description is stale in a number of stringtables. The FOCS script in scripting/species/common/stealth.macros itself already uses a macro for the value:

Code: Select all

BAD_STEALTH
'''EffectsGroup
            description = "BAD_STEALTH"
            scope = Or [
                Source
                And [
                    ContainedBy Source
                    Not HasTag name = "ORBITAL"
                ]
            ]
            activation = Planet
            stackinggroup = "SPECIES_STEALTH_STACK"
            effects = SetStealth value = Value - [[LOW_STEALTH]]
'''

and that LOW_STEALTH value is currently specified in a different FOCS file scripting/common/stealth.macros:

Code: Select all

LOW_STEALTH
'''20'''

The BAD_STEALTH stringtable entry is in sync for en.txt and fr.txt:

Code: Select all

BAD_STEALTH
−	Bad Planetary [[encyclopedia STEALTH_TITLE]]: −20 malus

but out of date for de.txt (last updated a few months ago)

Code: Select all

BAD_STEALTH
−	Schlechte [[encyclopedia STEALTH_TITLE]]: −15 Malus.

and for ru.txt (last updated a few days ago)

Code: Select all

BAD_STEALTH
-	Плохая [[encyclopedia STEALTH_TITLE]]: -15 малус.

If that LOW_STEALTH macro definition were instead moved to a common location as I propose, then the stringtable entries could also refer to it and we would drastically reduce this kind of desync problem. (At the very least we could do that within the stringtables, so that the value would only be specified once for all the stringtables and once for all the FOCS scripts, but why define it in two locations when you can define it in just one? I don't think you'd stand for multiple redundant / potentially_conflicting definitions in C++ code.)

On a related note, to go along with this it would be nice to add some formatting directives (akin to the encyclopedia directive or whatnot) so that, for example, instead of the stringtable entry

Code: Select all

ULTIMATE_OFFENSE_TROOPS
+++	Ultimate Offensive Ground [[encyclopedia TROOP_TITLE]]: 300%

we could have

Code: Select all

ULTIMATE_OFFENSE_TROOPS
+++	Ultimate Offensive Ground [[encyclopedia TROOP_TITLE]]: [[percentage ULTIMATE_OFFENSE_TROOP_MULTIPLIER]]

[Vezzra]

Am I missing something?

Yeah, user strings are a translation tool and not a data storage.

Well then we could redesignate them from "user strings" to "scripting_and_ui_strings_and_data" -- voilà! Problem solved!

Of course, I'm really thinking more of a virtual redesignation rather than going through and changing all the code references.

I think Marcel is less concerned about the name of the function in the backend code that is used for the purpose of retrieving those values, but the fact that we currently (ab)use the stringtables to store content definitions and configuration parameters (all those FUNCITONAL_* entries) within them (I know, we do that by using #includes, but still). Which has been a quick-and-dirty solution to be able to use the user_string function to retrieve these values and also be able to refer to them in the stringtables. But at some point quick-and-dirty solutions should get replaced by clean ones, instead of continually expanding them.

Stringtables have one and only one purpose: to provide a simple "database" where all the in-game texts are stored that need to be translateable, nothing else. All those FUNCTIONAL_* entries, as well as these FOCS constants that should get accessible by Python should get their own, dedicated configuration/content files and their own set of accessor functions in the backend code. So that would be a bit more than just a virtual redesignation, it's a hardcoded seperation in the backend code.

Of course, to fulfill the purpose of being accessible from content scripts, Python and the stringtable texts we need to implement all required interfaces. More complicated than just go with the current (ab)use of user_string and the stringtables, but clean.

[Dilvish]

So, it sounds like there are two objections -- one is the utilization of the UserString() function to retrieve functional non-user-string information, and the other is that some of those functional non-user-string entries have been placed within the main stringtables. I think that a fairly modest bit of code generalization, followed by an even more modest bit of branching and specialization, plus some file reorganization, would solve those problems.

The current parser/lookup code that lies behind UserString() and UserStringList() would get a new branch which would instead provide ContentString() and ContentStringList() retrieval functions, being essentially the same thing but having a different function name and being instanced not from the user stringtables and instead simply be instanced from default/content_specific_parameters.txt or something that includes that and similar content files. We could have a single file called something like "FOCS_value_lookups.txt" which could be #included into the stringtables, into content_specific_parameters.txt, and into the FOCS scripts. (I haven't reviewed them all just now, but from my recollection all the functional stringtable entries could be moved out of the stringtables in this fashion.)

I think that the code replication involved would be fairly minimal, and at least then you'd wind up with happily pure stringtables, yes?

[Vezzra]

That sounds like a reasonable solution, I already had something similar in mind (I actually envisioned something where e.g. stringtables would reference those "content strings" via a backend code interface, but your include idea is far simpler and should work just fine). Marcel?

[dbenage-cx]

Quick suggestion: keep these new macros/constants in a file near their definition (.fos.txt) file.

So in the same directory, you would have:
* FN.focs.txt (main definition)
* FN.macros (macros that may be used in other files)
* FN.egvalues (cross-referenced constant only values)
* potentially a language/stringtable file as well (or multiple files)

[Vezzra]

* potentially a language/stringtable file as well (or multiple files)

Why move stringtable files into the content script folders? They have their own dedicated directory, so you have all the language specific stuff in one place. Keeping them separate this way is a sound concept IMO.

[dbenage-cx]

Looking over the FUNCTIONAL entries, most could move to to a new config file within user_config/default/ (when mod specific) or to the current config.xml (for global).
FUNCTIONAL_SITREP_PRIORITY_ORDER is probably the biggest hurdle here.

Instead of separate definitions, existing macros could be stored for later reuse (example branch) Initially started in the middle of this thread, but was waiting to see what outcomes came (and further stalled for release). Changes such as renaming to ContentString() would be pending if the branch fits into the design (I have still to find a way to manually add to XCode project files, if that is possible).
I was toying with this to allow <<Ref MACRO_KEY>> within stringtables recently, though that could be a separate branch.

Why move stringtable files into the content script folders? ...

Aside from keeping a single file in some kind of order, my mind was on future work for allowing moddable content.
Still had to find the motivation to work out some kind of proposal for a vfs, so I did not mean to let the question hang. I took it more as a definitive statement and a suggestion to find another approach.