commy2

You are to focused on the goal you personally want to achive. The command is simply not meant for AI. Even if you "selectWeapon" to a pistol, the AI will select the launcher if a tank comes along. What you want is a command that forces the AI to keep a weapon selected, which would make it impossible for it to engage infantry at all. You are totally right that such a framework for AI could be useful for mission makers. That doesn't change the fact that "selectWeapon" works - for what it is meant to do. Your thread is titled "selectWeapon doesn't work for launcher" which is simply not correct.

The AI does not need enemies to be present for it to switch back to the rifle. You are wrong if you think I haven't tried this myself already. Just do the following test - put it into the init box of an AI AT soldier: 0 = this spawn { _this selectWeapon secondaryWeapon _this; while {true} do { diag_log currentWeapon _this; }; }; This will make him select the launcher, and then for the rest of the game print his selected weapon into the RPT. You will get the following result: 21:47:26 "launch_B_Titan_short_F" 21:47:26 "launch_B_Titan_short_F" 21:47:26 "launch_B_Titan_short_F" ...hundres of lines here 21:47:44 "launch_B_Titan_short_F" 21:47:44 "arifle_MXC_Holo_pointer_F" 21:47:44 "arifle_MXC_Holo_pointer_F" ...continued until mission ends The conclusion is that "selectWeapon" works for AI, but the AI switches back to the rifle immediately. They don't need any enemies nearby for that and the change can happen so quickly, that you never see them reaching for their launcher animation wise.

Yes I think this might be because the players sentences are created on the players machine and then sent over the network. If you mute all sentences on a machine, all units local to that machine will be muted for everyone. That would be because the machine that owns the unit doesn't send any such messages anymore. I haven't tested this, but that would explain that. Whether or not that means that "enableSentences" has global effects instead of local ones is up to debate if that's true I guess. The local-global dichotomy just doesn't work for everything.

No, you didn't listen. You are thinking about this to hard. There are no such things as "stand alone commands" - what would that even mean? This also has absolutely nothing to do with the editor, triggers or ammo. What does "selectWeapon" do? It makes the unit switch to that weapon (or muzzle). It works for the player and for AI. The only limitation is that you have to execute it on the machine where the unit is local. What does the command not do? It does not order the AI to keep the weapon selected. There is no such command and as far as I know, there is no way to order the AI to keep a weapon either. The AI will select the launcher, but it will immediately switch back to a rifle or pistol, because it wants to engage infantry. It's two systems running against each other: your trigger and the soldiers AI. Maybe there is some kind of way for the AI to keep the launcher, but I'm not aware of any.

"enableSentences" has local effects, but that doesn't mean it just works for the player. It means that it disables (or enables) ai talk on the local machine. There is a way to just mute player units, but it requires you to write a radio protocoll config where you remove all sentences. (you still have to put in a ton of classes just so this bad system doesn't choke on missing paths). https://github.com/acemod/ACE3/blob/master/addons/common/CfgVoice.hpp Then you can use "setSpeaker" to apply this radio protocoll to all players. It's really tricky because "setSpeaker" fails on unit init and is not JIP persistant. ACE 3 has this.

`selectWeapon` works, but the AI will always switch back to a rifle to engage enemy infantry.

You cannot use the ## thingies in strings. You'll have to stringify the entry after merging in the TEX variable. There is a (for me) unknown problem with #() when used in any mildy complex statement. You'll probably need a helper macro: #define QUOTE(var) #(var) hiddenSelectionsTextures[] = {QUOTE(\use_police\data\##TEX##.paa)}; \

Yeah, I was using "configName" too, so my post was easier to read. Didn't know whether you needed the configs or the classnames. Rereading this thread I wandered totally off topic with those hitpoints. I guess it was stuff that was on my mind at that time? Take it as a bonus.

More notes about hitpoints: - not all hitpoints in config are actually valid. They all can be damaged by "setDamage", "setHitIndex" or "setHitPointDamage" commands, but if they have no existing selection in the models "Hit-points" LOD, they never actually take any damage from hits and explosions. The configs are all over the place and ignore this fact. (exceptions are hitpoints with linked damage like "HitEngine" in helicopters) A way to retrieve all valid hitpoints would be a function like this below. The only downside is that you need an existing object and not just a classname: commy_fnc_allHitPoints = { params [["_object", objNull, [objNull]]]; getAllHitPointsDamage _object params [["_hitpoints", []], ["_selections", []]]; private _return = []; { if (_x != "") then { _return pushBack (_hitpoints select _forEachIndex); }; } forEach _selections; _return }; Note that "getAllHitPointsDamages" already filters out selections mentioned in config that don't exist in the model. - Hitpoints can have duplicate names. Examples for this are "HitGun" and "HitTurret" which can appear as hitpoints of turrets (e.g. commander turret). "getHitPointDamage" and "setHitPointDamage" cannot read or set the values for these correctly. Exact behaviour for these commands seems to be undefined in these cases, which is why you'll have to use "set/getHit(Index)" if you want to get it right. Selection names don't have duplicates.

Hello, A few points: - don't use "BIS_fnc_getCfgSubClasses". It was used before "configClasses" existed and has no benefit anymore, but is significantly slower (as far as I can tell). - "configClasses" as well as "count" and "select" ignore inherited subclasses if at least one other subclass was added in one of the ancestors of the class your are trying to retrieve the subclasses from. - The similar command "configProperties" has an optional parameter to search through all ancestor classes, but also reports <STRING>, <NUMBER> and <ARRAY> entries as well as subclasses. Solution is to use the "configProperties" command with an isClass filter: private _config = configFile >> "CfgVehicles" >> "O_MRAP_02_F" >> "AnimationSources"; configProperties [_config, "isClass _x", true] //["HitReserveWheel","Door_LF","Door_RF","Door_LM","Door_RM","Door_rear","HitGlass6","HitGlass7","HitGlass8","HitGlass9","HitGlass10","HitGlass11","HitLFWheel","HitRFWheel","HitLBWheel","HitRBWheel","HitLF2Wheel","HitRF2Wheel","HitLMWheel","HitRMWheel","HitGlass1","HitGlass2","HitGlass3","HitGlass4","HitGlass5"] Counter example using "configClasses": private _config = configFile >> "CfgVehicles" >> "O_MRAP_02_F" >> "AnimationSources"; "true" configClasses _config //["HitReserveWheel","Door_LF","Door_RF","Door_LM","Door_RM","Door_rear","HitGlass6","HitGlass7","HitGlass8","HitGlass9","HitGlass10","HitGlass11"]

Keep in mind that += is broken for inherited classes. "class ACE_Equipment" is never inherited in that way so it's fine there. I'd link the issue on the feedback tracker were I explained the behaviour in full detail ... Oh and I'm sorry for this cumbersome system. It's basically from AGM, where I didn't know any better. I'd do it in a way simpler way today.

My guess is that you added "isNotSwimming" correctly to your action, but didn't add it to the parent action, "ACE_Equipment". The "ACE_Equipment" parent action is disabled while swimming by default, so your child action isn't shown. https://github.com/acemod/ACE3/blob/master/addons/interaction/CfgVehicles.hpp#L293-L296 Solution: class ACE_Equipment { exceptions[] += {"isNotSwimming"}; class My_Custom_Action { ... }; };

We have an issue tracker. We tend to ignore bug reports on the forum thread, because it would be impossible to keep track of them. https://github.com/acemod/ACE3/issues

Interesting. For PlayerDisconnected this was supposedly fixed during 1.57 dev. It even appeared in a changelog. Maybe the change didn't make it into stable branch? https://forums.bistudio.com/topic/140837-development-branch-changelog/?p=3002942

It's called "ace_common_DisableMouse_Dialog" and has no idd (or rather -1 - I think those idds are stupid), but you can retrieve the DISPLAY via: uiNamespace getVariable ["ace_common_dlgDisableMouse", displayNull]; It already has key handlers attached that block input by returning true. No idea if stacking works, you might have to remove our handlers first. BE servers seem to be down. You'll have to wait until they fix them.

This has multiple problems: - the gunlight or IR laser will be turned off - the weapon mode (e.g. full auto) will be reset to semi You can restore the weapon mode with "action 'SwitchMagazine'", but that would turn the gunlight/ir laser off as well. (and it's itself rather slow and hacky) You could restore the state of the gunlight/ir laser by using "action 'IRLaserOn/GunLightOn'", but those have a bug where they reset the weapon mode... You can restore only one of them. :/

Instead of "onPlayerConnected {}" one should use "BIS_fnc_addStackedEventHandler" with "onPlayerConnected" to initialize (?) the event. That way you at least don't overwrite other events that make use of "BIS_fnc_addStackedEventHandler". Example: https://github.com/CBATeam/CBA_A3/blob/62f7ee38861940146610bd26b09e17515863310e/addons/common/XEH_preInit.sqf#L40-L43 Last time I tried, this bug only applied to "onPlayerConnected" and not to the "Disconnected" variant. This should really be fixed.

No, but my point was that "getUnitLoadout" is not the only command that reports the binoculars magazine. "weaponsItems" does that as well. Also sorry for bringing it up, because it is completely missing the point. "getUnitLoadout" does not report the same format as "magazinesDetail" (localized name with magazine id), which is what this ticket is about. B_recon_JTAC_F player call CBA_fnc_binocularMagazine 0.0382 ms getUnitLoadout player param [8, []] param [4, [""]] select 0 0.0733 ms

>The script command "magazinesDetail" doesn't include the loaded Laser Designator battery. Pretty sure this is intended behaviour. It returns no loaded magazine (incl. primary weapon, pistols, other muzzles etc.). Just like the regular "magazines" command which this is an derivate from. >I suggest using getUnitLoadout, as it is the only command that returns lasedesignator battery properly Not entirely true. It is also returned by "weaponsItems". You can create a forEach loop that reports the magazine(s): { if ((_x select 0) isEqualTo binocular _unit) exitWith { _magazine = (_x select 4) param [0, ""]; }; } forEach weaponsitems _unit; This is still faster than "getUnitLoadout" (even with few items in inventory), which is a pretty expensive command and might be overkill if you only want the binoculars magazine. >It's not possible to get the magazine ID when the binocular is not equipped. This is the real issue here. You cannot retrieve the magazine IDs of loaded magazines (any rifle, binocular, grenade launcher, 120mm ...), except with "currentMagazineDetail(Turret)". "getUnitLoadout" does not do magazines IDs afaik.

No. Wait for the next version. It should be fixed there.

Those statistics have nothing to do with ACE. You'll have to ask the content creators about this.

No need to. They will be deprecated soon anyway. Checkout these: https://community.bistudio.com/wiki/getUnitLoadout https://community.bistudio.com/wiki/setUnitLoadout

There is already the Patrol Pack/Kampfrucksack backpack as well as ~7 vanilla retextures in Fleck and Tropentarn.

Post RPT

You have to select that one that is _not_ named "... (Used)" and you have to have a backpack so you can pick up a "magazine" for it. Same is true for the RGW 90. It's clunky, but that is how the Arsenal works. It shows the "(Used)" variant whenever you open the arsenal while having a "(Used)" one in the inventory at least once in the mission. Again strange and clunky, but it's just how the arsenal is scripted. Nothing we can or should do about that.