You are having some of the following messages:

WARNING: Server attempted to garbage collect radio 'acre_prc343_id_3' but it still exists locally. idi\acre\addons\sys_server\fnc_clientIntentToGarbageCollect.sqf:28

which also causes your antenna not to be found, thus making the communication impossible

it may be that you are using a respawn script that assigns radios? if so make sure you do not assign radios with "*_id_xxx".

In addition you have acre_player [<NULL-object>] could not find a player with ID: 25 7:523 On Radio: 0 idi\acre\addons\sys_core\fnc_remoteStartSpeaking.sqf:80 plus a lot of closed TS pipes.

I will get back to you this evening with more information. Thank you for the feedback

Hi, nothing in the respawn script saves or creates a/the radio.
the only thing we have thats coming close to that is :
// Kill spectator
["Terminate"] call BIS_fnc_EGSpectator;

// Kill ACRE spectator chat
if (Var_ACRE) then {0 = [false] call acre_api_fnc_setSpectator;};

this happens also to other people who are not killed. Who can survive a whole session but out of no-where suddenly cannot hear anyone :/

And the reverse when we are killed ofc:
if (var_acre) then
{
0 = [true] call acre_api_fnc_setSpectator;
};

Havino that discarded. Do you experience heavy desync or disconnections from TS?

@soldia any ideas

Hi, We have not experienced any desync or disconnections from TS.

I will have to add one piece of information, that we do not seem to experience this acre issue on smaller maps or with smaller number of players (15 and below).

We also tested playing on a different teamspeak, we still had the same issues. One odd thing that will sometimes fix it is switching your radios from right to left ear (or the other way around). I dont know how acre works with that but, it seems to "reset" the problem about half the times.

If you experience this with lower player count it points out to desync.. low server fps.

Hi, we do not experience it with lower player count.
We monitor server and headless client FPS (stays stable at 40+).

I am also starting to get this issue. We've seen it with player counts from 5-14. Server FPS is fine.

Can you please check if this happens with omnidirectional antennas activated as well?

Otherwise the best option is to really dive into debugging in one of those sessions.
As those opportunities are rare, it would be the best option to contact me (or @TheMagnetar) in our Slack for specific Debugging actions.

Hi @Soldia1138 . We play with omnidirectional antennas.
Ive PMd you both on slack. appriciate any help in gettin this solved.

Also experiencing this issue with certain players, server FPS is all good, seems to happen after prolonged sessions. One of our players also wasn't receiving direct comms either, but could speak, even after a disconnect and reconnect. We have around 6 people playing at once. Interested to hear how this develops

I’ve experienced this in our yesterdays mission as well. So I’m currently trying to debug it, which is difficult due to the spurious behavior.

@TheFloatingCheese: Is it only on specific maps? Are there any aircrafts involved?

Now that you mention aircraft, I'm pretty sure the few times we've encountered this a helicopter was used during the mission. Might just be coincidental.

@Soldia1138 So far only tested on Altis using KP_Liberation. We were using helicopters, possibly connected.

We've experienced similar behavior as well in Snowfire Gaming:
The issue appears to be related to the AN/PRC-343 radio (especially on picking one up from an AI/corpse; unsure if it is specifically picking up 343s or if it's picking up default Arma radios that turn into 343s on pickup).
NOTE: 343 issue affects all carried radios
We also experienced a similar issue with 152's, although that appears to be caused by using the digital channel change buttons to switch off of the hardware-knob-selected channel and then changing the hardware-knob-selected channel, however the 152 issue is fixed by turning the radio off and back on again (lol).
the 152 issue only affects the 152 radio itself

343 issue not seen since banning 343 and base arma radio pickup among members (~4 months without seeing 343 issue)

server setup (ACRE-wise):
PvE,
Players spawn with 152/148s and NO base arma radios. Players use Blue radios (incl. backpack) with exception of 343 (removed from selection after finding the issue)
AI spawn with a mix of 343s and default arma radios (idk why, personally, but I haven't seen a base arma radio in a while)
Helis are on all maps and used regularly, but idk why that would be related to 343 issues

Unmute clients: yes
TS channel switch: yes
ignore antenna direction: no
Interference modelled: yes
Duplex: yes
Terrain Loss Coefficient: 0.5
AI Voice detect: yes

TS Client (most users) 3.1.10
TS Server: 3.0.13.8

It would be intereating to know your TS version

@TheMagnetar TS Client (most users) 3.1.10
TS Server: 3.0.13.8
I also edited the info into my previous post for the sake of ease-of-finding

We're experiencing the same problem with ACRE 2 sometimes. Yesterday it was happened when there was around a 12 players on server. Also there is a problem sometimes, when the transmitting is delayed for around a 3-5 seconds after button is pushed.

Is any community willing to test an older version of ACRE just to clarify where the issue might come from? From everything I've heard and experienced so far, it might be some kind of caching/queuing/buffering issue. And it's most likely on client side.
As we haven't introduced some minor changes to the backend, it'll be helpful to understand if this happens with e.g. Version 2.6.1 (https://github.com/IDI-Systems/acre2/releases/tag/v2.6.1.992)

I can provide some server logs, which I've found. I suppose it could help to make some clarify:

20:17:25 [ACRE] (sys_server) WARNING: Desync - Garbage collection prevented for radio 'acre_prc148_id_3' from player 'Henry Willamson' as it still exists for them locally! idi\acre\addons\sys_server\fnc_stopRadioGarbageCollect.sqf:27
20:17:35 [ACRE] (sys_server) WARNING: Desync - Garbage collection prevented for radio 'acre_prc148_id_3' from player 'Henry Willamson' as it still exists for them locally! idi\acre\addons\sys_server\fnc_stopRadioGarbageCollect.sqf:27

This is only messages from ACRE in a logs and it is roughly corresponds to the time when an issue is happened.

Hello, i am very new to programming and idk how to work out servers that well, any how, i have an arma 3 dedicated and ts3 dedicated server wich since the last ACRE update we started having issues of ACRE radio simply not working at all, player player A have his radio working, Player B cannot neither transmit or receive; player C can transmit and receive etc etc

Yeah my group still has this issue mixed with #875 and it happens almost exclusively upon respawning players. We are trying the fix of changing from multipath to single and getting rid of terrain coefficients to see if that works.

the respawning problem is totally different. If before the respawn radios work, and after respawn there is trouble, please have a look at your respawning scripts/templates

Had this occur two missions in a row, where radios simply stopped working for some users, and 343s stopped working altogether. Both of the missions included aircraft, going back to what @synixebrett and @Soldia1138 was talking about.

Running with multi-path

This was on v2.7.4, pending update to our unit modpack.
acre_dll.log
arma3_x64_2020-09-26_18-39-19.rpt.txt

A user submitted an error log with, well, a lot of errors:
arma3_x64_2020-09-26_15-39-14.rpt.txt

Encountered it again, and enabled a bunch of debug logging. Turning on transmission hints it was locked at -992dBm on all transmissions, even within 5m and in the same vehicle. 117s and vehicle racks didn't make a difference.

Here are the RPT logs from a few users, where we had signal traces to RPT enabled towards the end.
RPT Logs.zip

Mission involved lots of helicopters moving about and 30, upwards of 40 players. Radios failed for some users first being able to send and not receive, especially the FAC. Later it completely failed for all users on all radios.

Here are the settings used:

// ACRE2
force acre_sys_core_automaticAntennaDirection = true;
force acre_sys_core_fullDuplex = true;
force acre_sys_core_ignoreAntennaDirection = true;
force acre_sys_core_interference = false;
force acre_sys_core_revealToAI = 0.5;
force acre_sys_core_terrainLoss = 0.8;
force acre_sys_core_ts3ChannelName = "hidden";
force acre_sys_core_ts3ChannelPassword = "hidden";
force acre_sys_signal_signalModel = 2;

Anyone found a solution? Experiencing the same issue.

Is any community willing to test an older version of ACRE just to clarify where the issue might come from? From everything I've heard and experienced so far, it might be some kind of caching/queuing/buffering issue. And it's most likely on client side. As we haven't introduced some minor changes to the backend, it'll be helpful to understand if this happens with e.g. Version 2.6.1 (https://github.com/IDI-Systems/acre2/releases/tag/v2.6.1.992)

In the test setup where I was able to reproduce the garbage collection warning the version you posted did not make much of a difference.

The Setup was basically just setUnitLoadout in a loop.
It does not happen when I load a loadout from the ACE arsenal, tho.

The duplicate errors/warnings can be fully fixed by making sure that no "_ID_x" unique radios are in the loadout.
I don't understand why loading from the ACE arsenal does not seem to trigger the warning, as its also using the same setUnitLoadout as my scripts.

Closing this issue in favour of #1163 as it has a bit more up-to-date information.