Fixed in release version.

We reversed the zooming controls to be consistent with widely known on-line maps by Google, Bing and others. I understand that it can be initially confusing, but there should be no problem with getting used to it.

This problem is connected to core multiplayer structure and to fix it, a more serious revision would be required. I'm afraid it's not within scope of this project to do anything about it; however, we'd definitely want to resolve it in the future.

Fixed it this this morning, sorry for not marking it as resolved before.

Will be fixed in the next dev build update.

Fixed in the next dev build.

Should be fixed now

Switching to other units after death should now be possible again.

1. The sectors are not held when there are no allied troops present

Fixed

2. The "Sector Captured" boxes do not display correctly, only the background (no text) shows

Caused by issue in task notifications, fixed.

3. I did once get a Generic Error in Expression on line 26 on a related BIS function sqf, however I cannot reproduce this nor remember which exact one it was.

Should be fixed as well

Fixed some time ago

The subtitle relates to status between competing defenders - BLUFOR and Independent. When BLUFOR prevailed, it means they had higher score than Independent (although both failed to win the mission itself).

Did BLUFOR have higher score in the end?

Should be fixed in the next dev build.

Number of available game types is limited intentionally to prevent inventing new, highly customized modes. That would go against what types are for, and that is easy and understandable categorization for players.

List of available types was recently updated, the new options might suit your mission better than the old types (which remained unchanged since 2001):
http://community.bistudio.com/wiki/Multiplayer_Game_Types

preInit functions were accidentally executed using spawn, not call. This lead to delay in more extensive functions.

Script loading order is now:

1. Functions with 'recompile' param set to 1 are recompiled
2. Functions with 'preInit' param set to 1 are called
3. Wait until mission is initialized
4. If the machine is client, it waits until server init was finished
5. Multiplayer framework is initialized
6. Modules are initialized (running their own scripts, functions just wait until those scripts are done)
7. Mission scripts "initServer.sqf", "initPlayerServer.sqf" and "initPlayerLocal.sqf" are spawned
8. Functions with 'postInit' param set to 1 are called

The changes should appear in the next dev branch

http://community.bistudio.com/wiki/profileName ;)

In your example, what's in _id variable?

I suggest to ask in the official forum (http://forums.bistudio.com/forumdisplay.php?162-ARMA-3-BETA-MISSION-EDITING-amp-SCRIPTING), maybe somebody encountered the same scripting problem you have before.

Closing here, BIS_fnc_MP works as intended.

Markers should be already synced, programmers recently fixed the problem. I quickly tested it in the Dev build and creating a marker on hosted server will indeed sync it to all JIPped clients.

Does the problem occur when you host a mission? On dedicated server? Are you creating the marker on server or on client? If you were trying it the default build, could you please check it in the Dev one?

http://community.bistudio.com/wiki/getHitPointDamage

Good job finding the command. When searching for commands, I recommend to always go first to the complete list of them: http://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3

Fixed in dev build.

Duplicate of 10922

'Guer' is not a scripting command and it has never been. Therefore it's no surprise it does not return anything. See list of Arma 3 commands, wou won't find it there: http://community.bistudio.com/wiki/Category:Scripting_Commands_Arma_3

'Resistance' and 'Independent' are only valid commands returning the green side.

Please verify all magazine name lengths as well.

Hotfixed in today's dev branch. Could you please verify, I'm not 100% sure about the current solution.

I could send you either the files pertaining to just respawn or the PBO without the server security files.

No need, I downloaded SaMatra's Wasteland and will investigate the problem on it. Thanks for the offer.

BTW: To explain the problem - In Beta, we added automatic mission end when all players dies in a mission with limited respawn slots (GROUP or SIDE respawn). However, it seems it's being triggered also in missions with BASE respawns, which is incorrect.

And would you know in which missions it was happening?

It's a problem in newly added respawn system. Could you please tell me in what mission(s) it's happening, so I can debug it?

Crashing is fixed.

As for setting it up - see the module description (click on "Show info" when editing the module) and unpacked Defend Kamino mission.

More info coming soon.

Will be fixed in today's dev build.

Already fixed in default Beta build

I'm afraid your code is incorrect:
["TaskSucceeded", ["Job done"]] call BIS_fnc_showNotification;

Notification shows the task title as returned by taskDescription command (http://community.bistudio.com/wiki/taskDescription). However, the title is 2nd param in the returned param, not the 1st.

To mimic this behavior, push your text to the 2nd place:
["TaskSucceeded", ["", "Job done"]] call BIS_fnc_showNotification;

Note: I recommend to use task functions (BIS_fnc_taskCreate and others in 'Tasks' category of the Functions viewer) or task modules which handle notifications automatically.

The intention of Functions Library is to make all functions available for everyone, similar to how scripting commands are openly ready to use.

If you have a function which doesn't work independently, mention it in the header, ideally explaining what else has to be running in order for the function to work. Or, in extreme cases, you can remove it from the functions library and compile it separately.

Please add support for loading images from the local directory.

If you wish to change the color, go to Options > Game > Colors and adjust the "Active Elements" color yourself ;)

executing stuff, not necessarily a support.

I'm afraid that using Supports menu for something else than supports is not intended behavior. If you want to execute a code, use a radio activated trigger.

I'm sorry, but only way how to get rid of scripting errors is to fix them, hiding them is not a policy we'd like to promote.

• If the error is present in an official content, create a new issue in this tracker and mention basic reproduction steps leading to the error (which mission, how to play it, etc.)

• If the problem is in your own mission, it's your responsibility to locate and fix it. The text should help you locate which part of code is broken.

• If the error occurs in community content, its author is to blame. Contact him and let him know about it. Mission author is mentioned in the loading screen; additionally, server admin(s) might provide further details.

I assume this is your case, but I'm afraid there's no other way than to fix the bug.

I'm afraid dragging is not part of the basic game and the mission was probably running some custom scripts. I'm afraid you'll have to contact its author and let him/her know about the issue.

Disabled for security reasons.

Note added to community wiki (http://community.bistudio.com/wiki/copyToClipboard)

Fixed in default Beta build

Communication menu is now handled differently, please follow these instructions:
http://community.bistudio.com/wiki/Arma_3_Communication_Menu

Should be fixed in today's DEV build.

camera.sqs restored for the backward compatibility.

Please call the camera using following method, as the .sqs script is likely to be removed again in the future:

player call BIS_fnc_cameraOld;

Script calling removed, the error should no longer be present.

Already fixed in the default Beta build

Solved itself (the best kind of issue)

When does this happen? You mention respawn - if it happens when player is respawning, please mention in what mission it's happening or what kind of respawn is used.

Recently redesigned Functions viewer should solve this issue.

Obsolete models are no longer used by BIS_fnc_sandstorm

I'm afraid it never worked that way.

{_x=false} forEach [var1, var2, var3, var4, var5, var6, var7,...]

The array doesn't contain variable references, but their values. For engine, it may look like

{_x=false} forEach [true, true, false, true, false, true, true,...]

An you cannot use false=false statement.

The solution is simple. Create an array containing variable names as strings:
{
missionNameSpace setVariable [_x,false];
} forEach ["var1", "var2", "var3", "var4", "var5", "var6", "var7",...]

but it could be expanded

Expanded how? What do you miss in the current color corrections?
I'm afraid your message is rather unclear.

We're planning the similar functionality for official MP missions, will make sure it's made into a function.

I'm afraid your script is incorrect. Variable "RE" is declared only on server, but you're trying to call it also on client where it's not present.

Following solution should work correctly:
[{hint "This text should be shown to every player on the DS!";},"BIS_fnc_spawn",true,true] spawn BIS_fnc_MP;

However, I strongly recommend not to send code over network and rather store it in a script, which you would then call remotely using following expression:
["myScript.sqf","BIS_fnc_execVM",true,true] spawn BIS_fnc_MP;

P.S. There's actually error message displayed, but you cannot see it by default. Go to Functions Viewer and click on "Show Errors" button in bottom right corner to have errors shown on screen.

But still, is it intentional to == not work like this

It is, Deadfast's example is the only way how to ask for boolean state.

Sound removed in the DEV branch. Will be later replaced by a new one.

As mentioned, debriefings are now handled differently, with the new way being explained in http://community.bistudio.com/wiki/Debriefing

Nothing changed with ratings set in init fields, respawning preservers the negative value as intended.
Unable to reproduce, the attached Podank_AgiaMarinaDM_Small mission works fine.

We actually investigated this during Take On Helicopters development, and we found out it's not possible without overhauling large part of the engine. I'm afraid that user interface and 3D rendering are completely separate and cannot be easily combined.

Respawn systems are being revised, I'll make sure this is taken into consideration.

Newly introduced module "Vehicle Respawn" and "RespawnPosition" in "Multiplayer" category might be what you're searching for. They give you ability to create a respawn position only for naval vehicles (i.e., boats and submarines) and then mark them as respawnable.

BIS_fnc_endMission calls mission end with closing shot effects, it does not define effects for a trigger ending.

See http://community.bistudio.com/wiki/BIS_fnc_endMission for more info.

Markers filtered, only hand-drawn markers are now available (the same as in Arma 2).

Black dot is now default marker.

The commands already exist:
http://community.bistudio.com/wiki/markerDir
http://community.bistudio.com/wiki/setMarkerDir
http://community.bistudio.com/wiki/setMarkerDirLocal
http://community.bistudio.com/wiki/isPlayer

We don't want to simply port everything from VBS, as many functions wouldn't make sense in Arma. If you have any specific requests, please create a request for every each of them with explaining why you want them.

The issue was that "Set destination" module was called before "Create" one, and its effect was replaced. The modules are now executed in the correct order - first "Create", then "Set" variants (e.g., destination, description, ...).

Additionally, it's possible to set destination and state right in the "Create" module.

The command works as intended.

Intended behavior, use switchableUnits in singleplayer:
http://community.bistudio.com/wiki/switchableUnits

Combine them together to make sure returned array is both SP and MP combaptible:
(switchableUnits + playableUnits)

Confirmation box now appears upon clicking on "RESPAWN" button.

Players who JIP won't receive module synchronization, and are therefore invisible for the module.

However, "Create Task" module options were expanded to allow adding the task not only to synced units or their groups, but also to sides of synced units or even to all playable units.

So if you sync the module with any BLUFOR unit (and ideally not player, to make sure the unit is always there), the task will be added to all BLUFOR players.

The same option is available in the function BIS_fnc_taskCreate and in the core task function, BIS_fnc_setTask.

Descriptions were completely removed in the latest Functions Viewer redesign. Function headers are now the primary source of descriptions.

there are scripts to do it but they usually cause more problems than they help

Not when yu know how to use them. I'm afraid the trigger/waypoint camera effects are not going to be restored and scripted solution is the only way.

Side colors can now be customized in OPTIONS > GAME > COLORS > Map

While we have no plans to change the defaults (with 5 available sides, I'm afraid there are always 2 which are very similar, either for colorblind or for players with unaffected vision), the new options should at least give you ability to tailor the colors for yourself.

Could you please confirm if waypoint color remains unchanged even after the game restart? There's supposed to be a prompt message advising you to restart, but it's missing due to a bug (which we're fixing now ;)

Fixed in beta thanks to the customizable HUD layout

Interface layout settings as introduced in Take On Helicopters are going to be accessible soon, and GPS will be part of it.