[request] Scripting constants for AI

[Cjkjvfnby]

AI need to access to scripting data.

AI used hardcoded values:

Code: Select all

TECH_EFFECTS = {
    # "TECHNAME": { Token1: Value1, Token2: Value2, ...}
    "SHP_REINFORCED_HULL": {STRUCTURE: 5},
    "SHP_BASIC_DAM_CONT": {REPAIR_PER_TURN: 1},

One of way to fix it is to use constant in scripts:

Code: Select all

 EffectsGroup
            scope = And [
                Ship
                OwnedBy empire = Source.Owner
            ]
            effects = SetMaxStructure value = Value + <<SHP_REINFORCED_HULL_STRUCTURE_BONUS>>

In that case python call can be changed to:

Code: Select all

TECH_EFFECTS = {
    # "TECHNAME": { Token1: Value1, Token2: Value2, ...}
    "SHP_REINFORCED_HULL": {STRUCTURE: fo.resolve_value('SHP_REINFORCED_HULL_STRUCTURE_BONUS')},
    "SHP_BASIC_DAM_CONT": {REPAIR_PER_TURN: fo.resolve_value('SHP_BASIC_DAM_CONT_BONUS')},

I need help with support in C++, and can do all AI changes myself

[Cpeosphoros]

I'm not a FO programming type, but I think you'd get better results for this opening a github issue.

[MatGB]

I'm not a FO programming type, but I think you'd get better results for this opening a github issue.

Actually this is a "how should the project proceed" thing that covers a huge pile of ground and would, for example, affect the work I do all over the place (probably by making it easier, actually), it's not an issue, it's an approach.

As for the substance, I have no opinion, I don't think I could put any time to helping the conversion at the moment, my FO time is taken up reviewing scripts and PR and testing stuff for balance. However, if I'm reading it right the way we currently use macros to define some things for easy amendment (eg the currently open Drydock PR) is close to what you're wanting, and I'm very keen on seeing more of that sort of thing as it makes tweaking and balancing things far easier, plus if the AI is taking the stats directly from the thing I'm changing I don't need to worry about weakening/breaking the AI when I, for example, go in and tweak the costs or other stats of a ship hull.

So, cautiously in favour, won't have time to help much, happy to test if it's done.

[dbenage-cx]

Instead of re parsing the same data files, wouldn't it be more consistent to query the client/server?
If there is a stat not currently available, maybe it needs to be exposed.

I'm not speaking strictly against the idea, maybe there is some efficiency I'm missing.
From some of the comments in the python code I was under the impression that any parsing there was temporary.

[Cpeosphoros]

I'm not a FO programming type, but I think you'd get better results for this opening a github issue.

Actually this is a "how should the project proceed" thing that covers a huge pile of ground and would, for example, affect the work I do all over the place (probably by making it easier, actually), it's not an issue, it's an approach.

Sorry, as I said, I'm not on the programming team. I'm still getting around on what goes where.

Also, as for the content, I'm all for things getting centralized where everybody, human and AI clients, easily get the same values.

[Cjkjvfnby]

Instead of re parsing the same data files, wouldn't it be more consistent to query the client/server?
If there is a stat not currently available, maybe it needs to be exposed.

This example is inside EffectsGroup, in other word it is local variable of script function.

[Geoff the Medio]

This could be implemented by exposing all the Effect and Condition and ValueRef classes to Python, as well as the getters for a building type or part type or tech or similar's effectsgroups, which could then be examined to extract such parameters.

Probably it would be more useful to have a set of name-keyed numbers that are used in macros in the manner of the example, though. Probably it would need to be a distinct way to script a "queryable variable" or somesuch, rather than defining a normal macro... However, since macro keys can have arbitrary names and reappear in different places with different values, doing this consistently might be problematic.

[Cjkjvfnby]

This could be implemented by exposing all the Effect and Condition and ValueRef classes to Python, as well as the getters for a building type or part type or tech or similar's effectsgroups, which could then be examined to extract such parameters.

I think it will be quite complex to extract value from that data, and AI code will not be resistant to script changes.

Probably it would be more useful to have a set of name-keyed numbers that are used in macros in the manner of the example, though. Probably it would need to be a distinct way to script a "queryable variable" or somesuch, rather than defining a normal macro... However, since macro keys can have arbitrary names and reappear in different places with different values, doing this consistently might be problematic.

May be replace values in text before script parsing? How stringtables entries work, before parsing or inside parsing?

[Geoff the Medio]

May be replace values in text before script parsing?

I don't think it's possible to modify the Python code before it's parsed by Python itself... that's all done automatically from within Python.

How stringtables entries work, before parsing or inside parsing?

There's not really much "parsing" for stringtables... just identification of all the key-value pairs. But stringtable macro substitutions use stringtable key lookups to resolve, so I'd say the substitutions are done after the first pass identification of what keys and values there are. But that's somewhat irrelevant here, as you care more about how FOCS scripts handle macros, which is done before the main parsing step.

[Vezzra]

AI need to access to scripting data... I need help with support in C++, and can do all AI changes myself

The request is certainly reasonable, and IIRC we already had discussions in the past on the topic of how to give Python scripts access to stats/data defined in the content scripts.

Alas, I currently I have already much more on my plate than I can handle, I simply can't add even more, so I can't offer much help here, at least for the time being. But we definitely need to keep this in mind. Which reminds me (again) that we need a place where we can collect/manage these kind of suggestions/ideas. Of course we can add yet another tag ("suggestion" or "idea") for that purpose to our github tracker, and put them there, but I wonder if we will "overload" the tracker long-term, if we stuff everything we want to keep track of there...

[adrian_broher]

Of course we can add yet another tag ("suggestion" or "idea") for that purpose to our github tracker, and put them there, but I wonder if we will "overload" the tracker long-term, if we stuff everything we want to keep track of there...

Nonsense. That's what is the purpose of tags after all. If the bug/issue/idea isn't worked on / rejected for $reason the issue is open. If is implemented/fixed/rejected it's closed. The tags identify the domain what domain the issue is touching (idea/bug/feature/server/client/opengl/focs) the assignee identifies who is in charge of handling this issue. You can assign milestones to determine when a feature should be implemented at last. If you want to know something (like open unassigned bugs for the next release) your can write a search query. This is by miles better than anything a bulletin board can provide given that the users show some discipline. In fact some boards should be dropped with no replacement (compile issues, support) in favour of issues, because a BB just don't cut it.

[Vezzra]

Well, personally that's what I'd prefer too, because looking at our past experiences with trying to use dedicated special threads as todo lists/means to keep track of certain things weren't particularly successful. As you said, a forum isn't really cut out for that kind of task. So I want to second the suggestion to move all things that require keeping-track-of to the github tracker.

(I've added some more tags: "idea" and "request".)

However, I wouldn't completely discard all those subforums - often enough they are used to just ask for help, and not everything posted there is an issue that needs to be addressed in terms of fixing and kept track of, but only some answers/instructions/clarifications/explanations, and maybe some discussion. If something turns out to be an issue that actually needs more than that, we can always ask the poster to open a github issue. Things that can be solved by explanations and discussions are better kept on the forum, because there it has a far better chance to be found again later by someone googling a certain issue. At least, that's my experience - when I go to the search engines, I usually get tons of hits with forum posts, but github tracker issues rarely turn up.

In our case here, @Cj, can you open a github issue with your request? I think proper tag for this would be "feature".

[adrian_broher]

However, I wouldn't completely discard all those subforums - often enough they are used to just ask for help, and not everything posted there is an issue that needs to be addressed in terms of fixing and kept track of, but only some answers/instructions/clarifications/explanations, and maybe some discussion.

If that is the case the documentation is insufficient, which in turn is a bug. Or the user didn't RTFM (read the fine manual), which is maybe a bug (depending on how the manual is understandable).

[/quote]If something turns out to be an issue that actually needs more than that, we can always ask the poster to open a github issue. Things that can be solved by explanations and discussions are better kept on the forum, because there it has a far better chance to be found again later by someone googling a certain issue. At least, that's my experience - when I go to the search engines, I usually get tons of hits with forum posts, but github tracker issues rarely turn up.[/quote]

That's probably because people posting threads and not creating issues in combination with the search engine crawler crawls the most recent stuff.

[Dilvish]

CJ's suggestion seems like a fine idea to me. I've previously considered exposing the underlying EffectsGroups, Effects, Conditions and ValueRefs from FO as Geoff suggests-- it would have the benefit of potentially allowing the AI to really be automatically (at least nearly) totally adaptable to FOCS script changes, but I think that even relatively simple value checks would still be exceedingly messy for the AI to deal with in that fashion, let alone actually trying to be adaptable to the entire structure of a given Effect.

So, for SJ's suggestion, perhaps the parser has changed while I've been away (or my memory is simply a bit foggy), but it's seeming to me that this should be a simple scripting matter to implement, no C++ coding necessary. We could generalize the use of default/content_specific_parameters.txt (which already gets included into the stringtable for similar lookups for the UI) to be not just for customizing the UI, but also for these kinds of parameters (or else just make a new file for these kinds of parameters). At the end of default/scripting/common/misc.macros we would add the line

Code: Select all

#include ../../content_specific_parameters.txt

Within the FOCS scripts, the numeric constants would just be replaced with macro lookups, like is already done for things like MIN_RECOLONIZING_SIZE, so Cj's example FOCS script would instead look like

Code: Select all

 EffectsGroup
            scope = And [
                Ship
                OwnedBy empire = Source.Owner
            ]
            effects = SetMaxStructure value = Value + [[SHP_REINFORCED_HULL_STRUCTURE_BONUS]]

and the corresponding AI python script would be something like

Code: Select all

# probably put this function in freeorion_tools.py
def numeric_FOCS_value(key):
    lookup = fo.userString(key)
    try:
        return float(lookup)
    except ValueError:
        print_error("Error looking-up numeric scripting value for script key '%s', got '%s'" % (key, lookup))
        return get_default_value(key)  # from looking up in an AI table, or else some fixed value.

TECH_EFFECTS = {
    # "TECHNAME": { Token1: Value1, Token2: Value2, ...}
    "SHP_REINFORCED_HULL": {STRUCTURE: numeric_FOCS_value('SHP_REINFORCED_HULL_STRUCTURE_BONUS')},
    "SHP_BASIC_DAM_CONT": {REPAIR_PER_TURN: numeric_FOCS_value('SHP_BASIC_DAM_CONT_BONUS')},

Am I missing something?

[adrian_broher]

Am I missing something?

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