Productivity Modules calculate incorrectly (ATM 9)
JonoColwell opened this issue · 7 comments
Starting basis for all numeric comparisons: A hive with 5 crystalline bees, max stat
Base output of the hive: 20 per cycle
Setups:
Productivity Alpha
1 x Upgrade: Simulator
1-3 x Upgrade: Productivity Alpha
Productivity Beta
1 x Upgrade: Simulator
1-3 x Upgrade: Productivity Beta
Productivity Gamma
1-4 x Upgrade: Productivity Gamma
Productivity Omage
1-4 x Upgrade: Productivity Ometa
Specific wording of productivity modules
Spreadsheet of expected outputs vs actual outputs
Expected Productivity | Expected Output | Type | Actual Comb Output | Actual Productivity | Matches/ Higher/ Lower | Pre-Rounding Projected | Post-Rounding Projected | Post Matches Actual? | |
---|---|---|---|---|---|---|---|---|---|
Base Output | 100% | 20 | Combs | 20 | 100% | Matches | 100% | 100% | TRUE |
Alpha (1) | 220% | 44 | Combs | 20 | 100% | Lower | 120% | 100% | TRUE |
Alpha (2) | 340% | 68 | Combs | 40 | 200% | Lower | 240% | 200% | TRUE |
Alpha (3) | 460% | 92 | Combs | 60 | 300% | Lower | 360% | 300% | TRUE |
Beta (1) | 250% | 50 | Combs | 20 | 100% | Lower | 150% | 100% | TRUE |
Beta (2) | 400% | 80 | Combs | 60 | 300% | Lower | 300% | 300% | TRUE |
Beta (3) | 550% | 110 | Combs | 80 | 400% | Lower | 450% | 400% | TRUE |
Gamma (1) | 300% | 60 | Combs | 40 | 200% | Lower | 200% | 200% | TRUE |
Gamma (2) | 500% | 100 | Combs | 80 | 400% | Lower | 400% | 400% | TRUE |
Gamma (3) | 700% | 140 | Combs | 120 | 600% | Lower | 600% | 600% | TRUE |
Gamma (4) | 900% | 180 | Combs | 160 | 800% | Lower | 800% | 800% | TRUE |
Omega (1) | 360% | 72 | Blocks | 40 | 200% | Lower | 260% | 200% | TRUE |
Omega (2) | 620% | 124 | Blocks | 100 | 500% | Lower | 520% | 500% | TRUE |
Omega (3) | 880% | 176 | Blocks | 140 | 700% | Lower | 780% | 700% | TRUE |
Omega (4) | 1140% | 228 | Blocks | 200 | 1000% | Lower | 1040% | 1000% | TRUE |
Observations
It appears that the base 100% productivity of the hive is not taken into account by the productivity modules, and instead sets the productivity to whatever the module is for the first module
It appears that all of the modules round down to the nearest 100% after calculating the producvitity, hence why alpha 1 and beta 1 both round to no effect, because the modules set the productivity to 120% and 150% which is then rounded down to 100% productivity
2 x beta productivity modules comes to 300% which is then rounded down to 300%, which is why there's such a massive jump from one beta productivity module to 2
This is borne out by columns 8-10 of my above table which show the projected value if my above assumptions are taken into account both pre and post rounding as well as if the projection matches the actual
Looked into the code with a friend and it always rounds down the modifiers of the Upgrade. At 100% a Bee produces 4 Blocks, with 260% from Omega it would be ×2.6 which equals 10.4. But it gets rounded down so 2.6 becomes 2 and it actually is just 8 instead of 10.4. Its the same for the following upgrades. 2.6=2 5.2=5 7.8=7 10.4=10. Easy fix would be to round the result. So 4×2.6=10.4 =10 and not 8 like it is now.
I'm pretty sure it does round down the result, all of my "Actual Productivity" column numbers are taken by sitting in a game session and waiting for the hive to produce and tallying up the result, 4x omega did give a 1000% productivity boost, however it should have been 11 even rounded down as the upgrades did not take into account the base productivity of the hive.
The first upgrade sets the productivity from 100% to 260% and with each other upgrade it adds 260%
Not sure what you mean with it rounds the result. It 100% rounds the % as i said 260% = 2.6 and becomes 2. The next step is 2.6 + 2.6 which equals 5.2 and that bevomes 5. It written in the code. Thats no guess.
You are correct and I agree.
However, I believe that based on the wording used in the item description that the 260% should be added to the base productivity.
Per my table above
One omega upgrade currently results in 260% productivity where it should result in 360% as it states "increase by" rather than "increase to"
This would also prevent the current edge case where the first alpha and beta productivity upgrade do nothing assuming that the rounding logic is not changed