September 22nd, 2021, 13:03
(This post was last modified: September 22nd, 2021, 13:12 by Seravy.)
Posts: 10,463
Threads: 394
Joined: Aug 2015
1. Currently the game calculates the production output of each individual percentage bonus source separately, using the same rule for rounding. (round down)
This is simple, easy to understand but can result in inconsistent output between individual additional workers. (sometimes a new worker will cause each line separately to increase by more due to how rounding works, adding much more production than other workers who don't trigger this side effect.)
2. It's also possible to add all percentage bonus together and apply this bonus in one go.
This leads to inconsistent rounding rules (each separate source of production will randomly round up or down depending on which is required to get the desired total result) but a more stable difference between individual worker outputs (as there is only one rounding for percentage production, there can only be a total of 1 difference coming from this type of rounding - albeit other effects can still add more.) and also causes inconsistency in the Omniscient effect (Power, Research always rounded down, but gold and production, sometimes not.), however it does yields the result you'd expect from looking at the surveyor bonus which shows the total percentage.
It might also lead to a tiny bit slower turn times and city UI times as it requires a longer script to calculate.
September 22nd, 2021, 14:07
(This post was last modified: September 22nd, 2021, 15:14 by WhiteMage.)
Posts: 633
Threads: 13
Joined: Nov 2010
(September 22nd, 2021, 13:03)Seravy Wrote: 1. Currently the game calculates the production output of each individual percentage bonus source separately, using the same rule for rounding. (round down)
This is simple, easy to understand but can result in inconsistent output between individual additional workers. (sometimes a new worker will cause each line separately to increase by more due to how rounding works, adding much more production than other workers who don't trigger this side effect.)
2. It's also possible to add all percentage bonus together and apply this bonus in one go.
This leads to inconsistent rounding rules (each separate source of production will randomly round up or down depending on which is required to get the desired total result) but a more stable difference between individual worker outputs (as there is only one rounding for percentage production, there can only be a total of 1 difference coming from this type of rounding - albeit other effects can still add more.) and also causes inconsistency in the Omniscient effect (Power, Research always rounded down, but gold and production, sometimes not.), however it does yields the result you'd expect from looking at the surveyor bonus which shows the total percentage.
It might also lead to a tiny bit slower turn times and city UI times as it requires a longer script to calculate.
Thanks so much for hosting this survey. But I would phrase "This leads to inconsistent rounding rules (each separate source of production will randomly round up or down depending on which is required to get the desired total result)" differently. There is nothing inconsistent about rounding rules in 2.
Add up all base productions (farmers, workers, Sawmill, Smithy, Stables). Add up all percent bonuses (Terrain, Forester's Guild, Miner's Guild, Mechanician's Guild, Omniscient). Then multiply the 2 sums. Add this to the sum of base productions. The result of this is rounded down. There is no other rounding.
September 22nd, 2021, 15:18
(This post was last modified: September 22nd, 2021, 15:22 by Seravy.)
Posts: 10,463
Threads: 394
Joined: Aug 2015
(September 22nd, 2021, 14:07)WhiteMage Wrote: (September 22nd, 2021, 13:03)Seravy Wrote: 1. Currently the game calculates the production output of each individual percentage bonus source separately, using the same rule for rounding. (round down)
This is simple, easy to understand but can result in inconsistent output between individual additional workers. (sometimes a new worker will cause each line separately to increase by more due to how rounding works, adding much more production than other workers who don't trigger this side effect.)
2. It's also possible to add all percentage bonus together and apply this bonus in one go.
This leads to inconsistent rounding rules (each separate source of production will randomly round up or down depending on which is required to get the desired total result) but a more stable difference between individual worker outputs (as there is only one rounding for percentage production, there can only be a total of 1 difference coming from this type of rounding - albeit other effects can still add more.) and also causes inconsistency in the Omniscient effect (Power, Research always rounded down, but gold and production, sometimes not.), however it does yields the result you'd expect from looking at the surveyor bonus which shows the total percentage.
It might also lead to a tiny bit slower turn times and city UI times as it requires a longer script to calculate.
Thanks so much for hosting this survey. But I would phrase "This leads to inconsistent rounding rules (each separate source of production will randomly round up or down depending on which is required to get the desired total result)" differently. There is nothing inconsistent about rounding rules in 2.
Add up all base productions (farmers, workers, Sawmill, Smithy, Stables). Add up all percent bonuses (Terrain, Forester's Guild, Miner's Guild, Mechanician's Guild, Omniscient). Then multiply the 2 sums. The result of this multiplication is rounded down. There is no other rounding.
That's not how the game works - you are trying to remove or ignore features for your convenience.
AFTER what you posted, it has to individually adjust each displayed line to have the correct total.
Example : 50 base production (20 workers and 20 farmers), forester's guild, mechanician's guild, 15% bonus from terrain.
Result = 50*(160%) = 80
Displayed Lines :
Farmers = 10
Workers = 40
Forester's Guild = 50*10% = 5
Mechanican's Guild = 50 * 35% = 17
Terrain = 50 * 15% = 12
This adds up to 79 so it's incorrect.
So the script will have to add 1 somewhere.
Most likely it will be added to the first line to keep it simple, so it will display "Forester's Guild = 6". (Which btw causes by far the most inaccuracy)
Or it could display "Terrain = 13" or "Mecha Guild = 18".
Either one of those three. Which means the result on that line is rounded up, other lines are rounded down. In worst case scenario a line will display an entire +1 more than it should.
If the total is higher by more than 1 (more rounding than in the above example) then that many different lines have to be increased by 1 each.
Displaying the output of each building is a feature and it's not going to be removed and the sum of all lines has to be equal to the total.
September 22nd, 2021, 15:59
(This post was last modified: September 22nd, 2021, 16:15 by WhiteMage.)
Posts: 633
Threads: 13
Joined: Nov 2010
“AFTER what you posted, it has to individually adjust each displayed line to have the correct total.”
As I wrote earlier, I can do that if there is at least 1 person who would be interested in it. For myself, I don’t need it.
“Example : 50 base production (20 workers and 20 farmers), forester's guild, mechanician's guild, 15% bonus from terrain.
Result = 50*(160%) = 80
Displayed Lines :
Farmers = 10
Workers = 40
Forester's Guild = 50*10% = 5
Mechanican's Guild = 50 * 35% = 17
Terrain = 50 * 15% = 12”
In my formula 50*35% =17.5
50 * 15% =7.5
These are the accurate values. So it would be 10+40+5+17.5+7.5=80
But to show something close to these true values in integers, I would need to intentionally make the individual lines slightly inaccurate. So I would need to show Mechanican's Guild=18 and Terrain =5. I can do this, but this is pure cosmetics to make the UI intentionally less accurate, but more detailed so players can eye ball what is going on, but don’t take the individual lines seriously. The final results, however, will be always accurate, with <1 error due to the final rounding down to integer.
“This adds up to 79 so it's incorrect.
So the script will have to add 1 somewhere.
Most likely it will be added to the first line to keep it simple, so it will display "Forester's Guild = 6". (Which btw causes by far the most inaccuracy)
Or it could display "Terrain = 13" or "Mecha Guild = 18".
Either one of those three. Which means the result on that line is rounded up, other lines are rounded down. In worst case scenario a line will display an entire +1 more than it should.
If the total is higher by more than 1 (more rounding than in the above example) then that many different lines have to be increased by 1 each.
Displaying the output of each building is a feature and it's not going to be removed and the sum of all lines has to be equal to the total.”
OK. So I take it that you want a version that shows each line. I will work on it, happily.
The alternative is to add one more line called LEFTOVERS as you suggested earlier, which is the sum of all rounding errors that can be 0, 1, 2, or 3, I think.
So which do you prefer? Use LEFTOVERS for the sum of rounding errors, or add the extras to the buildings?
September 22nd, 2021, 16:44
Posts: 10,463
Threads: 394
Joined: Aug 2015
First we wait for the poll results. If a significant number of votes are on the second option then I will most likely prefer the "Leftovers" version as it's less confusing than randomly adding 1 to specific lines. If the second option does not get a majority or at least relevant support then I prefer leaving everything as is.
Posts: 343
Threads: 4
Joined: Mar 2020
How about displaying a decimal number instead of visual hammers? Then there's no rounding problem for individual buildings' output display. It's also easier to read.
Posts: 224
Threads: 4
Joined: Sep 2019
(October 4th, 2021, 20:36)massone Wrote: How about displaying a decimal number instead of visual hammers? Then there's no rounding problem for individual buildings' output display. It's also easier to read.
Decimal numbers for a medieval-age fantasy game? I think that might break immersion. It might also make it feel like doing taxes or math homework. If there's some round-off errors, just attribute it to the blacksmiths having a few too many flagons of beer.
January 22nd, 2022, 13:18
(This post was last modified: January 22nd, 2022, 15:06 by WhiteMage.)
Posts: 633
Threads: 13
Joined: Nov 2010
This poll has been open for 4 months. As of now we have 12 votes. 7 (58.33%) voted for my proposed change, 2 (16.67%) voted against. Can you please make a decision? Or how much longer do you want to wait?
I can spend a little more time on this project if there is a genuine need from players and a decision is made soon. Otherwise, I am unlikely to come back and do it later, since I already started a new software development project. And if I don't do this, probably no one will.
January 23rd, 2022, 14:11
(This post was last modified: January 23rd, 2022, 14:20 by Seravy.)
Posts: 10,463
Threads: 394
Joined: Aug 2015
I was hoping for more than 12 total votes to be honest.
I don't think 7 votes can be called a "genuine need" unfortunately.
I'm theoretically willing to include this change. Fortunately I'm playing a game that uses a similar logic so I find it more intuitive nowadays albeit that game has no "detailed view" that makes it confusing here.
(it's an RPG but same idea except it's base attack and buffs that add attack percentage.)
I generally want to avoid anything that requires large scale changes that affect many lines in the scripts. Who will test all that? I won't, but I also won't include something I personally didn't test at all. So the solution has to be simple.
To adjust each line individually to match the total, each line's value has to be stored in a variable, then depending on the total, the variable needs to be increased, and finally ADDRESLINE has to be executed for all of them at the end of the script. This works but it literally changes 90% of the script. High risk of errors.
To display a "Leftovers" line, you need to calculate the "correct" total, which requires storing the percentage modifiers in a variable. This only requires adding a "percentagebonus=percentagebonus+x" part to the few effects that add such bonus. The base value already has a variable in most scripts I think so then it's just a single new Addresline "leftovers", BASE*percentagebonus/100 at the end. This seems safe, easy to implement with minimal chance of error and doesn't really require testing beyond the usual, playing the game once and reading the code is enough.
So I think we should do the latter. It's simple enough so I'll add it to my TODO list. Don't worry about it, I'll manage.
I think the first solution would be better for immersion and user experience but for the time being I have to also consider my own willingness to spend time on new features which is not very high.
The next question is, what should we name that line?
"Leftovers" does work but maybe we can come up with something better?
Wait, it's not that simple. There is also a lot of stuff that's neither base not a percentage bonus.
This can only work if everything in the script is reordered so that base values and percentage values are processed first, otherwise "sumresline()" does not give us the correct result.
...or is there? No, maybe there isn't. I can't find any.
...Sorry I think I'll pass on this for now. But I did add it to my TODO list so it'll happen eventually.
January 23rd, 2022, 14:32
(This post was last modified: January 23rd, 2022, 14:36 by tarkalak.)
Posts: 13
Threads: 0
Joined: Jan 2022
What about adding another line "Rounding correction" or something and add the hammers there.
You can calculate the old way and then the new way and just put the leftover in the "leftover" tab.
I am fine the way it is now. But I wouldn't mind it changed.
|