Implementing pre-movement effects(?)

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
Ophiuchus
Programmer
Posts: 3548
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Implementing pre-movement effects(?)

#1 Post by Ophiuchus »

in order to react to e.g. fleet stance changes without having the 1 turn delay, I would like to propose adding a round of effects happening before combat (actually before movement). The idea is to get along without the normal effect evaluation in order to remove dependencies and corner cases.

the reason to such a feature is that we often have to build ugly and complicated workarounds to get (close to) intended effects.

I am not sure though what I might miss (especially on effect prediction), so please comment

The design is as follows:
  • add another property to FOCS content (e.g. 'premovementeffects') where you can add EffectGroups
  • those effects are only executed in an additional round of effect application before movement
  • those effects should be based on current stats.
  • those effects should be shown in the current turn (e.g. stealth/damage/fuel meter changes on ships)
  • at the beginning i would add this only to ship hulls (then to ship parts, maybe also to techs?)
  • first content would be a stealth bonus to ships for fleets set to "Passive Hide"
  • restriction: some effects are not possible as premovementeffects and will be ignored - nothing which adds/removes universe objects should be possible precombat for UI reasons and introducing sources/targets of effects
  • restriction: maybe only effects targeting the source should be possible
  • restriction: maybe only valuerefs based on initial values are possible
  • restriction: only effects changing persistent meters (not max/target meters) are possible
  • restriction: no sitrep support
Note i considered and scrapped the idea of precombat effects after movement as the change of location could create serious UI issues. Also the next location is not completely known as it also depends on the blockade of ships other players have agency about.

I expect the following changes to be necessary:
  • invent a term for the point in turn processing when effects are applied (e.g. 'phase')
  • use the last turn end results (meters and target meters) as base for initial values. (this is critical and i am not completely sure if this is possible)
  • add the necessary parser changes
  • add the special effect application before movement and "commit" the result (so the current code sees the changed values as "last turn")
  • add the calls to prediction (?which places?)
  • add some flags to Effects or other facility which phases they might be applied (e.g. DestroyShip etc. only in standard effect application);
  • noop effects and log debug if they are applied on wrong phases (we could also make this a hard error, but i dont think so)
  • make it a runtime error (hard or just logging) when using immediate valuerefs in premovementeffects
  • focs: add the "Passive Hide" stealth stance effect (to all ship hulls)
  • pedia: add the stance effect explanation to the pedia entry for "Passive Hide"
  • AI changes - add support for the new content; have a look if something more generic is possible
followups would be to shift errors and warnings to parsing stage - but probably not with the boost framework, it might be easier with the python parser.

one more doubt I have (and someone needs to check) - as stealth is completely recalculated each turn, the stealth upgrade would be only in combat and else lost.
this would probably mean one has to add the effect also as normal effect - which is a bit ugly for scripters, but not ugly in gameplay.
it might though be that visibility leaks inbetween calculation somewhere.

Note it might make sense to have such movement/combat-only effects.

One change to gameplay is that the other players have less complete information - e.g. with the Passive Hide toggle the enemy could cloak the ships before movement if that bonus increases stealth over detection. Not sure how blockade works currently, but switching focus might help slipping through.

I guess we could script around that - e.g. prevent combat stealth bonus when being detected.

If we keep the real premovementeffects results on the server only, that would actually be a great use case for stealthed detection which is currently impossible to solve.
In that case the information that you are detected by an unseen enemy is only shown if combat occurs. And we might even be able to restrict that to the cases where you are actually hit (and put that as special in the combat log "Unexpected hit on <ship> - contrary to our intelligence it seems the enemy is able to detect the stealthed vessel")

edit: collecting datapoints in the forum
Last edited by Ophiuchus on Fri Jun 21, 2024 8:23 am, edited 1 time 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: 5883
Joined: Mon Apr 10, 2017 4:25 pm

Re: Implementing pre-movement effects(?)

#2 Post by Oberlus »

I think it would be better to split backend process instead of FOCS, for simplicity in understanding or implementing scripting.

Consider first the simplest case:

* Press turn -> FOCS effects -> backend processes (movement, combat, etc. in current order).

And if this one brings in new problems, consider this:

* Press turn -> some backend processes -> FOCS effects -> rest of backend processes


If the not so simple way is the way to go, maybe this:

* Press turn -> techs researched + policies adopted + fleet toggles -> FOCS effects -> fleet movement + combat + invasion + colonization

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

Re: Implementing pre-movement effects(?)

#3 Post by Geoff the Medio »

I'm rather skeptical about doing this, as I think it will lead to a bunch of glitches and unexpected problems. Also, I think it's not being adequate considered that if one player's actions can lead to changes in things like stealth or damage before the next turn resolves, than so can other players' or neutral object effects, which will make predicting the situation that will apply for battles or resource output on the next turn much more unreliable.

But if it were done, I'd probably implement it with a special-purpose condition like BeforeMovement that is scripted into the activation for an effectsgroup, like any other condition, but which matches (all) objects if the current turn phase is before movement. An AfterMovement tag could work similarly.

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

Re: Implementing pre-movement effects(?)

#4 Post by Oberlus »

What if all scripting effects are AfterMovement and BeforeCombat ?
  1. Backend batch pre-scripting:
    • Invest RP/PP/IP
    • Get completed techs
    • Create completed ships and buildings
    • Adopt/deadopt policies
    • Fleet movement
  2. Scripting effects
    • Backend batch post-scripting:
      • Combat
      • Invasion
      • Colonization
    Not sure about order within backend batches. I guess whatever it is now is the right one.

    With this, the one-turn-lag only affects speed/fuel effects from techs/policies/buildings completed this same turn. But having the scripting effects between movement and combat removes the one-turn-lag for effects that depend on position, like stars and fields (e.g. the turn you arrive you get the stealth bonus, the turn you depart you lose it), and for combat effects that depend on policies, buildings or techs adopted/completed/researched this turn.

    I'm for sure missing the complications of this.

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

    Re: Implementing pre-movement effects(?)

    #5 Post by Geoff the Medio »

    Effects are not run just once per turn, but rather are re-run several times for meter updates during the turn processing to allow things like combat results to be reflected in the results sent back to players, and possibly for newly colonized planets to not starve due to having out of sync initial and target/max and current meters, and for newly-produced ships and buildings to have an immediate impact.

    But the main updates are indeed post-combat. If instead doing a general effects update after movement and before combat, that would mean that the values reported in the client won't be accurate for combats between turns. What you're calling a one turn delay is largely intended so that the situation between turns is more or less accurately described by what the client can tell players, rather than difficult-to-predict other values that depend on how things change between what the player sees while playing a turn and what the situation is by the time combat happens.

    Also, you're proposing a substantial reorder of the turn cycle regardless of the placement of effects. In particular, movement and combat happen before research and production.

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

    Re: Implementing pre-movement effects(?)

    #6 Post by Ophiuchus »

    Oberlus wrote: Sun Mar 13, 2022 5:20 pm What if all scripting effects are AfterMovement and BeforeCombat ?
    ...
    I'm for sure missing the complications of this.
    yes. this is quite a big topic with tons of issues.

    for revamping the order like you suggest we would probably need a thorough list of all kinds of things which happen and their dependencies, if we dont do that first we will most probably end up in a worse place than where we are now.

    every effect which is not player-determined will be a source of wrong predictions. also if we get rid of all +1 we would need a cascade of effect applications (e.g. the ancient ruins give you a technology, that technology has an effect, so you need to restart effect evaluation including the technology; or you build a ship, if you have an effect which is based on the number of ships in the system should this ship be included or not).
    this would also introduce possibilities of unstable effects results or other kinds of endless loops.

    i am looking for useful input here for applying effects premovement without revamping the whole system.
    if you want to discuss getting rid of the +1 in general please open another topic.
    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: 5883
    Joined: Mon Apr 10, 2017 4:25 pm

    Re: Implementing pre-movement effects(?)

    #7 Post by Oberlus »

    Ophiuchus wrote: Sun Mar 13, 2022 7:59 pm for revamping the order like you suggest we would probably need a thorough list of all kinds of things which happen and their dependencies, if we dont do that first we will most probably end up in a worse place than where we are now.
    Since I am interested on this, I'll do it.

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

    Re: Implementing pre-movement effects(?)

    #8 Post by Ophiuchus »

    Geoff the Medio wrote: Sun Mar 13, 2022 1:00 pm But if it were done, I'd probably implement it with a special-purpose condition like BeforeMovement that is scripted into the activation for an effectsgroup, like any other condition, but which matches (all) objects if the current turn phase is before movement. An AfterMovement tag could work similarly.
    I think that would make things more confusing for players and also for the compiler.

    If it is a typical condition, you probably expect that you can use it somewhere nested. But what would it mean in an Or condition?
    e.g.

    activation = Or [ And [ BeforeMovement Ship ] And [ Aftermovement Ship ] ]

    would this mean the effect gets applied twice?

    For parsers; if for a certain phase only a subset of conditions and actions are allowed, you can already check that when parsing the FOCS code.
    if that is put in a condition, it might get hard to figure out what is allowed and what is not. if it is in its own specification, it is completely clear.

    is there a reason you prefer the condition?
    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!

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

    Re: Implementing pre-movement effects(?)

    #9 Post by Ophiuchus »

    Oberlus wrote: Sun Mar 13, 2022 8:11 pm
    Ophiuchus wrote: Sun Mar 13, 2022 7:59 pm for revamping the order like you suggest we would probably need a thorough list of all kinds of things which happen and their dependencies, if we dont do that first we will most probably end up in a worse place than where we are now.
    Since I am interested on this, I'll do it.
    perfect; i hope you can slice the gordian knot there :mrgreen:
    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: 13619
    Joined: Wed Oct 08, 2003 1:33 am
    Location: Munich

    Re: Implementing pre-movement effects(?)

    #10 Post by Geoff the Medio »

    Ophiuchus wrote: Sun Mar 13, 2022 8:14 pmIf it is a typical condition, you probably expect that you can use it somewhere nested. But what would it mean in an Or condition?
    Same as All or None depending what phase of the turn it was.
    activation = Or [ And [ BeforeMovement Ship ] And [ Aftermovement Ship ] ]

    would this mean the effect gets applied twice?
    Probably more than twice, since multiple effect evaluations already get done. But what that means might not be what you assume, as meter backpropagation occurs at specific times, and that's what makes the result of an effect be "permanent", more or less.

    I'm not really concerned about whether this sort of condition will make obvious sense when nested strangely within And/Or or some other subcondition. The intended and sensible use would be something like activation = And [ BeforeMovement Ship ], not in an Or condition.
    is there a reason you prefer the condition?
    Adding a condition that implements turn phase checks would be relatively simple and should work with all the existing mechanisms for effectsgroups evaluation, and would be relatively easy to modify and extend to different split points or multiple split points. Adding a separate list is much less flexible or extensible, and seems like more work to set up than adding a fairly simple condition parser and class definition.

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

    Re: Implementing pre-movement effects(?)

    #11 Post by Ophiuchus »

    probably we should start by a watered down UI design principle;
    • (usually and in most cases) UI shows the correct numbers which will be used in turn processing (e.g. movement, blockade, combat, effect processing...)
    • for specific cases, expected values are shown and care should be taken to emphasize that the used values might be different depending on unknowns; currently this is mostly happening to movement orders, because blockade depends on enemy orders (e.g. enemy sends blockaders home) and also hidden information (e.g. an fleet blockades a out-of-detection planet)
    • it is ok if unknowns like enemy orders (or hidden enemy ships) make those values deviate from those used
    • this is considered a "low-level feature" and the burden is on the effect implementer to get this right (and we should document this caveat implementor). One should always figure out how to communicate the effect to the players.
    and using that we could figure out which effects should be shown (or in which way) - this should lead to valid tests for which implementations could make sense.

    i have two main designs: a) temporary changes; or b) normal/stacking changes

    in general this is only about meter changes currently (i think)

    a)

    with temporary changes the phase effect application would only happen in that phase. and outside of the phase that change would not exist, so the current effect application would be basically unchanged, resetting meter values after a phase to the initial meter (or simply not backpropagating the changes).

    The UI should probably indicate if there are temporary effects applied or not (and if possible also have a mouseover with effects accounting). E.g. by using a different color (not sure about accessibility).

    The values presented for weapons would be the current values with the temporary before-combat effects applied.
    So if one did not have any, the damage/shots... are shown in white; as soon as flanking kicks in, the value shown would be with the flanking bonus and e.g. in green color.
    (This works well if there are not many sources of temporary effects).

    About in-flight effects; this is obviously harder/impossible for the UI. E.g. when passing two systems in one jump; one could have a certain stealth on the first lane, a certain stealth in the first system (e.g. there is a scanning facility) which is relevant for blockade, another stealth on the next lane, another stealth on the second system, another stealth on the last starlane.
    This would mean reevaluation of those in-flight effects every time a starlane is entered or a system is entered. We could of course also dumb down movement by dissallowing any passage - but i doubt anyone wants that.


    b) normal/stacking effects

    this has the advantage that a simple UI flow is backed by a similar process in the backend. E.g. if stealth changes in pre-movement phase because of fleet stance, it would the true value for movement/blockade/combat and won't be necessary to change.

    with the temporary effects one would have to make sure to apply the effect on all those phases again. e.g. the fleet stance effect would be necessary to apply e.g. before-movement, before-combat...

    the problem with such is when the effect should be temporary - one has to undo it; and sometimes it might be hard by how much .
    With the extreme example of in-flight effects one in order to undo previous effect, one would have to figure out the bonus which was provided by the last flight segment and substract it


    so i would rather go for temporary effects, because undoing effects is a lot more messy than reapplying. and if I consider phases a low-level feature, it is ok that it is ugly having to list multiple activation conditions.
    Last edited by Ophiuchus on Fri Jun 21, 2024 9:26 am, edited 1 time 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: 5883
    Joined: Mon Apr 10, 2017 4:25 pm

    Re: Implementing pre-movement effects(?)

    #12 Post by Oberlus »

    Ophiuchus wrote: Fri Jun 21, 2024 8:16 am i think you had opened a thread/started work? could you link please?
    Oh, nopes, I never got to it.
    The closes I have is from two years before that: https://www.freeorion.org/forum/viewtopic.php?t=11803

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

    Re: Implementing pre-movement effects(?)

    #13 Post by Ophiuchus »

    Oberlus wrote: Fri Jun 21, 2024 8:42 am
    Ophiuchus wrote: Fri Jun 21, 2024 8:16 am i think you had opened a thread/started work? could you link please?
    Oh, nopes, I never got to it.
    The closes I have is from two years before that: https://www.freeorion.org/forum/viewtopic.php?t=11803
    I meant a we need a collection of actual game content which are candidates for earlier effects and how those should be presented.
    i opened up a thread early turn effect application candidates (e.g. pre-movement)
    feel free to take over and edit that post (if you can do that as moderator).
    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!

    Post Reply