Should the real economy be changed to match the tooltips? - Page 2

Should the real economy be changed to match the tooltips?

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Google_Frog
Moderator
Posts: 2448
Joined: 12 Oct 2007, 09:24

Re: Should the real economy be changed to match the tooltips

Post by Google_Frog »

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.
User avatar
smoth
Posts: 22306
Joined: 13 Jan 2005, 00:46

Re: Should the real economy be changed to match the tooltips

Post by smoth »

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.
abma
Spring Developer
Posts: 3621
Joined: 01 Jun 2009, 00:08

Re: Should the real economy be changed to match the tooltips

Post by abma »

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.
i guess it is different to reduce load-peaks.
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!
Google_Frog
Moderator
Posts: 2448
Joined: 12 Oct 2007, 09:24

Re: Should the real economy be changed to match the tooltips

Post by Google_Frog »

abma could you elaborate? I do not see how the quote relates to what you said.
abma
Spring Developer
Posts: 3621
Joined: 01 Jun 2009, 00:08

Re: Should the real economy be changed to match the tooltips

Post by abma »

(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.
Google_Frog
Moderator
Posts: 2448
Joined: 12 Oct 2007, 09:24

Re: Should the real economy be changed to match the tooltips

Post by Google_Frog »

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?
abma
Spring Developer
Posts: 3621
Joined: 01 Jun 2009, 00:08

Re: Should the real economy be changed to match the tooltips

Post by abma »

Google_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?
this was just wrong: viewtopic.php?p=566260#p566260

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.
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

Re: Should the real economy be changed to match the tooltips

Post by Silentwings »

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.
User avatar
Anarchid
Posts: 1383
Joined: 30 Nov 2008, 04:31

Re: Should the real economy be changed to match the tooltips

Post by Anarchid »

I consider (4) to be inferior because it will lead to ugly numbers either in readout or in code.
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

Re: Should the real economy be changed to match the tooltips

Post by Silentwings »

@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.
Google_Frog
Moderator
Posts: 2448
Joined: 12 Oct 2007, 09:24

Re: Should the real economy be changed to match the tooltips

Post by Google_Frog »

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.
1. It seems stupid to use a modrule for some sort of economy multiplier when we have unitdefs_posts.

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();
}
A faster update may be bad because some performance hungry things depend on it. Maybe it would be reasonable to have a different update rate for economy.
lamer
Posts: 153
Joined: 08 Mar 2014, 23:13

Re: Should the real economy be changed to match the tooltips

Post by lamer »

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
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6193
Joined: 29 Apr 2005, 01:14

Re: Should the real economy be changed to match the tooltips

Post by FLOZi »

My vote is for 2 if possible.

'Balance' change will be negligible.
User avatar
Silentwings
Moderator
Posts: 3666
Joined: 25 Oct 2008, 00:23

Re: Should the real economy be changed to match the tooltips

Post by Silentwings »

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.
Google_Frog
Moderator
Posts: 2448
Joined: 12 Oct 2007, 09:24

Re: Should the real economy be changed to match the tooltips

Post by Google_Frog »

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
User avatar
Nemo
Spring 1944 Developer
Posts: 1376
Joined: 30 Jan 2005, 19:44

Re: Should the real economy be changed to match the tooltips

Post by Nemo »

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.
Google_Frog
Moderator
Posts: 2448
Joined: 12 Oct 2007, 09:24

Re: Should the real economy be changed to match the tooltips

Post by Google_Frog »

With two 'votes' to apply the change I have made a PR for feedback. https://github.com/spring/spring/pull/169
abma
Spring Developer
Posts: 3621
Joined: 01 Jun 2009, 00:08

Re: Should the real economy be changed to match the tooltips

Post by abma »

ok, thanks, its merged. lets see if we find issues/problems with it. (i hope we don't) :)
Post Reply

Return to “Engine”

cron