Description of the issue:

Since the 1.8 update, radios with large range have a massive simulation cost on the server whenever a player is transmitting.

The issue also happens in Singleplayer, but with many players transmitting, it will obviously be more serious.

Reproduction:

1. Create a new Workbench project, select any radio prefab like e. g. Radio_ANPRC68, and override it.

2. In the override, go into the BaseRadioComponent. Typically, vanilla radios have 2 transceivers - set the range of one transceiver to a very high value like 100000, leave the other as normal for comparison.

3. Now, run any scenario, like e. g. Game Master - regular Workbench Singleplayer is sufficient.

4. Make sure you don't have an FPS cap so the issue is more obvious. Enable current/detailed (not average) FPS display in the diag menu.

5. Spawn yourself a character with the radio, select the unmodified transceiver and transmit - there will be no significant impact.

6. Now transmit using the transceiver with extended range - there will be an abrupt and sustained drop in FPS while you are transmitting.

Impact

Obviously, in a dedicated server environment, the lag will happen on the server and not the client.

To provide some statistics, I tested a 100k tranceiver in GM Arland. Average frametime without transmitting was 10ms (note that this includes the client, server would be much lower), 1ms of that was simulation. For the duration of a transmission, simulation frame time increased by 14ms (15x the normal). 50k range increased it by 8ms, with 25k range by 2ms.

Even if the cost is smaller with more lower ranges, that is still a huge impact on the server for obvious reasons, especially if many players are transmitting frequently, possibly even at the same time.

Origin

This issue was introduced in the 1.8 update, in particular I suspect it is related to the VoN optimization mentioned in the changelog ("Tweaked: Improved VoN Performance").

I don't know what that optimization was, but my speculation is that someone might have tried to "optimize" radios by replacing a simple within-range check (constant runtime complexity) with something more complicated, which might have even been a small improvement at very short ranges, but is absolutely detrimental at long ranges.

This also happens in 1.8.0.13, and is unrelated to the former issue with radios turning off that now been fixed.

Severity

While one could argue that none of the radios in vanilla have such a large range, this is a very serious problem for two reasons:

First of all, in a modded context, there are situations in which radios should transmit across the entire map, not just within a small range. The issue came to my attention because we did actually have radios with such large range, which we use for realizing VoN of spectator players, who need to transmit across the entire map regardless of range.

Secondly, the radio ranges in vanilla are not representative of the needs in a military simulation game (they are even sustantially less powerful than their real life counterparts) - many real life manpack radios already have up to 5 digit ranges, and vehicle radios, commonly VHF or sometimes even UHF, have even greater ranges. Terrain size is also large enough that this is relevant, e. g. a 32x32 terrain has a diagonal distance of almost 50km.

Conclusion

If my suspicion about the "optimization" is correct, it should probably be reverted or significantly altered.