I meant that when focus switching, there is a penalty to the output of all of industry, reserach, and influence, unless one of those is the new focus. So if dithering between industry and research, there will also be a cost to influence, which I don't think was considered in the examples above.Oberlus wrote: ↑Tue Feb 15, 2022 4:21 pmI'm not sure what you mean.Geoff the Medio wrote: ↑Tue Feb 15, 2022 3:45 pm Is this analysis considering any other meters, such as influence output, being affected by frequent focus switching?
Extra voice meeting on Monday 14.02.?
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Extra voice meeting on Monday 14.02.?
Re: Extra voice meeting on Monday 14.02.?
If you mean the FOCUS_CHANGE_PENALTY macro, it is considered.Geoff the Medio wrote: ↑Tue Feb 15, 2022 9:33 pm I meant that when focus switching, there is a penalty to the output of all of industry, reserach, and influence, unless one of those is the new focus. So if dithering between industry and research, there will also be a cost to influence, which I don't think was considered in the examples above.
If one is dithering between research and industry, I guess influence meter will be all the time at the minimum (with unfocused bonus and nothing else), and it would not be affected by the dithering because penalty (or "one-time accelleration of the meter decrease when focus is abandoned") never gets you below target meter.
Or am I still missing something?
Re: Extra voice meeting on Monday 14.02.?
Well, it'll the same as for all the other dev meetings: https://meet.jit.si/ThoroughNovembersConvertPossibly
One of the good things about home office is that you don't have to leave home at all on a stormy day
Re: Extra voice meeting on Monday 14.02.?
Follow up on the suggested equations for meter growth/decay:
The equation for decay, -1-sqrt(current/2), is not aggressive enough to avoid the kind of gain that Ophiuchus pointed out (e.g. get 75% of max research and 50% of max industry by focus dithering).
Using -1-sqrt(current) is enough for the most extreme cases of target_meter_A>>target_meter_B, 100 vs 25, ensuring that the combined percentages of max production of both meters in the focus dithering is smaller than 100%.
This system does not require the macro FOCUS_CHANGE_PENALTY, only the standard meter growth/decay effects.
The equation for decay, -1-sqrt(current/2), is not aggressive enough to avoid the kind of gain that Ophiuchus pointed out (e.g. get 75% of max research and 50% of max industry by focus dithering).
Using -1-sqrt(current) is enough for the most extreme cases of target_meter_A>>target_meter_B, 100 vs 25, ensuring that the combined percentages of max production of both meters in the focus dithering is smaller than 100%.
This system does not require the macro FOCUS_CHANGE_PENALTY, only the standard meter growth/decay effects.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Extra voice meeting on Monday 14.02.?
I wasn't aware that the penalty never takes the meter below the target. Perhaps that should change? Allowing the penalties to current meters from switching focus to overshoot the target meter would make those penalties more effective in general.
Is there a word added or missing? This doesn't make sense to me.
There should be room in the formulas for increasing meter growth/decay due to techs like Force-Energy Structures or similar policies or construction-dependent modifiers to the effects.
What happens when current is negative for such formulas?
Re: Extra voice meeting on Monday 14.02.?
Such a change could help with focus dithering, but not if target meter is 0 and we are changing from/to research or industry. Even as a partial solution, it's not satisfactory when the two target meters are very uneven.Geoff the Medio wrote: ↑Wed Feb 16, 2022 10:55 am I wasn't aware that the penalty never takes the meter below the target. Perhaps that should change? Allowing the penalties to current meters from switching focus to overshoot the target meter would make those penalties more effective in general.
Ehm, no word missing that I can think of, I guess it's grammar knowledge by my part what might be missing here I don't know how to improve the sentence.Geoff the Medio wrote: ↑Wed Feb 16, 2022 10:55 amIs there a word added or missing? This doesn't make sense to me.
I meant, if in a given turn your current research meter is 50 and the target is 10 (you are going down), you don't know if target was 50 or 100 or 200 when focus was research. But that concern of mine is addressed with the suggested equations.
For FES I thought of a simple multiplier. If we want to multiply the rate by X (=2, 3...):Geoff the Medio wrote: ↑Wed Feb 16, 2022 10:55 am There should be room in the formulas for increasing meter growth/decay due to techs like Force-Energy Structures or similar policies or construction-dependent modifiers to the effects.
What happens when current is negative for such formulas?
Increasing:
(1+(X-1)*OwnerHasTech...) * sqrt(target/4)
Decreasing:
-1*(1+(X-1)*OwnerHasTech...) * (1+sqrt(current))
Something similar for Capital Markets affecting only the influence meters.
Note I know syntax of the OwnerHasTech is longer than that, with Statistic If, etc.
For influence, that can have negative target and current meters, I hope it just works with abs(...).
Current 0, target -1, going down from zero to negative
-(1+sqrt(0)) = -1
Current 0, target 1, going up from zero to positive
+sqrt(1/4) = +0.5
Current 1, Target -2, going down from positive to negative
-(1+sqrt(1)) = -2
Current -1, Target -2, going down from negative to negative
-(1+sqrt(abs(-1))) = -1
Current -4, Target -2, going up from negative to negative
+sqrt(abs(-2/4)) = +0.71
Compared to going up from positive 0 to positive 2:
+sqrt(abs(2)/4) = +0.71
Compared to going up from positive 2 to positive 4:
+sqrt(abs(4)/4) = +1
Current -1, Target 2, going up from negative to positive
+sqrt(2/4) = 1.42...
Going up from negative to zero:
+sqrt(0) = 0
Meter would be stalled.
I'll think about a fix.
Except when target is zero and current negative, for which I'll find a fix, It works for the basics: it goes up when you want it to go up, and vice versa.
I haven't written the guards for mix and max in these posts but they are in my spreadsheets.
Re: Extra voice meeting on Monday 14.02.?
If I stick to current growth/decay function for influence (+/-1 per turn), the problem with negative and zero values is gone and it does not allow advantage from focus dithering.
Edit: I'd like to move the posts regarding this subject to another thread, if that's OK and someone wants to do it.
Edit: I'd like to move the posts regarding this subject to another thread, if that's OK and someone wants to do it.
Re: Extra voice meeting on Monday 14.02.?
sorry, couldnt attend yesterday. any notes?
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!
Look, ma... four combat bouts!
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Extra voice meeting on Monday 14.02.?
Influence consumption doesn't update when swapping policies, but can be updated with a planet focus change.
AI has lots of problems. It doesn't settle viable planets right next to its homeworld and then stalls colonizing after a while.
Interactive AI debugging works and Grummel added support for multiline command entry.
I already made a pull request to fix policy adoption cost getters from from Python API.
Figuring out medium term consequences of policy adoption is difficult for AIs and humans. Simulating a sandbox galaxy a few turns might be needed to get that info. Reporting the new maxes or target meters might help.
Maybe a few simple to use and understand but not super powerful policies can be added for people and AIs that can't or don't want to figure out the more complicated ones that might actually cost IP.
It should be easy to expose named valerefs to the Python API.
AI has lots of problems. It doesn't settle viable planets right next to its homeworld and then stalls colonizing after a while.
Interactive AI debugging works and Grummel added support for multiline command entry.
I already made a pull request to fix policy adoption cost getters from from Python API.
Figuring out medium term consequences of policy adoption is difficult for AIs and humans. Simulating a sandbox galaxy a few turns might be needed to get that info. Reporting the new maxes or target meters might help.
Maybe a few simple to use and understand but not super powerful policies can be added for people and AIs that can't or don't want to figure out the more complicated ones that might actually cost IP.
It should be easy to expose named valerefs to the Python API.
Re: Extra voice meeting on Monday 14.02.?
...
Interactive debugging works, but apparently only in single player games and nobody knew why it doesn't work in multiplier games. It's a shame, because acting as a moderator of a multi-player, it is much easier to observe the AIs.
The AI python interface has a generator, but it hasn't been used for a while, so freeOrionAIInterface now locks different from what it would after being generated. The generator is described in default/python/README.md
I have since played around with it. Actually it crashes more often then it works. I've figured out that this is because it relies on at least one field in existence (or maybe visible to the AI). For me it works reliably when I start with one AI and a seed of 2. Also the readme says that it should generate both freeorion.pyi and freeOrionAIInterface.pyi, but it always only updates the later. Cjkjvfnby should know more about it, I hope he can clarify these issues.
Interactive debugging works, but apparently only in single player games and nobody knew why it doesn't work in multiplier games. It's a shame, because acting as a moderator of a multi-player, it is much easier to observe the AIs.
The AI python interface has a generator, but it hasn't been used for a while, so freeOrionAIInterface now locks different from what it would after being generated. The generator is described in default/python/README.md
I have since played around with it. Actually it crashes more often then it works. I've figured out that this is because it relies on at least one field in existence (or maybe visible to the AI). For me it works reliably when I start with one AI and a seed of 2. Also the readme says that it should generate both freeorion.pyi and freeOrionAIInterface.pyi, but it always only updates the later. Cjkjvfnby should know more about it, I hope he can clarify these issues.