Scripting

[Benji]

Hi everybody,

Where can I find a good explanation of how 'effectsgroup' works?

Also, looking through some of the files, there must be a way to write things more concise. More 'code-like' maybe. I'll give an example below.

And some files would probably be better of in XML format. For instance, the techs.txt file would be much more readable and editable if it was a nicely structed XML file you could edit in exel (or related software).

I'm obviously very new to this forum, so I don't know. How open is this kind of stuff for debate?


Currently the species.txt folder reads

Code: Select all

    effectsgroups = [
        EffectsGroup
            scope = Source
            activation = And [
                Planet environment = Good
                Planet size = Huge
            ]
            effects = [
                SetTargetPopulation Value + 18
                SetTargetHealth Value + 25
            ]

        EffectsGroup
            scope = Source
            activation = And [
                Planet environment = Good
                Planet size = Large
            ]
            effects = [
                SetTargetPopulation Value + 12
                SetTargetHealth Value + 25
            ]

        EffectsGroup
            scope = Source
            activation = And [
                Planet environment = Good
                Planet size = Medium
            ]
            effects = [
                SetTargetPopulation Value + 8
                SetTargetHealth Value + 25
            ]

        EffectsGroup
            scope = Source
            activation = And [
                Planet environment = Good
                Planet size = Small
            ]
            effects = [
                SetTargetPopulation Value + 5
                SetTargetHealth Value + 25
            ]

        EffectsGroup
            scope = Source
            activation = And [
                Planet environment = Good
                Planet size = Tiny
            ]
            effects = [
                SetTargetPopulation Value + 3
                SetTargetHealth Value + 25
            ]

It would be much easier if this could be condensed to something like (pseudo code):

Code: Select all

    

effectsgroups = [
        EffectsGroup
            scope = Source
            activation = For All Planet environment = Good
[
Planet size = Huge
effects = [ SetTargetPopulation Value + 18
                SetTargetHealth Value + 25 ]

Planet size = Large
effects = [ SetTargetPopulation Value + 12
                SetTargetHealth Value + 25 ]

Planet size = Medium
effects = [ SetTargetPopulation Value + 8
                SetTargetHealth Value + 25 ]

Planet size = Small
effects = [ SetTargetPopulation Value + 5
                SetTargetHealth Value + 25 ]

Planet size = Tiny
effects = [ SetTargetPopulation Value + 3
                SetTargetHealth Value + 25 ]
]

[Geoff the Medio]

Where can I find a good explanation of how 'effectsgroup' works?

There's a format description here: http://freeorion.org/index.php/Effects#EffectsGroup

If that's not clear, ask again, hopefully with a more specific question.

Also, looking through some of the files, there must be a way to write things more concise. More 'code-like' maybe. I'll give an example below.

The scripting format could be made a lot more complicated and flexible, to allow nesting of conditions and other parts of EffectsGroup definitions, but this would be a very big and complicated undertaking.

There was some discussion between me and tzlaine about making "named conditions" that one could define early in a file, and then use by name later whenever a condition parameter is required, rather than redefining the full condition each time.

I don't see your example as being that much easier to work with, though. To save the "cost" of "Planet environment = Good" in each effectsgroup, you've introduced a new structure that is, upon inspect, not very clear about what it can or can't do, and which mean each actual effect definition doesn't locally contain the relevant info about what its activation condition is, but instead requires scrolling back up to find the enclosing condition / partial effectsgroup definition.

The particular case of species getting one of many different possible bonuses depending on environment and planet size is really the worst case for the current effects system. That use is a new addition with the species system, and wasn't the original model for the effects system. Previously the planet environment and size bonuses were looked up in a data table outside the effects system, and I just ported over similar numbers when implementing Species definitions.

It's possible that the many different effectsgroups could be replaced with fewer effectsgroups using some object parameters to modify the meter modifications they produce, but doing this for dependent environment quality and planet size, would require interpreting those enums as integers, which is it awkward and probably hard to understand as well.

Other than species, there aren't many cases where a long list of effectsgroups like appears for species is actually necessary, though...

And some files would probably be better of in XML format. For instance, the techs.txt file would be much more readable and editable if it was a nicely structed XML file you could edit in exel (or related software).

The content files were originally written in XML format, but we changed to the current system for several reasons. In part, the current system is a lot more readable and much less verbose than the XML was (despite what initial impressions of the current files might lead one to believe), particularly for non-programmers for whom the extra formatting filler of XML can be intimidating. At least in the simple case, the current format is easier to understand and read.

I'm obviously very new to this forum, so I don't know. How open is this kind of stuff for debate?

You can debate about it all you want... There's rarely any need to shut down discussion or debate outside of a specific on-topic official design thread, which this is not.

Edit: That all said, if there is a recurring need for a big list of effectsgroups to implement what is essentially a 2-parameter lookup table (if size = X and environment = Y: use bonus Z) then we could add a special scripting format rule for effectsgroups to deal with that, without needing to explicitly script out all of them. This would be similar to how parts or hulls currently have various stats (stealth, structure, capacity, etc...) which don't require writing an effectsgroup, but which are actually internally stored and implemented as an effectsgroup. I probably won't want to write such a parser for just the Species population and health bonus dependence on planet environment and size, though... /Edit

That said, anything mechanics or scripting format-related that you propose won't necessarily get implemented unless you can convince someone to modify the parser accordingly...

[Benji]

The general format of effectsgroup is quite clear. My question is: what can I actually do with it. For instance, looking at other buildings there are things like maxfarming +2, etc. Is there a description of all the conditions and effects that are available?

And what is a stacking group?

As to your other comments: fair enough! You're right that it's mostly relevant for planets. But having two dimensions (size/quality) seems like such a perfect use for two-dimensional tables (<= tables? well, i'm sure you know what I mean).

[Geoff the Medio]

The general format of effectsgroup is quite clear. My question is: what can I actually do with it. For instance, looking at other buildings there are things like maxfarming +2, etc. Is there a description of all the conditions and effects that are available?

See the entirety of that page: http://freeorion.org/index.php/Effects

There is an list of conditions and effects.

The main purpose of the effects system is all the bonuses and penalties to planets' meters, so there are a lot of planet meter-altering effects listed, but you can also do things like changing planet size and types, setting various non-planet meters, destroying objects, adding or removing specials, creating planets or buildings, setting empire capitols...

And what is a stacking group?

The linked page discusses it:

An EffectsGroup's stacking group determines when it should affect a specific target; if that target has already been affected by another EffectsGroup with the same stacking group, all EffectsGroups after the first have no effect on the target that turn. For instance, if an EffectsGroup is in a stacking group "WONDER_FARM_BONUS", and executes on a target object, no other EffectsGroup in the "WONDER_FARM_BONUS" stacking group will affect it on that turn.

As to your other comments: fair enough! You're right that it's mostly relevant for planets. But having two dimensions (size/quality) seems like such a perfect use for two-dimensional tables (<= tables? well, i'm sure you know what I mean).

Right; the problem was that the previous tables system worked outside the effects system, so all the effect value tracking didn't work the same way. Also, there was no way for Species to have different sets of bonuses from eachother. The current Species format lets that happen. There could be a table syntax added for these bonuses to Species, though... if it's worth the effect of writing the parsing for it just to clean up the Species definitions.

[Bigjoe5]

I'd just like to add that as a non-programmer, I'm very comfortable with the current format of the text files.

[Benji]

See the entirety of that page: http://freeorion.org/index.php/Effects

Eh... yeah. I actualy looked at that. Must be a complete brainfreeze from my part. Sorry!

There could be a table syntax added for these bonuses to Species, though... if it's worth the effect of writing the parsing for it just to clean up the Species definitions.

Naaah, you're right. Not worth your effort. Only really important in the species.txt file, and how often do we need to mod that?

Like BigJoe5 said, in general the scripting format seems very powerful. Maybe it's just that it's a tad overwhelming when you look at it the first time.