Should the real economy be changed to match the tooltips?
Moderator: Moderators
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Should the real economy be changed to match the tooltips
What do you mean by alter slow update? Altering the timing of slow update sounds drastic, I would just make the economy pay attention to the slow update rate instead of assuming that it is twice a second.
Re: Should the real economy be changed to match the tooltips
That is fine to, I don't see any issue with that if it was that simple. Slow update happens every 16 ticks, you cannot run something every 15 and still have it on slowupdate.
Re: Should the real economy be changed to match the tooltips
I have looked into this further and it turns out that most things which rely on slow update already have a factor of (float)UNIT_SLOWUPDATE_RATE / (float)GAME_SPEED. The economy parts instead use the magic number 0.5.
Last edited by abma on 12 Feb 2015, 16:37, edited 1 time in total.
Reason: thats wrong! 0.5 isn't use to change update rate, its used to change resource production!
Reason: thats wrong! 0.5 isn't use to change update rate, its used to change resource production!
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Should the real economy be changed to match the tooltips
abma could you elaborate? I do not see how the quote relates to what you said.
Re: Should the real economy be changed to match the tooltips
(synced) engine has a lot of stuff to update:
- projectiles
- unit positions
- pathfinder
- collisions
- ...
- economy
i _guess_ its not everything done in the same tick. when changing magics/update rates this should be kept in mind so no new load-peaks are created when to many things are run at the same time.
either someone with knowledge responds or someone has to test, if changing this will cause new problems. very likely there is a reason why it is 16 and changing it will cause problems/load peaks.
- projectiles
- unit positions
- pathfinder
- collisions
- ...
- economy
i _guess_ its not everything done in the same tick. when changing magics/update rates this should be kept in mind so no new load-peaks are created when to many things are run at the same time.
either someone with knowledge responds or someone has to test, if changing this will cause new problems. very likely there is a reason why it is 16 and changing it will cause problems/load peaks.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Should the real economy be changed to match the tooltips
Then you did not understand what you quoted. In that quote I said that many things that occur in slow update make use of the global constants in order to behave in a way that ends up synced with seconds. For example paralysis and idle autoheal actually do seem to work on seconds. What I said is that the economy related actions use a multiple of 0.5 instead of updateRate/gameSpeed. The quote does not say anything about changing the frequency of slow update.
I basically agree that changing the slow update rate seems risky. It would require more checks than simply changing some economy multipliers.
As an engine developer I expect that you know a bit about how slow update works and what it is for. But now I feel I have to ask: do you know anything about this?
I basically agree that changing the slow update rate seems risky. It would require more checks than simply changing some economy multipliers.
As an engine developer I expect that you know a bit about how slow update works and what it is for. But now I feel I have to ask: do you know anything about this?
Re: Should the real economy be changed to match the tooltips
this was just wrong: viewtopic.php?p=566260#p566260Google_Frog wrote:As an engine developer I expect that you know a bit about how slow update works and what it is for. But now I feel I have to ask: do you know anything about this?
yes, a few. idk why i intuitively thought to change update-rate and not the 0.5 magic constant and yes, i didn't look into the code, that was the problem. changing update rate would also change/"break" selfd time and a lot of other stuff as well. others suggested to change slow-update rate, this is what i responded too.
0.5 is used in a lot of places of slowupdate: https://github.com/spring/spring/blob/d ... .cpp#L1013
its more questionable why is there a multiplicator at all? TA "compatiblity"? just broken?
sadly there are no code-comments, wiki says: http://springrts.com/wiki/Gamedev:UnitDefs#Resources
"energyMake The amount of the energy resource the unit generates unconditionally per game 'tick'." which is wrong.
adding a modrule parameter to allow to change the magic would be possible, too, but this would break stuff as well. as it seems there is no way to change it without breaking stuff: why not remove the magic completely?
imo the questions are: is it worth to break stuff for this? and if so, what to break?
hopefully all posibilities:
1. a modrule parameter would make it more difficult for widgets/ais to get the correct values (but would allow to game devs to let decide when to change it), would break nothing if it defaults to the same value as currently, but will break ai's/widgets when changed by gamedev
2. changing the constant so income is per second would break balance of games "instantly"
3. remove the constant completely would simplify code but would move some calculation to game devs and break everything as well
4. don't change it at all but change widgets to show it correctly
also when changing this other values/magics should be adjusted as well so its consistent as this is already a major change / break. changing this in a backwards compatible way would be difficult as well.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Should the real economy be changed to match the tooltips
To repeat what I said above in the new terminology, I think (4) is the best solution, ideally with an added Game.slowUpdateRate(=16) constant made accessible to lua, (1) is a bit hackish but its simple, although - as abma pointed out - not backwards compatible for widget/AI/map devs, and (2) and (3) are bad.
Re: Should the real economy be changed to match the tooltips
I consider (4) to be inferior because it will lead to ugly numbers either in readout or in code.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Should the real economy be changed to match the tooltips
@Anarchid: Explain? All "readouts" in the UI currently require a math.floor anyway. Lua uses floats and operations (e.g. builds split between multiple cons) will still result in econ numbers not being nice fractions in all cases.
I don't see why it matters either way; clean code and backwards compatibility are more important imo, which is why I favour a game.slowUpdateRate constant known to lua.
I don't see why it matters either way; clean code and backwards compatibility are more important imo, which is why I favour a game.slowUpdateRate constant known to lua.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Should the real economy be changed to match the tooltips
1. It seems stupid to use a modrule for some sort of economy multiplier when we have unitdefs_posts.abma wrote:1. a modrule parameter would make it more difficult for widgets/ais to get the correct values (but would allow to game devs to let decide when to change it), would break nothing if it defaults to the same value as currently, but will break ai's/widgets when changed by gamedev
2. changing the constant so income is per second would break balance of games "instantly"
3. remove the constant completely would simplify code but would move some calculation to game devs and break everything as well
4. don't change it at all but change widgets to show it correctly.
2. How many games are balanced to within an economy speed difference of 6%? I suspect none of them are. I know that DPS, pathing and targeting behaviour have changed a lot between recent engine versions and am not aware of anyone outside ZK taking the changes into account.
3. If you remove the constant then the economy would be in even weirder units of slightly more than half second. The numbers in unitdefs and that are spat out of lua functions should be in units that make sense. Also balance would change a lot.
4. Makes many widgets confusing and does not work across games.
I have dug a bit deeper and realized that slow update of 16 frames is actually awful for the economy. This is to do with tooltips. AddMetal and related functions also update the unit tooltip and resource information for the units team. A units income is the sum of the values sent to AddMetal since the last two slow updates. TeamSlowUpdate is every 32 frames so a teams income is the sum of the values sent to AddMetal over the last 32 frames. It is quite simple to apply the 16/15 multiplier to these values alongside the replacement of the 0.5 factor in AddMetal.
The issue arises when you consider one-off payments. If some high reload time laser costs 500 energy per shot then currently the unit will display a drain of 500 from when it fires until the second slow update after it fired. But when you change the tooltips to show the correct expenditure over time the instantaneous drain of the weapon appears to be 500*15/16. This is because in both cases the UI displays the drain as if it were spread over 32 frames. When the UI is changed to be correct it displays a lower drain.
So the UI is misleading with a slow update of 16 frames in both cases. I think being misleading about income is worse than about instantaneous costs though. This is quite bad and could only be fixed by updating the team resource tooltip once a second alongside an economy fix. This necessitates an update rate that divides 30.
The slow update rate looks configurable in the constants file but it is actually not configurable. Here is how it is used and why it currently has to be a power of 2. It is a speedup with nifty bit tricks for a check which, as far as I can tell, occurs once a frame.
https://github.com/spring/spring/blob/d ... r.cpp#L281
Code: Select all
if ((gs->frameNum & (UNIT_SLOWUPDATE_RATE - 1)) == 0) {
activeSlowUpdateUnit = activeUnits.begin();
}
Re: Should the real economy be changed to match the tooltips
Not related to economy, but some code doesn't even use UNIT_SLOWUPDATE_RATE, instead it uses 16.0f :)
https://github.com/spring/spring/blob/3 ... o.cpp#L226
https://github.com/spring/spring/blob/3 ... o.cpp#L226
Re: Should the real economy be changed to match the tooltips
My vote is for 2 if possible.
'Balance' change will be negligible.
'Balance' change will be negligible.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Should the real economy be changed to match the tooltips
I don't think the balance changes of effectively altering all econ production by 6% are negligible, I'd rate them as huge. Anyways, I think I already made my views clear.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Should the real economy be changed to match the tooltips
If the 6% change is really bad then add a few lines in _posts. But I really doubt it will be noticeable for you. How much can mex income and wind output vary between maps? A lot more than 6%. You could also think of a faster economy as a HP buff and speed nerf for units (because speed and DPS is lower in comparison). So how much variance is there in travel time?
As I said in my previous post, it is impossible to fix the problem with a multiplier. This means that it is impossible to fix this gameside without rewriting the economy in lua. Given this I will push much more strongly for an engine change. Not doing this change would be retaining broken behavior for legacy reasons.
I investigated and changed the slow update rate to twice a second. This is a very clean change which fixes the economy situation and also happens to fix the self-d timer problems. I have adjusted the things which rely on a power of 2 for slow update. In my experience slow update has a small performance cost so the change should not be noticeable in that respect.
https://github.com/GoogleFrog/spring/co ... dateChange
abma unit slow updates are already spread across the update period to reduce load.
https://github.com/GoogleFrog/spring/bl ... r.cpp#L285
As I said in my previous post, it is impossible to fix the problem with a multiplier. This means that it is impossible to fix this gameside without rewriting the economy in lua. Given this I will push much more strongly for an engine change. Not doing this change would be retaining broken behavior for legacy reasons.
I investigated and changed the slow update rate to twice a second. This is a very clean change which fixes the economy situation and also happens to fix the self-d timer problems. I have adjusted the things which rely on a power of 2 for slow update. In my experience slow update has a small performance cost so the change should not be noticeable in that respect.
https://github.com/GoogleFrog/spring/co ... dateChange
abma unit slow updates are already spread across the update period to reduce load.
https://github.com/GoogleFrog/spring/bl ... r.cpp#L285
Re: Should the real economy be changed to match the tooltips
As another balance wonk with hundreds of hours invested in the very particular numbers in S44 unitdefs, I agree with GF -- a 6% change applied universally is really unlikely to have much true impact (and fixing it is, as he said, trivial in unitdefs_post.lua).
I'd be glad to see this change applied.
I'd be glad to see this change applied.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Should the real economy be changed to match the tooltips
With two 'votes' to apply the change I have made a PR for feedback. https://github.com/spring/spring/pull/169
Re: Should the real economy be changed to match the tooltips
ok, thanks, its merged. lets see if we find issues/problems with it. (i hope we don't) :)