Applying beacon diminishing returns based on cumulative base effects
Posted: Mon Nov 04, 2024 6:37 pm
As of release of 2.0/SA beacons feature diminishing returns. This is based purely on the number of beacons active on the receiving entity. There are some gripes and issues with this mechanic I will try to outline to segway into the suggestion. To be clear: this is not about the diminishing returns per se - I support that as a good incentive to diversify builds.
To illustrate the issue I use the following example:
In the example picture the left setup has 240% crafting speed on the assembler, but it is slightly below the required output to achieve a compressed belt with an even number of units. When adding another beacon with a speed & efficiency module to 'push it over the threshold', contrary to expectations this actually has a net negative effect as the crafting speed drops to 222% in the right setup when adding a beacon.
Thus the issue is that returns in this case are not diminishing (=weaker), but actually negative. The expectation is that adding a beacon would still provide a small bonus with progressively weaker effect.
Gripes with the application of transmission based on the number of beacons are:
So how can diminishing returns be applied without negatively impacting efficiency modules or having weaker effects for lower tiers? The suggestion is: applying beacon diminishing returns based on cumulative base effects.
The notion is that by simply calculating the sum of effects per beacon, and applying a scaling function based on the total will do the trick. This would be done per effect type:
E.g.
The effects of this scaling could be tuned based on the base values and scaling function itself to essentially replicate the current status quo. However, the key difference would be that adding an empty, a beacon with efficiency modules, or lower tier beacons would not kill the original effects, but instead only add to the diminishing returns, if applicable (e.g for a tier 1 module being added). In essence, it would increase the cumulative base effect, which would then scale to yield the diminished return, but still a return.
An argument for this change is the negative impact of the current calculation on design freedom:
To illustrate the issue I use the following example:
In the example picture the left setup has 240% crafting speed on the assembler, but it is slightly below the required output to achieve a compressed belt with an even number of units. When adding another beacon with a speed & efficiency module to 'push it over the threshold', contrary to expectations this actually has a net negative effect as the crafting speed drops to 222% in the right setup when adding a beacon.
Thus the issue is that returns in this case are not diminishing (=weaker), but actually negative. The expectation is that adding a beacon would still provide a small bonus with progressively weaker effect.
Gripes with the application of transmission based on the number of beacons are:
- Can have weaker total effect, which may be unintuitive (when using empty beacons, beacons with lower tier modules, efficiency modules).
- Penalizes lower tier modules more than max tier.
So how can diminishing returns be applied without negatively impacting efficiency modules or having weaker effects for lower tiers? The suggestion is: applying beacon diminishing returns based on cumulative base effects.
The notion is that by simply calculating the sum of effects per beacon, and applying a scaling function based on the total will do the trick. This would be done per effect type:
E.g.
Code: Select all
Applied per module type:
Beacon effect = sum of [module effect] x [beacon transmission rate]
Sum of beacon effects = sum of effects (from all modules/beacons)
Applied effect = f(sum of effects), e.g. sqrt(sum of effects)
An argument for this change is the negative impact of the current calculation on design freedom:
- current system promotes the use of beacon rows of the same type
- discouraging the use of mixed modules
- discourages using interspersed efficiency beacons
- penalizes lower tier modules more than it should