Hi, the issue is in the test object itself. Code that throws the error comes from init event handler which doesn't allow code suspension and the code is called, so it doesn't changes and still doesn't allow code suspension.

Only entities with AIBrain can hold information about synchronization. From this presumption comes the limitation - you cannot connect 2 objects without AIBrain and that's also why in your case synchronizedObjects ai_unit works, but synchronizedObjects building does not. Checking the https://community.bistudio.com/wiki/synchronizedObjects there is clearly stated unit not object.

You are right. You need to change the content of the exec field to make the LOCAL EXEC recompile the code. But is it a real problem? Do you really need to get informed that there is still compilation error if you didn't modify the content of the exec field and just spam the button?

Hi, there are several issues with your example:

1. If you have the pause menu opened, then time is not running, so the execution will pause on the sleep command. You need to use uiSleep instead.
2. Because of the typo in the command the syntax is wrong as game understands "sstemchat" is a global variable and as the result the code doesn't compile and you get an error.

Please try using "NONE" instead of "" and also please provide the revision of exe you are using.

The spawner module reads all needed data from config when it is initialized. If you later change the input variables, you will break it as the modified data will not be compatible with the data retrieved from configs.

Hi. The initial comment / bug report is not valid. You are supplying wrong input to setHit command.

Update: Command should already be fixed in dev. exe. Next version of retail exe (Tac-Ops DLC release) should have it fixed.

Hi, what's the revision of the exe, you are using? I cannot reproduce the issue, it works as described on the community wiki.

Hi there. Actions cannot be added to memory points by script not can they be added via object config.

Arrays are referenced as pointers. If you do _array2 = _array1; both variables will contain reference to the same array. That's why if you change _array1 you will see change in _array2 and vice versa.

The behavior is correct, examples are flawed. The name of returned variable is not important, problem is in how you work with script/variable scopes.

Hi there. Thanks for the repro mission, I checked it. The script commands you are using there provide basic functionality over simpleTasks. It is absolutely OK, if you use them directly. This way you get full control over your tasks, but also full responsibility over everything else, like is synchronization in MP or the above mentioned automated handling of child tasks according parent task state.

Thanks for the feedback. I will check the issue with onPlayerKilled.sqf and I look at the JIP issue. Thanks for the repro mission.

Fixed in functions_f.ebo rev. 102287 or higher.

Thanks for the report. The fix will be published to dev. build today.

You are welcome.

There is no initialization needed. If you call the bis_fnc_taskCreate on server with proper attributes, the task frameworks should create the individual (local) task on every valid client.

In your example, you call it with owner being true, which means the task should be created on every client.

To ensure the bis_fnc_taskCreate is executed from server, try for example put it into the missions init.sqf and frame it into the isServer condition:

if (isServer) then
{

[...] call bis_fnc_taskCreate;

};

Thanks for the info provided. I think I find where the issue is. Please check what you are sending into the function as text on the marker. The format is [_taskDescriptionText,_taskNameText,_taskMarkerText]. Focus on the last element in the array which is the text that is displayed on the task marker in 3D.

According to what you say "_position_mark would equal an actual position such as getposatl _intelobject" you are sending into the function ARRAY with task position instead of STRING that is expected.

Please change the 3rd parameter in the task text array (replace _position_mark with some string, like "INTEL IS HERE!") and please let me know if it works.

Note: _array =+ _array is not a typo, the plus sign is a copy operator; see https://community.bistudio.com/wiki/Operators#Array_Operators for more info.

Please provide the input parameters that you use in the bis_fnc_taskCreate call. Seems like you are sending wrong parameters into the function or the function doesn't handle the input properly.

[true,[_tsk],[_taskdesc,_tasktopic,_position_mark],_position_mark,1,2,true,"Search"] call BIS_fnc_taskCreate;

I am especially interested about the:

• _taskdesc
• _tasktopic
• _position_mark

But if you can provide all input parameters, we will be able to test it. The local variables without values do not tell us much.

Please check what you send into the command and the difference (especially in data types and format) between this:

[
true,
["TestTask"],
["TestTask Desc","TestTask Name","TestTask Marker"],
getPos player,
1,
2,
true,
"Search"
]
call BIS_fnc_taskCreate;

The reported script error (File A3\functions_f\MP\fn_MP.sqf, line 46) is now fixed. Please wait for it to be applied.

The issue with bis_fnc_mp failing if more then 10 objects/players are being used is under investigation. Seems like an issue in remoteExec/remoteExecCall.

Sorry for your troubles.

Are you still experiencing this issue?

When script command has a wrong input it throws an error and halts further code execution. That's a normal behavior.

In case of param and params commands we could make an exception to use default value and continue code execution if the default value is provided.

If it would be a new command we probably wouldn't go this way and halt the execution, like it is done anywhere else where the wrong input occurs. Because of the backward compatibility (with bis_fnc_param) we will change the behavior of those 2 commands so they will use the default value even if the input type is wrong.

But seriously, you should know what the command is inspecting and send correct data type there.

Thanks for the feedback, I will check it out.

EDIT: Fixed for the next build. The system now correctly displays the map markers for tasks with "AUTOASSIGNED" state.

Thanks for the report. We will look at it.

Fixed.

Issue is fixed.

Hi guys. Thanks for the report. Issue should be fixed in the dev branch tomorrow.

• Animation set GUARD removed from BIS_fnc_ambientAnimCombat.
• List of available animation sets updated; GUARD removed, WATCH added.

You are welcome. :)

Hi Scott. I see, the "GUARD" is set to remove the weapon. It was originally meant to support the weapon and therefore it was allowed to be used in BIS_fnc_ambientAnimCombat.

But later I noticed that there is some serious clipping between the arms and the weapon. So I was forced to set it to remove the weapon and I forgot to disable it for the BIS_fnc_ambientAnimCombat.

I cannot allow the weapon for "GUARD" as it is used in campaign - it would cause clipping there.

Please use different animation set. Mose safe is "STAND". You can also try "WATCH" (="WATCH1") or "WATCH2", if you need more variations.

Function BIS_fnc_ambientAnimCombat requires the unit to have a rifle weapon equipped and selected to work properly. When unit gets into combat state, actually acquires an enemy target within 300m or its release condition evaluates to true, the unit will try to interpolate to standing animation with rifle raised ("AmovPercMstpSrasWrflDnon").

If you have the units with rifle weapons and they are switching to handguns after interpolating to "AmovPercMstpSrasWrflDnon", try to remove handguns. Might be caused by unit Ai preferring handgun over rifle.

Fixed.

@Changing loadout after mission briefing:

• loadout is forced to default loadout if you use the quick start from the strategic map. If you do not use the strategic map and interact with the "mission giver", after the mission briefing cutscene, you are sent to the armory, where you get the required gear. The gear that matches the criteria is kept.

@Transition between base and mission:

• this is also fixed. No gear should be missing, although it might be moved between containers (vest, uniform or backpack).

Hi there. Looks like a general issue bugging several last releases of the exe.

The gear you (and every other unit with persistent gear) get on the hub is not retrieved correctly at the start of mission with briefing.

We are looking into it right now and will try to fix it asap.

Thanks for the report guys.

All fixed.

1. What build number of are you playing?
2. Dev branch or stable?

Sorry, my bad. I missed the line about happening only without squad. It is fixed now. You find the fix probably in next dev. branch build.

Hello there. We have revised the transition of items between hubs and side missions in 1.22 and expanded on that in 1.24.

We fixed all issues related to item transition we were aware of and added some new features, like tracking cargo of multiple vehicles (and backpacks stored there) returning from skirmish.

We made series of testing to ensure, all the fixes and improvements are working as intended. I have just tested going from Gori to side mission in the offroad and I cannot see any issue (rev. 1.23.125365).

Be aware that your side mission squad in Adapt take the stuff from the equipment pool too. When they arrive back, they return everything they have in their possession and is in their vehicle(s).

The tricky part is that the gear your squad is going to take to side mission is NOT removed from the armory until the hub mission ends. We didn't want to deny player to take HIS/HER favorite weapon just because one of his side mission men took the only 1 piece.

Btw. this is same to campaign missions in episode Adapt.

If you want to try it isolated, try it in episode Survive, where the is only player. Use the quad bike. And let us know, what you find.

Cannot reproduce the issue under 1.50.

Hi there. The problem is the issue is actually very hard to reproduce. Our QA is currently looking into it.

The default behavior of "Replay" in campaign is to start the mission and return back to the mission selection menu when the mission is finished.

If you want to play again a mission and then continue the campaign from that mission further, you should use "Revert".

Already fixed.

Hi guys, I fixed the bug on Monday 5.8.2013, described in the former report. Function should now work properly.

Vasilyevich, regarding your example, you are trying to feed a wrong input parameter into the function, the animset "REPAIR_VEH_KNEEL". Check the function header for list of the valid input params.

FYI: It is generally good practice to check for the wrong input, and we usualy do. So I suggest to check the *.rpt files for warnings nad errors prior of reporting that something is broken. You might find some useful info there.