[2.0.28] Multiple beacons rounding effect transmission inconsistently

[TheBrain0110]

I noticed when playing with some legendary beacon setups, that the precise effect values get rounded slightly differently depending on how the modules are distributed between multiple beacons.

For example here:

Screenshot 2024-12-29 at 16.43.31.png (4.33 MiB) Viewed 431 times

Putting 2 [Legendary Speed 3] Modules in one beacon and 2 [Legendary Efficiency 3] Modules in another gives the Rocket Silo [Crafting Speed 19.05 / +662%] and 18.47 MW / +363% energy usage.


But If you switch them around to be 1 speed & 1 efficiency in each of the two side beacons (ignoring the middle one that stays the same):

Screenshot 2024-12-29 at 16.43.07.png (4.62 MiB) Viewed 431 times

You get Crafting Speed 19.025 / +661% and 18.51MW / +364% energy usage.

So it looks like using 2 of the same module in one beacon is marginally more effective than putting 1 of each in each beacon.

This is on an Arm64 M2 Max Mac, just in case in comes down to architecture differences in floating point math...

[boskid]

Thanks for the report however i am not considering this to be a bug. Effect values were designed to be integer values and as such when you have legendary speed module with +125% effect, when beacon's distribution_effectivity is applied, for 1 module you get 125%->187% effect advertised by the beacon while for 2 modules you get 250%->375%. To change this behavior the effects would have to be changed to not be integers anymore.

[computeraddict]

To change this behavior the effects would have to be changed to not be integers anymore.

As I understand it the truncation is happening in an intermediate step before the final machine bonus calculation. Could the formula be rearranged so that truncation only happens at the end? Because with things like beacon effectiveness being fractional numbers with square roots involved there's floating point going on somewhere in the chain.

[boskid]

As I understand it the truncation is happening in an intermediate step before the final machine bonus calculation. Could the formula be rearranged so that truncation only happens at the end? Because with things like beacon effectiveness being fractional numbers with square roots involved there's floating point going on somewhere in the chain.

That would require making effects to be floats somewhere and i do not want doing that because that would require huge rewrite of the effects code because right now effect receiver holds all beacons in non deterministic order (96457 -> 98445) and floats math is fragile to rounding errors accumulating differently when order of operations is changed. That means all the intermediate values must be fixed point so the order of operations does not affect outcomes of the effect computation. Since beacons of different quality can have different distribution effectivity, can have different state of energy, can belong to different forces with different force's beacon distribution modifiers, there are no common subexpressions that could be extracted out of a bracket.