This has been already fixed in version v1.55.133505 and above of DEV branch and should appear in the next stable release.

TASK and LOCATION both support only STRING argument:

"b:TASK getvariable STRING"
"b:LOCATION getvariable STRING"

This is why both throw error when ARRAY is passed. Both variants are also pretty old and alt syntax was simply never implemented. I resolved this ticket because according to its content, this is not a bug. But feel free to make a feature request to extend functionality.

This is not a bug but rather a copy paste mistake on wiki. You can always check supported syntax either using in game help F1 or by looking it up with supportInfo command.

addMagazineTurret command will be extended to take additional argument with ammo count, this is in the works since last year. However removeMagazineAmmoCount is not going to work as you suggested, as this will most definitely require magazine id to identify the specific magazine, since more than one magazine can have the same amount of ammo.

<vehicle> addMagazineTurret [<magazine>, <turretpath>, <ammocount>]
Should be added in 1.55.133817

This is what BIKI says regarding your error:

0xC000012F - STATUS_INVALID_IMAGE_NOT_MZ
These errors are raised when the EXE or DLLs, either in the game folder or in the system folders, are corrupted. Possible solutions:

Verify the integrity of the game cache using Steam.
Re-install DirectX.
Uninstall the Visual C++ 2013 Redistributable package (x86 version), restart your computer and install the package again (do not use the Repair function).
Run the Windows System File Check tool to repair corrupted system files.
To identify the precise DLL that is causing an issue, download a 32-bit version of the Microsoft Dependency Walker and open arma3.exe with it. The corrupted library will be listed marked in the list.

More info is here: https://community.bistudio.com/wiki/Arma_3_Unusual_process_exit#0xC000012F_-_STATUS_INVALID_IMAGE_NOT_MZ

Sorry to ask, is this ACE3 related?

Fixed in today's dev.

Should be fixed in tomorrow's dev, please check

addMagazines is the wrong command to be used on ammo boxes. Use addMagazineCargoGlobal instead

Have you tried spawning object in away location, then setting desired object orientation there before moving it to the exact position?

The custom JIP ID should be returned by the remoteExec/Call commands just as well in tomorrow DEV build, please check and report back.

I agree this is not entirely polished and could do with a few tweaks. However when you provide your own string for JIP ID, this is basically your unique id, which you can use later to manage JIP queue, so returning it, would be just copying input to output (not the worst idea actually). Otherwise you can request random one, which you can then store and use to manage JIP queue.

As per description on https://community.bistudio.com/wiki/remoteExec

"Return Value: ... Otherwise this is an unique JIP ID..."

and

"JIP (Optional): ... If true, function generates a unique ID...."

Basically, JIP ID returned only when JIP param is true. TBH I don't remember it returning JIP string under any other condition.

In today's DEV nearestbuilding correctly returned the house shukari posted. Any other reproes where nearestbuilding fails?

Confirmed, though nearestbuilding detects something else. nearestobject [player, "house"] seems to detect the correct house.

nearestTerrainObjects [position player, ["house"], 50]

seems to work as well

"Will there be a fix to get those houses aimed with cursortarget?"

There will be a new scripting command "cursorObject" that should take care of this as "cursorTarget" is not quite suitable for this kind of detection by design.

Works on houses created by script, have you got coordinates to where on the map you are testing it?

As this is Guerrilla Offroad, sometimes it might not have driver door :) This is by design, not a bug.

There are 3 templates for IF command now

IF BOOL THEN CODE (ELSE CODE)
IF BOOL THEN ARRAY and
IF BOOL THROW ANYTHING

compiler must find a match in templates for your expression otherwise it throws an error. It reads the code forward but it needs to know all the arguments like for example is it a CODE after THEN? Because you can use variable, doesnt have to be block with curly brackets.

if (true) then BIS_fnc_whatever

BIS_fnc_whatever needs to be evaluated. So when you use throw like this, its argument needs to be evaluated just as well.

Also let me remind you that original throw functionality has not changed a bit, you can still

if (false) then {throw (123 call abc)}

and abc will never execute.

PS just to make sure everyone understands this

if (false) throw <whatever>

throw above does not throw anything, command never executes.

"You are saying its expected behaviour for performance reasons ???"

It is just normal behaviour.

abc =
{
systemchat str _this;
{}
};

if (false) then (123 call abc);

Expression after then is still evaluated and function is called. This is normal.

I'm afraid this is not a bug but expected behaviour. You pass an argument to throw command which is a result of the function call. With any other command the compiler will behave in the same way, it will first call the function to obtain return value and only then use the value as the argument for the command.

You probably did not expect the function to be executed at all, but there is no reason why it shouldn't, it is inside try {} scope that has been entered. In other cases when you have throw inside then {} scope, it is different because then {} scope is only entered when "if" before that evaluates to true. And since it is false in your example it never has a chance.

Compare this to getVariable with devault value. Same thing would happen, if default value is a function call, it will first call the function.

a = 10;
b = missionNamespace getVariable ["a", 123 call abc];

the abc function will always run, regardless if a is or isn't defined. I hope this clears it up and sorry for the time you have wasted on changing.

Please try "cursorObject" command, which should be available in tomorrow's DEV

Please try "cursorObject" command, which should be available in tomorrow's DEV

It is actually a bug that turned into a feature. This will remain unlimited for scripted use while the means of detecting of available space will be extended.

Fixed in today's dev.

The way the current compiler works, it is not possible to for example

a || b

to stop evaluation if a is true, but

a || {b}

scope with b will be ignored, unless a is false. Ideally it would have benefited to have lazy eval all the time, unfortunately not possible with current compiler.

Old ticket, must have been fixed awhile ago, if not, dev branch has the function rewritten completely.

I suppose you can override tent/sleeping bag assembly with https://community.bistudio.com/wiki/inGameUISetEventHandler

Just checked, unfortunately the fix for some reason didn't make it to DEV. Probably after Christmas.

The fix should have beed added to dev branch awhile ago, could you confirm it solved the problem?

Should be fixed from 1.57.134270

Please see updated https://community.bistudio.com/wiki/ctrlMapCursor for the correct usage.

Should be fixed from 1.57.134270

select has been extended awhile ago, apply should be added in tomorrow's dev.

Seems resolved. Please request reopening if this is not the case.

Should be fixed on dev, did it work?

Please try "cursorObject" command instead, which should be available tomorrow.

Should be fixed from 1.57.134270

One month no reply - resolving then

There is clientOwner command available now that should return client id regardless of player existence on the client. Also both onPlayerConnected and onPlayerDisconnected have _owner information for the joining/leaving client.

Does this resolve the issue?

This should be fixed in today's dev, could anyone confirm?

Fixed in today's DEV

Backpack created in editor returns reference to actual backpack container inside its parent weaponholder. In order to get the position of the weaponholder use objectParent

getpos objectParent myPack

reports correct position https://community.bistudio.com/wiki/objectParent

Does this resolve this issue for you?

fixed, somewhere in between 2013-2016

You can use lineIntersectsSurfaces instead, which can detect units