This should be resolved for a while, could you please give it a try and re-open this issue if that is not the case?
Thanks!

I am able to complete the main objective by destroying the truck at the first enemy compound then destroying the lighthouse. Would you be able to give it a try and re-open if that is not the case?
Thanks!

I am unable to repro this issue both on internal and default steam branch. Would you be able to give it another go by reverting campaign to this mission and report back?
Thanks!

While the syntax is not great, it's something we will have to live with.

You can also use

Should be fixed for a while. Thank you.

Added a while ago.

In T116823#1443858, @Xeno wrote:

And as you can see, there are players listed even more than once in the unit list on the left!

The mission uses BI dynamic groups and BI spectating is only used for the admin (as admin spectating)

Fixed and should hit Dev branch soon. Thank you for the report.

Fixed, should arrive at the Dev Branch tomorrow.

If non-leader player in non-registered group tries to create a group, it will now be correctly create, but player is moved out of the old, non-registered group (because he is not the leader of current group).

Thanks.

This issue should have been fixed a while ago. Please re-open in case you experience the same issue. Thank you.

Thanks, fix will be deployed onto dev branch today.

Good to hear you were able to fix the issue on your own. Thanks.

Fixed and should arrive at Dev Branch today or tomorrow.
See (https://community.bistudio.com/wiki/Dynamic_Groups) for more info.
Thanks for the report.

Please, give it a go. We've introduced a new command "setGroupIdGlobal" which set's the id of a group over the network and Dynamic Groups is now using it.

Done a while ago.

Thanks for the feedback.
We are currently testing the new Download Intel mechanics internally, expect it it to reach Dev Branch very soon. ;)

We've introduced a new Spectator Mode with Nexus update.
https://community.bistudio.com/wiki/EG_Spectator_Mode

For further suggestions please open a new ticket, if necessary.
Thanks. ;)

Seems problem was community addon/mod.
Closing here.

Please note that OnEachFrame does not stack by itself, is instead overridden.

onEachFrame { hint "Blue"; };
onEachFrame { hint "Red"; };

Would hint Red only. Can you try on a empty/clean mission in editor? Maybe the problem is that your OnEachFrame is being overridden.

Also, if you would like to stack it, see: https://community.bistudio.com/wiki/BIS_fnc_addStackedEventHandler

Hello.

Could you please provide simple repro steps?
Thank you.

@cykuan I am unable to repro. Please, if you are still affected by that issue please create a separate ticket.
Thank you.

Fixed, expect it on Dev Branch next week.
Your example code is problematic because it tries to spawn core modules, try instead:

MyFunc =
{

hintSilent str [time, _this];
[format ["MyFunc_%1", time], compile format ["%1 call MyFunc", time], 1] call BIS_fnc_runLater;

};
[time] call MyFunc;

And it should run forever.
The problem was automatic termination of BIS_fnc_loop in case there were no more items to execute.
Please confirm whether it is solved.
Thank you.

@sms Is this deemed fixed? Thank you.

Unable to reproduce, please re-open if issue still persists. Thank you.

Duplicate of http://feedback.arma3.com/view.php?id=21135

Duplicate of http://feedback.arma3.com/view.php?id=21135

Thank you for reporting back.
Closing as resolved.

Fixed at revision 73434

This issue should have been fixed a while ago, please re-open if you experience it again. Thank you.

@Deathlyrage Can you please provide repro steps? I'm unable to reproduce this issue when executing the command only where a unit is local, I see no duplication of magazines.

You are using wrong syntax, should be:
addCamShake [100,10,1];

Please confirm that it works.
Thank you.

Thank you for letting us know that this issue was fixed.
If you experience this again, feel free to re-open.
Thank you.

Improved version, as suggested in first post is already on development branch, setting as resolved, please assign back to me if something else comes up.

Thank you,
Nelson Duarte

Closing as resolved, feel free to re-open if something else comes up.
Thank you.

Hi and thank you for the feedback, really appreciated!

"Why in the bottom is there a need to have a “DELETE_ME_PLEASE” string?"

• This is because the element must be as unique as possible, your example would not work, because it would remove all NULL objects from the array. For example:

_array = [5, objnull, "text"];
_shuffled = _array call BIS_fnc_arrayShuffle;
_shuffled; // Will be ["text", 5]

"New Shuffle Inline with the Debug Console"

• Code executed within the console is run in a non scheduled environment (code is run on one single frame, no matter what), while within a script called with execVM, execFSM, spawn, will be caught and limited by the script scheduler. So when you want to test performance of a script/function, it MUST be done in non scheduled env.

So I did a few tests and the results are (for a 10 element array, from console):

Old BIS_fnc_arrayShuffle - 0.212201 ms
New BIS_fnc_arrayShuffle - 0.161798 ms
Your Array Shuffle suggestion - 0.168295 ms

The only difference between Old and New BIS_fnc_arrayShuffle is that instead of Set, it now uses push_back, as you suggested.

Attaching files in case you would like to perform some benchmarks yourself and give back some more feedback!

BIS_fnc_arrayShuffle > Old function
BIS_fnc_arrayShuffle2 > New version using push_back
BIS_fnc_arrayShuffle3 > Your version

Thanks a lot,
Nelson Duarte

Like others have said, you should use OnEachFrame (https://community.bistudio.com/wiki/onEachFrame) or Draw3D (https://community.bistudio.com/wiki/addMissionEventHandler), because the drawing of the the icons/lines needs to be done every frame.

Hi and thank you for taking the time to report this.
I found that the problem was the debriefing texts were switched, because there is also a timeout for you to seize the enemy area, after destroying the tank.

The current timeout is 360 seconds to seize the enemy position, you were taking more then this time and the wrong ending (bug) was being shown.

I fixed this particular issue, expect it on the development branch at the beginning of the next week.

Thank you.

Fixed in current development branch.
Thank you for the feedback.

Hi and thanks for the feedback.

The small warning conversation refers to the south entrance of the ruins, so when you approach the ruins, you should enter them from the South side, relative to them.

James as set up mines on the North side of the ruins.

Thank you,
Nelson Duarte

Hi and thanks for the suggestion.

We have no design plan to make such items interactive because I feel it would bring unbalanced sand box behavior. A player would be confused if he could interact with items in this particular scenario and not in others.

I hope you understand,
Nelson Duarte

Hi,

I was unable to reproduce this issue on Stable Branch, tried 3 times and mission always progressed fine.

I wonder if your team was in combat mode, when they got stuck. I ask this because one of the conditions for each objective is that the team in no longer in combat mode.
Were you using any mods? Especially Ai mods, that could influence the group visibility/fighting abilities.

Yes, because when you have a weapon, looking up/down changes torso rotation, not the head rotation.
If you would do it while unarmed, it will work, because looking up/down in that situation changes the head rotation, not torso rotation.

You have to use camera and not the eyes of a unit to achieve what you want.

EyeDirection command is returning correct values, because EyePos/EyeDirection is a socket attached to the model's head that has a certain location and rotation. The head rotation is more limited then the player's camera view, meaning, the player can actually turn his view further then his head in the model will.

EyeDirection/EyePos is limited by this.
A easy way to see this in effect is to switch to 3th person camera and using free head movement turn around to the sides, you will see your head reaching it's rotation limit although, you can still rotate the camera a little further.

Hi,

Please note that the crosshair now gives you an accurate representation of where you are aiming at, when you see the crosshair change it's position, it is actually showing you where it is actually pointing at, and where the bullet will hit.

Hi,

This is already possible, when placing the in between waypoint, make sure you set it's order correctly, see comment above.

Thank you.

Can you, please, describe a reliable repro?

Thank you.

Hi, thanks for the feedback.

Why do you need to sink objects into ground?

I'm confused, because CfgFunctions is already implemented in Arma 3 since Alpha. Can you elaborate?

Why not use CfgFunctions instead? http://community.bistudio.com/wiki/Functions_Library_2.0

Duplicate of #0009937, that should now be fixed.

Such option already can be found in Options > Game > Head Bob.

This is by design, for long range.

Use visiblePosition function instead.

Use visiblePosition function instead.

What you describe is not a bug, please re-check your condition:

this && local player

Where "this" is the trigger properties condition.

It's strange that in Take On Helicopters the feet actually moved. Would be nice to have it in Arma 3 as well.

With nexus update, we've introduced a new Spectator Mode.
https://community.bistudio.com/wiki/EG_Spectator_Mode