3 Commando Brigade

Actually, it makes perfect sense -- as much as a random hacky way of implementing "unique" radios can make sense ;) 
The radios have a class/item as a base, e.g. tfr_anprc152 (152 being name, not id).
In the arsenal or in ammoboxes, you'll find an item of classname "tfr_anprc152". When you take it into inventory some magic event handler is called that goes and finds an unused (not necessarily "new", afaik, just "unused") ID.
It then hands you the item with classname tfr_anprc_152_ID (e.g. tfr_anprc_152_666). There are 999 ID's per radio, from tfr_anprc_1 to tfr_anprc_999.
This is why ID's are only unique to each radio.

When you grab a radio from the arsenal, it gives you a tfr_anprc152. For some reason, it doesn't seem to replace it with a unique id version until you leave the arsenal. (event handler magic?)
So during this phase, you might actually be able to save a loadout with a radio in it, since it'll be the "generic" radio classname.

However, if you leave the arsenal and get yourself a tfr_anrpc152_ID and then go and save that in the arsenal, this is were issues might appear.
I'm not sure if they added magic that kicks in when you leave arsenal and replaces it with a new ID. They might, or might not have that and it might or might not work all the time.

What I do know is that the arsenal mod (same one as the one with the weights) introduces partial loading, so you can simply add only the generic classnames to the whitelist (allowing people to grab radios and save "generic" ones) but when you try and load one of the loadouts that contain a unique-ID version it'll simply go "1x item tfr_anprc152_666 is not whitelisted" and load your loadout minus the radio (and any other non-whitelisted stuff).

I'm just hunting down a bug that I noticed when I took the screenshot for you (value of container weight is waaay to low to be real, must still be log(value) rather than value) but expect an updated, @ASDG JR compatible version of the arsenal mod to be released tonight.

Lack of reports on this forum does not mean it isn't happening.
I have personally experienced players on the public server, in the last 2 weeks, outside of that Op, with radio channel issues caused by duplicate ID's.
We know there WAS a problem. We do not KNOW that it has been solved, apart from a single line lacking detail in a changelog.
So far tests show that the problem probably still exists. Certainly tests do not show that the problem has been solved.
I therefore feel on balance that we should assume that the problem still exists until proven otherwise. And in that regard we should still be telling everyone not to save radio's in their loadouts.

Ok, that's a fair assumption to make. However, when you're suggesting to create a mod that erases radios from loadouts as they're loaded - do you not think that perhaps we should confirm what we believe to be true first, before implementing such a thing?

That depends on how long you take to prove it.  :-)
just kidding with ya

Haha, I'm working on it

The issue has been fixed by the lovely TFAR developers. Again, I want to point out how amazing open-source mods with github repos are.
Searched their issues for "Duplicate Radio" and found this: Duplicate radio ID problem #313 

And here is the developer's explanation of how it works:

So yes, the original issue has been fixed.
Some weird vodoo happened with the last private op (no AI on a mission that ran stable on the public for days and days) and chances are good any weird radio issues can be chalked up to voodoo, too.
Combined with the fact that it hasn't been noticed on the public in quite a long time, even when we see ~50 people on it at some times, I'd say its actually safe to save and load radios now. 
Open-source repos FTW!

@alexander

I got them to dump their radio that they had saved in VA and get a new one. Problem was solved.
Don't ask me why it was happening if it was supposed to have been fixed, just giving you an observation that disagrees with your assertion that it isn't happening any more.

The unknown is whether the put and take event handlers are actually used when you load from the Arsenal.

Jamie and I did some testing on the dev server.

The UID of the owning player is stored in the class "<radio name>_xx" where xx is a unique integer assigned to the radio.

When you first pull the radio out of the arsenal it is assigned the integer.  From that point onwards it seems to keep the same integer (except in the case of a conflict --- see below).  We past radios between ourselves and the integer was preserved, but the player id within the class was undated to the owner of the radio.

When you save the radio in the loadout, the integer is also saved.  Jamie loaded a loadout from the arsenal with the same integer value as a radio that I had.  So there was a conflict in numbers and his radio's integer was automatically increment to another unique number.  We tried it a couple of times and it worked correctly.

The only issue that we saw was that the unique integer and player UID combination seemed to not always propagate to other clients.  Using the debugger on my client I could see Jamie's radio, but according to my client that radio belonged to me.   This is not necessarily an issue, as it was not in my inventory.  By default it looks as though a client assumes all radios belong to the local player.  It looks like the information may only be fully propagated between clients in the event of a conflict. 

So, there should not be a problem.  However on Sunday there was.  It may have been down to comms issues between clients and server.

I can put some monitoring code in the config to check player UIDs align with equipped radios, and log any issues. 

Just as an aside if I remember rightly some people did get a TFAR error saying that there was a version mismatch. I did for sure.


Sent from my iPhone using Tapatalk