help with implementing ARC SYPHONs

Creation, discussion, and balancing of game content such as techs, buildings, ship parts.

Moderators: Oberlus, Committer

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

help with implementing ARC SYPHONs

#1 Post by Ophiuchus »

i did a mostly-working implementation for arc concentration (see forum post) in PR-4951


SR_ARC_SYPHON.focs.txt

ok, i have a timing problem and at the moment i am not sure i can solve it.

what the code does, is; the SR_ARC_SYPHON part does three effects after another
  • for each ship arc disruptor in the fleet add the number of shots to the capacity of a special
  • the capacity gets distributed between all ships with arc syphon parts
  • all disruptors in the fleet get shots set down to zero (if the special capacity is greater zero)
at the moment the shots oscillate from the arc disruptors to the arc syphons and back again, this is working okayishly, but i think it results in some unnecessary micromanagement.

i thought running the effects late, using the current value of the shots ( by using Value(ShipPartMeter SR_ARC_DISRUPTOR SecondaryStat) ) at TARGET_LAST_BEFORE_OVERRIDE_PRIORITY would fix the oscillation, but it does not.

the arc disruptor shots should be set zero every turn, so the initial meter value should always be zero.
i expected the current meter value of the arc disruptors to be "recharged" by TARGET_LAST_BEFORE_OVERRIDE_PRIORITY.

...maybe weapon meters do not recreated each turn?...

...still need to figure out at which priority the meters are set to max meters..

help, review and ideas appreciated
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: help with implementing ARC SYPHONs

#2 Post by Geoff the Medio »

Do you need the special as an intermediate accumulator? Can't you set the desired meter to some big(ger) calculation directly?

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

Re: help with implementing ARC SYPHONs

#3 Post by Ophiuchus »

Geoff the Medio wrote: Wed May 29, 2024 7:57 am Do you need the special as an intermediate accumulator? Can't you set the desired meter to some big(ger) calculation directly?
probably I can get rid of the special in the final version. the extra step is quite helpful for debugging.

but the problem I have is that i get zero values from the Value(ShipPartMeter SR_ARC_DISRUPTOR SecondaryStat) when the intial meter was zero. maybe using MaxSecondaryStat will help?

in order for better debugging/development:
could we maybe add a debug switch to enable SitRepMessage to be executed also when normal effects processing happens and print the message to the log file instead of the sitrep?
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: help with implementing ARC SYPHONs

#4 Post by Geoff the Medio »

Ophiuchus wrote: Wed May 29, 2024 9:09 amcould we maybe add a debug switch to enable SitRepMessage to be executed also when normal effects processing happens and print the message to the log file instead of the sitrep?
What specifically do you mean by "normal effects processing"?

Maybe consider using the NoOp effect? You can put it in a list of effects in an effectsgroup and it should output to the log when it executes.
https://github.com/freeorion/freeorion/ ... s.cpp#L432

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

Re: help with implementing ARC SYPHONs

#5 Post by Ophiuchus »

Geoff the Medio wrote: Wed May 29, 2024 5:59 pm
Ophiuchus wrote: Wed May 29, 2024 9:09 amcould we maybe add a debug switch to enable SitRepMessage to be executed also when normal effects processing happens and print the message to the log file instead of the sitrep?
What specifically do you mean by "normal effects processing"?
I meant what is now ApplyAllEffectsAndUpdateMeters. Once upon a time the sitreps effect were generated in a step following the applying the other effects, so the values in the sitrep and in the actual effect could differ. So this should not be an issue anymore and one can rely on sitreps for debugging purposes (for objects which already existed last turn), can one?

Thanks for the NoOp reminder!


TLDR; i managed to get the implementation right, still confused about some timing and UI stuff
To my original post:
i think it might not possible to do what I imagined.

Resupply happens before movement and sets the paired part meters to the respective max meters. So if I want the arc disruptors to have zero shots in combat, the max meter has to be zero.
I am not sure if clamping happens inbetween or not, but at least after effects processing, the ship part meters are clamped between zero and the max meter.

Also I am not sure what values the UI shows. E.g. for a ship with three disruptors (and revision 41472bcb3; which sets arc disruptor shots to 1 and max shots to zero and takes the current value of shots for setting the special

Code: Select all

before setting stat(s): Arc Disruptor got syphoned on 3 arcs Canis Fleet: Battle Fleet 1939  cur2nd: 0.00 curMax2nd: 3.00  ini2nd: 0.00  iniMax2nd: 0.00
after setting stat(s): Arc Disruptor got syphoned on 3 arcs Canis Fleet: Battle Fleet 1939  cur2nd: 1.00 curMax2nd: 0.00  ini2nd: 0.00  iniMax2nd: 0.00
the ship UI shows 432 damage and 27 destruction, i.e. the normal arc disruptor damage/destruction at three shots.
combat report fits the UI, not the sitrep. do we have another effect application before combat???

also note that applying flanking does not get the shot count of the syphon up in the turn it gets applied.

so i am still a bit unsure/confused. it seems values do not get clamped on setting, so it shooould be possible to use intermediate meters which are higher than the max meter.

aargh... main problem was that priority was too low.... taking the value from the max meter at LATE_AFTER_ALL_TARGET_MAX_METERS_PRIORITY works...

also it is not really clear I should do the draining of arc disruptors without adding better UI support - without effects processing accounting a player might wonder where all the arc disruptor shots went.
UI and AI could better handle arc syphons which do not drain the disruptors. i could make the ship part more expensive (e.g. add the cost of three arc disruptors and have it the damage of three arc disruptors iff there are supporting arc disruptors around - although the weapon gets very heavy (expensive and powerful))
Last edited by Ophiuchus on Wed May 29, 2024 7:39 pm, 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
Geoff the Medio
Programming, Design, Admin
Posts: 13619
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: help with implementing ARC SYPHONs

#6 Post by Geoff the Medio »

Ophiuchus wrote: Wed May 29, 2024 6:45 pmThanks for the NoOp reminder!
Also, if you wrap a ValueRef expression in NoOp(...) it will log the result when it is evaluated.
Ophiuchus wrote: Wed May 29, 2024 6:45 pmOnce upon a time the sitreps effect were generated in a step following the applying the other effects, so the values in the sitrep and in the actual effect could differ. So this should not be an issue anymore (for objects which already existed last turn).
As far as I can tell, currently the only time sitrep effects are run separately from the rest is during universe creation.

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

Re: help with implementing ARC SYPHONs

#7 Post by Ophiuchus »

I am a bit struggling about how to map draining shots from the arc disruptors.

In the current implementation I take the sum of all the arc disruptor shots and split them by the number of arc syphon ships.
So it is unbounded which might be abused (but maybe okay) .

It is easy to add some bounds to the maximum shots distributed to the syphons.
But i don't know how to drain just some shots from some arc disruptors in a fair way.
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: 5841
Joined: Mon Apr 10, 2017 4:25 pm

Re: help with implementing ARC SYPHONs

#8 Post by Oberlus »

Ophiuchus wrote: Sun Jun 02, 2024 9:39 am But i don't know how to drain just some shots from some arc disruptors in a fair way.
Can you use min(available_syphons * max_arc_disruptor_shots_per_syphon, arc_disruptor_shots_in_fleet) to measure how many shots are syphoned?
And max(arc_disruptor_shots_in_flee - available_syphons * max_arc_disruptor_shots_per_syphon, 0) to measure how many arc shots can be shot normally because not syphoned?

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

Re: help with implementing ARC SYPHONs

#9 Post by Ophiuchus »

Oberlus wrote: Sun Jun 02, 2024 1:04 pm
Ophiuchus wrote: Sun Jun 02, 2024 9:39 am But i don't know how to drain just some shots from some arc disruptors in a fair way.
Can you use min(available_syphons * max_arc_disruptor_shots_per_syphon, arc_disruptor_shots_in_fleet) to measure how many shots are syphoned?
And max(arc_disruptor_shots_in_flee - available_syphons * max_arc_disruptor_shots_per_syphon, 0) to measure how many arc shots can be shot normally because not syphoned?
yes, then i have the number of non_syphoned_shots. but then i still need to distribute those to the arc disruptor ships...

then there are ~two issues. one is, that ships might have different number of arc disruptor shots/parts.

the other one is a rounding issue or (a lack of control in FOCS). lets assume each arc disruptor ship has the same number of shots.
then i could do something like setMaxSecondaryStat( round(non_syphoned_shots/arc_disruptor_count) ) to all of the arc disruptor ships. but depending on the actual numbers and rounding there will be quite a mismatch to the exact number of shots. E.g. if there are nine arc disruptors with three shots each. So the arc disruptors should have 15 shots total. In this approach, depending on rounding, the arc disruptors will have each one or two shots. So there will be 9 or 18 arc disruptor shots left (as compared to 15)

maybe there is another way but to setMaxSecondaryStat with the same value to each of those, but currently i dont see it

edit1: something like figuring out statistically the likely necessary number of ships to drain should be possible and then select that number of ships; but ugly and messy; probably we would first need to sort out)

edit2: using a greedy algorithm uglyness would probably also include sorting the ships by the arc disruptor counts and have the same drain effect multiple times or similar.

edit3: could probably also write a new effect. like greedyDistribute totalDistributionValue = non_syphoned_shots sinkCapacity = Target.original_ship_arc_disruptor_shots

edit4: i would rather like to do something less complex
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