Thanks for comprehensive report, should be fixed in Revision: 151051 (and hopefully hotfixed with the next update)

In T174235#2505310, @Mamith wrote:

You seem to misunderstand. I am not talking about a guard as a unit. I am talking about the guard waypoint. These are two different things.

Fixed in 2.12

this only start happening only after last update , however Thank you for checking it

Just applying the callsign stuff to the existing speaker indicator, the same way it applies to text chat. (see also https://community.bistudio.com/wiki/radioChannelSetCallSign)

2.10

I have said it wrong in the first thread the game freezes I counted that as a crash I am not sure on how arma 3 goes with the ungrouping of units but the overall problem was that I had units synced to a trigger which activated them and when I went into zeus whenever i unsynced said units it would just freeze the game doesn't crash it just freezes it only turns off when I press alt + f4 or start clicking into the program then it turns white

can you photoshop some image showing how you imagine it to look like?

You posted no useful information.
Please describe what your actual problem is.
If you mean that your game is crashing, then follow this guide: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

I left the trigger sync connection there.
Fixed in next profiling branch

And a extra question. Its trying to disconnect the synced trigger.
But should it even do that, why would assigning a unit to a different group, unsync it from the trigger? Do you think it should?

Wow I really somehow posted about:blank :D
Should've been this https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

1. A script command (like add or +) doesn't know where the value came from.

It cannot differentiate between 0 add 5 or _variable add 5

The illegal instruction is inside your graphics drivers. dxgi.dll/nvcuda64.dll
Part of Nvidia's graphics drivers, we can't do anything about that

You dumped a ton of information that is useless for me. But didn't provide the actual crash dump that we need.
Please follow this guide: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

There are several freezes. But the freezes are inside Windows code
The crashes all gave you the message

I don't know how this happens, cannot reproduce.
You even had that crash when not loading any mods.

Please follow this: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

1. No
2. Unlikely
3. No
4. No
5. No

Alright, thanks for feedback. Will try what @crashdome suggested instead.

https://community.bistudio.com/wiki/createHashMapObject 2.14

The bases actually don't exist as separate objects. They are all merged (and partially overwritten) when the object is created. So to link to them, we would also have to create instances of the base classes. I don't want to waste that memory/processing time.

Wow. I indeed F'ed up the variable passing in scheduled execution.
Instead of the new map, it passes the argument that you passed to createHashMapObject.

The constructor call environment depends on the caller.
its just a call. So if called from scheduled, it will also be scheduled. If called from unscheduled, it will

If you turn off shadows, you don’t get the full performance gain you should get. You get much better fps if you reduce shadow drawing distance, while this should not be happening as the shadows are turned off already ?

getPlayerChannel, currentChannel and setCurrentChannel were added in 1.42, which seems to cover everything requested in this ticket.

This was resolved by the addition of radioChannelInfo in 2.00

I thought I had it working with 'call' instead of 'spawn' (which it does work if called unscheduled) but, you are right. Call in initPlayerLocal.sqf is scheduled. I don't know why I thought it wasn't. So if you wrap it using isNil, it does fix it as a workaround. This does need to be fixed though.

Yeah, no dice. Tried it wrapped, tried w/ calling a setter instead of using set... All to no avail. Remains broken.

@wjbond - can you confirm that you were playing on server with custom mission where it didn't work?

Found the issue, BIS_fnc_fire has to be RE-allowed. I expected it to be engine-driven.