BIS_fnc_spawnGroup could do with a change along with this addition.
Currently, if the function spawns a vehicle as part of the group( e.g a CfgGroups entry ), the group is passed to BIS_fnc_spawnVehicle where addVehicle is used on the group, but at the end of BIS_fnc_spawnGroup an additional group is created so as to reorder the units by rank( previous group is deleted ) but the vehicles are not transferred.

I was going to ask a similar question.
Currently when in Eden triggers are shown as a volume and I presume this feature is by scaling primitive models as found in \a3\3den\objects\ where you can see...
ellipse.p3d
ellipselimited.p3d
rectangle.p3d
rectanglelimited.p3d
etc

I can confirm that this is a PITA.
You use to be able to, as long as you have not restarted the client i.e been jumping from editing to testing on a loopback server and back to editing, be able to start a new editor session and press Open to automatically open the last mission you were editing when you had previously sorted the open mission dialog by date (or any sort option).
As described above this no longer happens. Although the top sorted entry is highlighted if you press Open it will open the top entry as if the missions are NOT sorted (default by name ascending).
You need to specifically click on the, already highlighted, entry to open the correct mission.

Still broken as of v1.84.
It also does not output the new base class of RscControlsTable that was added in v1.84.

The strange thing is, is that the mine detector is available under misc items when viewing a container (uniform, vest, backpack) when in the full arsenal from Arma's main menu "Tutorials > Virtual Arsenal".

Since 1.68 the 'Use Default Action" can now be used on the same button as your primary weapon, to use the currently selected action. Fixing the problem that 1.66 introduced, where "Use Selected Action" would stop you from being able to fire your weapon, as it now brings up the action menu if currently hidden.

You can already bypass the BI damage handler whilst unconscious if you wish see this thread.

An allControlsGroupControls would be extremely helpful seeing as currently allControls is only for displays.

Same problem with the singular command.
_unit = get3denselected "object" select 0; done = _unit set3DENAttribute ["Init","hint 'spammin ur hint'"];

(get3DENSelected "object") select 0 get3DENAttribute "Init";

Returns
[""hint 'spammin ur hint'""]

Update: RC build ["Arma 3","Arma3",156,134594,"Stable",false,"Windows"]
This is a problem with any Attribute class that is of type STRING.
Tried..
Name
Description
Rank

All either, fail to make any change or fill the attribute with a double quoted string, which then cause errors when you try to open the attributes window and then close it as the values are illegal when evaluated.

Yep. Excellent, just put it through a little testing using the mission attached to the ticket and remotely removing from JIP que from debugConsole on client. All seems good. Thank you.

Aye could do with changing.
This..
_veh = createVehicle ["B_MRAP_01_F", _somePos, [], 0, "CAN_COLLIDE"];
_veh setvariable ["JIP_ID", [_veh] remoteExec ["fnc_doSomething",0,format["veh_%1",netid _veh]]];

Makes a whole lot more sense to me than having to...
_veh = createVehicle ["B_MRAP_01_F", _somePos, [], 0, "CAN_COLLIDE"];
_JIP_ID = format["veh_%1",netid _veh];
_nul = [_veh] remoteExec ["fnc_doSomething",0,_JIP_ID];
_veh setVariable ["JIP_ID", _JIP_ID];

Been a while since i test it last but i could of sworn it originally did.

Full quote..
Nil in case of error. String otherwise. If JIP is not requested this is an empty string. Otherwise this is an unique JIP ID.

No error so its not Nil.
String otherwise. <<<<<
If JIP is not requested this is an empty string. << i am requseting JIP
Otherwise this is an unique JIP ID. <<<< Contradicts first statement, but it is unique im supplying it ??

Quote from remote execution wiki page.
The JIP id is a unique key under which the JIP MP message is being stored in the JIP queue on the server. When you set isPersistent flag to true, the JIP id is auto-generated on the machine the remote execution was initiated. If you set the isPersistent flag to specific string, that string is considered to be the JIP id.
The auto-generated JIP is always unique. If the JIP is manually supplied, the content author needs to make sure it is unique, otherwise he/she will overwrite another MP msg that is currently stored in the queue under the JIP id.

If the JIP is manually supplied, the content author needs to make sure it is unique <<< Again is unique as i supplied it

Its crazy idea if only a generated ID is returned. Makes a whole lot more sense to return ANY ID if JIP is requested so you can look after your own que and delete any that become unneeded.

Someone forgot to clean up the new variables in BIS_fnc_deleteTask.
The simpleTask gets deleted and the player variables get cleaned up but the new variable @task.# 0-11 are not cleaned up which is what taskExists looks for well specifically @task.0 but surely they should all be set to nil else over the course of a long mission your filling missionNamespace with lots of unneeded variables.

//initPlayerLocal

TAG_fnc_awardRevive = {
//Do what ever
params[ "_unit" ];
hint format[ "You revived %1, awarded %2 points", name _unit, 10 ];
};

[ missionNamespace, "reviveRevived", {
params [ "_unit", "_revivor" ];
if !( isNull _revivor ) then {

		[ _unit ] remoteExec [ "TAG_fnc_awardRevive", _revivor ];

};
}] call BIS_fnc_addScriptedEventHandler;

See https://forums.bistudio.com/topic/182228-scripted-event-handler-for-entering-and-exiting-incap-state/#entry2874967

I am also a ESDF key user and have done since coming from Arma2 into the A3 alpha. In fact ive now changed all my games as it allows for an extra column of keys in easy reach.

I would of thought an editor keys bindings section is something you would add early on and add keys to it as you implement features leaving you not having to back track once your finished. Especially from a usability standpoint for both devs, testers and now that its in beta your public users.

Current Zeus bindings do not work for the left and right panels but are hard coded to E and R.

Even keys from the Common bindings like Map, Lights, NightVision dont work but are hardcoded to M, L and N respectively.

Infantry movement bindings work for the 3D view yet 2D view movement is hard bound to WASD. It has always been a PITA that splendid camera is hardcoded to WASD and that has never been changed no matter how many time i commented on it both here, in the forums and in private to Moricky.

At the moment it just leave the new editor excessively frustrating to use and test. I understand it is beta but when one of the key features is the ability to seamlessly jump from 2D to 3D to playing having multiple different key sets is frustrating.

Generally I agree that entities should not exist at [0,0,0].
However the engines own marker system will place a marker at [0,0,0] if its given a crap position like an entity that no longer exist. OK you could say well the people who write their scripts should check for this occurrence but when the respawn menu craps out unless you know about this quirk the debugging could be a nightmare.
TBO i think youve taken the easy way out here when you could have changed a couple of more lines and provided a nice robust system for people to use. Which in doing so would not allow people to break your own systems.

I still think multiple var files would be better.
Mission keys and GUI setting etc still go to default profile but is locked to anything but access through engine. e.g activateKey etc

If you want a vars file for storing your specific stuff e.g DLRS or VAS or mission variables for a characters stats. Then profileNamespace has to specify a name e.g
( proflieNamespace "DLRS" ) setVariable ["myVar", _myValue];
saveProfileNamespace "DLRS";

Also has the benefit of keeping things separate in case a mod/script corrupts its var file. If you delete a script/mod that you longer need you can also delete its vars file.

ProfileNamespace is still loaded as a amalgamation of all var files and can be queried as such but any saving must be specified to a certain name that creates/updates it own vars file.

This can be closed, commands were added an are available on stable.

This is still broken for elliptical markers if axisB > axisA.
Triggers are ok as you can not create a trigger that has axisB > axisA as they automatically have their dir rotated 90degrees and axis swapped.

While your waiting for a possible fix you may find this link handy https://forums.bistudio.com/topic/182321-increasing-bis-fnc-livefeed-display-size/#entry2876393

Also add the joint commands, so many uses not just towing.

Can this be added to the list http://feedback.arma3.com/view.php?id=20431
ctrlAngle and ctrlSetAngle from VBS

Definitely seem to be some issues with this module. Sometimes the module fails to initialise properly aswell. See this thread for conversation http://forums.bistudio.com/showthread.php?167389-Simulation-manager&p=2564582#post2564582

The description for task notifications is %2 e.g
["TaskSucceeded",["", "Disable the nuke"]] call BIS_fnc_showNotification;

Its like this so you can send your default task array to the notification function and it will display the title rather than the long description

Thank you MulleDK19 & KK for the tips, my balding head appreciates them.

AArgh this made it through to stable v1.06.

Anything put in the watch lines now resets back to what was there before stable update. This makes the debugConsole a pain in the arse to use as you cant flick in and out of the escape menu to see your results without having to keep typing in the values you want to watch all the time. (same for the execute box) (not to mention i had some vague rubbish in my watch vars that now throw errors on the screen every time i escape).

This needs a hotfix when you got it done Moricky, this is an invaluable tool and is going to drive me crazy if we have to wait till the next stable update to use properly.

Excellent, cheers Moricky

May be worth removing that check from the while loop BL1P and adding it to a onEachFrame event instead. Maybe the odd occasion slipping through due to the sleep.

Check PM

oh ok , seeing we had had two dev updates and a stable update with alot of sector fixes since that comment i just presumed that this had gone through aswell.

Will test when it goes stable, I really dont have the bandwith and patience to be swapping back and forward between dev and stable every day. I wish you guys would go back to the OA way of patching (as a mod) makes life so much easier.

This is still not 100% fixed. (Stable build v1.06)
If the position is removed whilst the respawning player is looking at the respawn menu then they are still able to respawn at the position although it has been removed and is no longer a viable position.

What is fixed is - on reentering the respawn menu once a position has been removed, if your default position does not exist then you are given a viable position from the list.

As it currently is leaves a PvP exploit, on knowing you are going to lose the position (if your last respawn was here and you have not selected anything in the respawn menu) you can wait at the respawn menu, once the enemy team has captured the point and your respawn position has been removed, it is possible to wait for either the enemy to move on or be less cautious because they think the area is clear but you can still spawn on top of them.

If you wish to remove this behaviour from any PvP missions you are developing you can use this for now, until it is fixed :-

player addEventHandler ["Respawn", {
h = [] spawn {

		waitUntil { !(isNull (uiNamespace getVariable ["RscDisplayRespawn_display",displayNull])) };
		while {!(isNull (uiNamespace getVariable ["RscDisplayRespawn_display",displayNull]))} do {
			_defaultRespawnLocation = missionNamespace getVariable ["BIS_fnc_respawnMenuPosition_respawn",""];
			_respawnPositions = ((player call bis_fnc_objectSide) call bis_fnc_getRespawnMarkers) + (player call bis_fnc_getRespawnPositions);
			if ( !(_defaultRespawnLocation in _respawnPositions) ) then {
				missionNamespace setVariable ["BIS_fnc_respawnMenuPosition_respawn",""];
			};
			sleep 0.05;
		};

};
}];

This as a respawn eventHandler will constantly monitor the player whilst looking at the respawn menu, if his current default respawn position is no longer available it will be removed and he will be assigned a new one.

Just to backup what Egosa-U says :- for a temp fix open up your NAME.Arma3Profile and search for keyHeliFastForward[]={18}; and remove the 18 from between the brackets so it looks like keyHeliFastForward[]={};

Yes it still seems to be a problem in Stable 1.46. Using either a For loop or the command configClasses to iterate around the vehicles hitpoint classes. Try

terminate h;
h = [] spawn {

    while {true} do {

            hinttext = format ["%1\n\nMain Points\n******\n", typeOf cursorTarget];
            _veh = cursorTarget;
            "
            	_HPName = configName _x;
                hinttext = hinttext + format['%1 >> %2\n', _HPName, cursorTarget getHitPointDamage _HPName ];
            "configClasses ( configFile >> "CFGVehicles" >> typeOf _veh >> "Hitpoints" ) ;
            
        hintSilent hinttext;
        sleep 1;
    };

};

OR

terminate h;
h = [] spawn {

    while {true} do {

            hinttext = format ["%1\n\nMain Points\n******\n", typeOf cursorTarget];
            _veh = cursorTarget;
            _baseCFG = configFile >> "CFGVehicles" >> typeOf _veh;
            for "_i" from 0 to (count (_baseCFG >> "HitPoints"))-1 do {
                _HPName = configName((_baseCFG >> "HitPoints") select _i);
                hinttext = hinttext + format["%1 >> %2\n", _HPName, cursorTarget getHitPointDamage _HPName ];
            };

        hintSilent hinttext;
        sleep 1;
    };

};

From the debugConsole and compare the hitPoints reported in the hint whilst looking at a B_Truck_01_covered_F or O_Heli_Light_02_F to the hitpoints in the actual config for the vehicle. They do not seem to match?

count(configfile >> "CfgVehicles" >> "B_Truck_01_covered_F" >> "HitPoints");
returns 15
There are actually 19 hitpoints in the config

count(configfile >> "CfgVehicles" >> "O_Heli_Light_02_f" >> "HitPoints");
returns 9
There are actually 32 hitpoints in the config

They were the first two i retried.

This is still a problem. Just found this myself while trying to get HitPoint names http://forums.bistudio.com/showthread.php?181848-How-can-I-get-the-health-of-a-vehicles-hull-trurret-tracks&p=2751300&viewfull=1#post2751300.
Came here to post but found this open ticket.

Although as soon as the unit is ungrouped from you he will act accordingly and mount the vehicle in the correct turret position.

Steps to Reproduce:-
Place yourself down and one subordinated named u1. Create an empty Marshall and name it apc1.preview the mission.
In the debug console type u1 assignAsTurret [apc1,[0]]; u1 orderGetIn true;

Nothing will happen. Checking u1's assignedVehicleRole show it has been assigned properly.

Now do u1 join grpNull. and the unit will make a beeline for the apc and mount it properly according to assigned turret.

If that is correct wolfstriked it looks horrible and needs removing. As you say it does it in all Adjusted stances but is ok in normal stand, crouch, prone.

Quick video of a Standard BLUFOR rifleman droppped in the editor a rotating through different stances. http://youtu.be/TT04St8Ujp0

Its almost like the animation is speed up, although crouch does not shake as such the gun wobble is definately faster than standing

players view seems to be set to a position in front of the guns muzzle instead of actually looking down the GL sights. See my video in this Issue http://feedback.arma3.com/view.php?id=4082

Heres a quick video ive made showing the problems with the GL sights http://youtu.be/S44HdV0CKW4

Im sorry rogerx but i do not have a clue what you are talking about "slowing of the throttle" ??

My X52 works fine in ARMA with or without the profiler running, the only problem is game side where the analogue collective is shifted versus using keyboard on digital collective. There is talk on the forums showing the same thing with banking, analogue does not bank as much as digital (using keys) does. There is obviously something wrong with BIS's conversion of analogue axis to ingame thresholds/values.

Sounds to me like you have a separate problem related to the profiler and windows 8?? Im getting no .NET errors in my system log on WIN7 64 (Home edition).

Quote PTW-105 : "When you map Z+ above Z- in the keybinds for "Collective Increase (Analog)", the throttle behavior is reversed (0% throttle is 100% throttle being applied and vice-versa)."

If the mapping are going to remain as they are i actually like this. I prefer my collective to be full when pulled towards me. I can then reverse this in the settings for aircraft.

@ rogerx
I am going to have to disagree with your findings on the collective.
To put things into perspective first, I have a X52 (non pro) using driver version 6.0.4.1 and profile version 6.6.6.9. I have never had any problems assigning axis in either ARMA 2 or 3, although I'm am not sure if these inconsistencies exist in ARMA 2 as i have not done much flying in it.
I have used DIView to make sure my X52 is calibrated correctly and that I am receiving no spurious data. Throttle is RAW 0 to RAW 255 and steady.
In game I have +Z and -Z assigned to analogue collective raise as discussed above and analogue collective lower empty. I also have Q assigned to collective raise and Z to collective lower.

Whilst in game with a steady horizon and as little speed as possible :-

KA60 :
There is a dial in the centre console that shows climb and descent (not sure what the official naming is for this display) 9o'clock position is 0 @ 50% throttle, it is also shown in the HUD just to the right of your cross hairs.
At full collective on the X52 my climb rate is +12, if I then hold Q to override with the keyboard this value will decrease to +10.
At collective fully lowered on my X52 my descent will display -8, if I then override by holding Z my descent rate will change to -10.

There is a discrepancy between analogue collective and collective of +2.

climb    descent

X52: +12 -8
keyboard: +10 -10

This discrepancy is Visually noticeable especially when descending. You can see exactly the same behaviour in the Littlebird although the dials are somewhat different.

Can the others reading this thread please test this out as well whether you have an X52 or some other analogue method. Is this a discrepancy for the X52, maybe related to how the axis are assigned, or is this a problem with analogue collective in general.

(Think I covered everything I wanted to. Second time of writing due to account being signed off/session discontinued, and on posting losing everything doh)

Same here X52 throttle is seen as Z+ and Z- so you only ever get half the throw. It should just be seen as one axis Z and report 0-255.

ok after much experimenting ive found you get the full throw of the throttle on a logitech X52 if you map both Z- and Z+ to raise collective and leave lower collective empty. You can notice it by watching the (dont know name) small needle in the smaller dial in the lower left dial (RPM) in the littlebird.

This was fixed fors stable build 0.52 *RESOLVED*