Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

Fixed in Dev build 151825.

You don't switch to the countermeasures weapon. If you mean changing the CM firing mode. Don't know, test it and report back :harold:

I noticed it didn't work right with vehicles and removeMagazinesTurret.
I fixed that now. But I don't have time to properly fix all possible ways of removing magazines.
And also not sure if it might not double trigger the EH in some case.

Fixed since Update 2.16

Haven't tested it yet, does it trigger for countermeasures on vehicles?

"MagazineUnloaded"
[B Alpha 1-1:3 (dedmen),"arifle_MXC_F","arifle_MXC_F",["30Rnd_65x39_caseless_mag",30,1.00003e+07,0]]
[B Alpha 1-1:3 (dedmen),"hgun_P07_F","hgun_P07_F",["16Rnd_9x21_Mag",16,1.00003e+07,0]]

https://feedback.bistudio.com/T178384
No magazine data in there

https://feedback.bistudio.com/T178384
Its not giving you the magazine in there. But surely you can pull that yourself. If you can't ping me on discord I might miss reply here.

SlotItemChanged

[B Alpha 1-1:1 (dedmen),"optic_Aco",201,false,"arifle_MX_ACO_pointer_F"]
[B Alpha 1-1:1 (dedmen),"optic_Aco",201,true,"arifle_MX_ACO_pointer_F"]
[B Alpha 1-1:1 (dedmen),"acc_pointer_IR",301,false,"arifle_MX_ACO_pointer_F"]
[B Alpha 1-1:1 (dedmen),"acc_pointer_IR",301,true,"arifle_MX_ACO_pointer_F"]

"Since SlotItemChanged cannot be used for items in the attachment slots of a weapon"
Well why not add it to the existing EH?

I'm looking at WeaponSlotItem/MagazineChanged next

With this addition becoming a reality, is there any chance of seeing WeaponSlotItemChanged set up for the magazine half of this request?

Adding one element to an array that already exists anyway, is much much much cheaper than executing a SQF command that looks up the weapon and returns the result.
Yeah it should be somewhat rare, also not many objects will have the EH added anyway. So we'll just leave the many args.

The EH itself should not trigger frequently - in regards to performance.

IFV-6A Cheetah toggle gunner weapons
EH owner, prev, new, prevMode, newMode, prevMuzzle, newMuzzle, turretIndex

[B Alpha 1-1:3 (dedmen),"autocannon_35mm","missiles_titan_AA","manual","Player","autocannon_35mm","missiles_titan_AA",[0]]
[B Alpha 1-1:3 (dedmen),"missiles_titan_AA","autocannon_35mm","Player","manual","missiles_titan_AA","autocannon_35mm",[0]]

params ["_unit","_weaponPrevious","_weaponNew","_vehicle","_turret"];//for vehicles

Fixed in Dev build 151781.

Fixed in Dev build 151781.

Will this trigger on mode and muzzle change too? Perhaps all 3 can be included somehow.

what would you imagine the weapons to be?
In code I have the weapon index. Do you want classnames?

@Nelis75733126, I would also like this bug to be fixed. Until this bug is fixed, you can either use my workaround or wait who knows how long. The choice is yours. :)

@Schatten i appreciate your contribution. however, i want to make it very clear that i wish that this issue gets resolved by a developer from Bohemia Interactive. Because that is what needs to happen in order to make regular players enjoy the already impressive AI convoy behavior. It just has flaws that ruin the whole thing.

Confirm. Sometimes even the commander's vehicle freezes.
I can even say that after updating to version 2.16, sometimes convoys ignore the added waypoints.
A workaround for resuming following the leader's vehicle:

_groupLeader = leader _group;
_groupLeaderVehicle = objectParent _groupLeader;
_groupLeaderVehicleSpeed = abs (speed _groupLeaderVehicle);

In T170535#2603824, @SaMatra wrote:

Bug found in inAreaArrayIndexes, it ignores c for height:

private _area = [positionCameraToWorld [0,0,0], 20, 20, 0, true, 20];
[
     [player] inAreaArrayIndexes _area
    ,[player] inAreaArray _area
]

I uninstalled and reinstalled Arma 3 via Steam. Is that a soft uninstall? Should I do a hard purge of Arma3 ? Which folders can I backup to keep my graphics settings, pofile and key bindings ?

most recent crash logs are here - RPT and mDMP https://filetransfer.io/data-package/ZQmLCxOa#link

next perf/dev

after doing even more testing, it seems that the followers in the convoy "freeze" most often on intersections and very sharp corners.

i would like to add that it seems like the speed of the convoy has a big impact on the behavior. when the movement speed is low, the route in the test mission will complete completely fine.

Can be closed;
revisted the problem to see what I may have done wrong and found out the problem:

Also Getting threats from staff about them going to beat people up irl

Please post TEXT as TEXT instead of images in different resolutions - it's TEXT!
The 4 examples with additional leading zeroes seem more like some changed formatting as they don't change the actual evaluated value mathematical - in fact, there shouldn't be any leading zeroes in scientific notation.
In the end it's IEEE754 imprecision of floating point numbers. The main underlying issue is that A3 only uses one number type "scalar" which is floating point - this can issues for whole integers sometimes not able to be represented correctly in IEEE754 i.e. have 2 end up in 1.999 or 2.00000001 or something stupid like this.
As for the attribtues: Yes, they got swapped around, but here the issue isn't that the editor does it but rather that your comparison engine doesn't correctly recognize the blocks and only shows the labels changed but wrongly thinks content of the blocks changed. Yes, correctly the attributes shouldn't get shuffled around once they're set and not further modified, but that's not how the editor engine works, don't think about the attributed as a fixed-order set of elements but rather a not-fixed list: The editor loads all stuff into memory - and on save it gets back serialized - in the order it's currently in memory. And if, for some reason, the not-predictable order list has changed the order - or rather changed the order the contained elements stored - then that's perfectly ok from a programmers point of view if all that matters are the presence of the elements and thier values but not thier order.
If you use some version control which has to deal with such results you have to change the version control engine to correctly deal with the blocks as one instead of splitting up thier unordered content. It's not the editor at fault but your version control.

If this ticket has a chance to be implemented, let me know and I'll make scripts to quickly test it.

Found through comparison with alpha where it works, you need to have hit > 10 for it to work.

class CfgAmmo {
    class Grenade;
    class GrenadeHand:Grenade {
        hit = 10.00001;
    };
};

Really weird choice but seeing that alpha uses same grenade config as OA probably means this engine part wasn't touched for years.

Sorry, closed it by mistake 😅

Bug found in inAreaArrayIndexes, it ignores c for height:

private _area = [positionCameraToWorld [0,0,0], 20, 20, 0, true, 20];
[
     [player] inAreaArrayIndexes _area
    ,[player] inAreaArray _area
]

> [[],[B Alpha 1-2:1 (Sa-Matra)]]

Intressting about it is the mag appears for a moment in the inventory and gets "deleted". Can happen moving mags from the weapon into a container too.

Fixed in dev build 151781.

Fixed in Dev build 151781.

There are reports that this can also happen when the unit does a gesture partway through a reload. (See: Arma Discord > arma3_feedback_tracker)

In T126046#2602464, @NikkoJT wrote:

I think you need to read a bit more carefully.

KK added a revision number (i.e. the change number for the problem being fixed) and changed the task status to Feedback, as in "waiting for feedback on whether the fix worked".

I tested addMagazineCargo, addItemCargo and addMagazineAmmoCargo, all are fixed. Tyvm!

next dev/prof

The submunition being spawned multiple times is actually normal.
Every shot has a local-only copy on every player. But they should be flagged as being local and not cause effects like that.

In T154359#2602895, @dedmen wrote:

We're switching from "the target that was last shot at" to "the target we are going to shoot at". I think that fits.

Works for me

getAttackTarget isn't well defined.
So it returning the "target the unit is told to attack" seems correct.
We're switching from "the target that was last shot at" to "the target we are going to shoot at". I think that fits.

next prof/dev

I love it. It's easy to play. I will win all these cookie clicker 2 missions.