I believe I have set everything up properly, however this wouldn't explain why all the Zeus Modules don't work with a CfgRemoteExec set up.

Also this worked before 1.54!

I can also confirm this issue. This issue is related to the 'Treat' animation fix that was implemented by Bohemia a few patches ago. The fix stopped the unit treating from teleporting in front of the unit being treated. After this patch however we found that medics would randomly lose all their actions and hear a constant treating sound from the treat animation.

The only way to fix this bug currently is to respawn to break the loop. I have also implemented an alternative action that bypasses the use of FAKs and Medikits. This bug has been tested in a dedicated & local server running nothing but stock ArmA 3 content.

This bug is less likely to happen when treating yourself, but much more likely to happen treating others. Almost seems like a dsync issue as if the unit being treated hasn't correctly informed the treater that the healing has been successful.

Hope this helps lead to a fix ASAP!

Bug has been reproduced and assigned over at http://feedback.arma3.com/view.php?id=21906

Good job lads!

much appreciated!

I can also confirm this issue. This issue is related to the 'Treat' animation fix that was implemented by Bohemia a few patches ago. The fix stopped the unit treating from teleporting in front of the unit being treated. After this patch however we found that medics would randomly lose all their actions and hear a constant treating sound from the treat animation.

The only way to fix this bug currently is to respawn to break the loop. I have also implemented an alternative action that bypasses the use of FAKs and Medikits. This bug has been tested in a dedicated & local server running nothing but stock ArmA 3 content.

This bug is less likely to happen when treating yourself, but much more likely to happen treating others. Almost seems like a dsync issue as if the unit being treated hasn't correctly informed the treater that the healing has been successful.

Hope this helps lead to a fix ASAP!

I can also confirm this issue.

This snippet of code will have no impact on performance whatsoever.

The reason I am using onEachFrame is to ensure that the loop is suppressed before it can fire as the draw mines while loop will be running on its own co-routine.
onEachFrame isn't slow, its what goes in it that makes it perform slowly because of the rate of execution - and setting two booleans wont take anytime whatsoever.

This is just a temporary fix until bohemia fix the issue and provide an alternative!

["sneakyMines", "onEachFrame", {
BIS_fnc_drawMinefields_active = false;
BIS_fnc_drawMinefields_refresh = false;
}] call BIS_fnc_addStackedEventHandler;

Add this to your mission and it should prevent the loop from firing each frame.

This should help some of you guys out until this is fixed properly!