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.

next prof/dev

I think you need to read a bit more carefully.

@Bis! 9 years have passed, Instead of fixing it, you only change the status of this problem, 9 years later! Looool!
Mod makers fixed this themselves a long time ago!

The Grenade Window Breaker mod works for both hand and UGL grenades...

@Bis! 9 years have passed, Instead of fixing it, you only change the status of this problem, 9 years later! Looool!

false report - after extensive debugging turns out was likely viewdistance related

In T154359#2602361, @dedmen wrote:

The weapon the unit is using, knows what its told to shoot at.
We could say "If you are told to shoot something, that should be considered target"
That would be doable, if unit has no assigned target, check if its weapon is told to shoot at something and use that instead..

Repro mission is a bit meh, only updating every 0.5s
replacing with a onEachFrame makes it much easier to see

Ugh this is a mess.

No

Fixed next profiling/dev branch

Any chance to see removeMagazineTurret get the same treatment as addMagazineTurret did (i.e. getting a third optional parameter specifying the ammo count)?

Can you close https://feedback.bistudio.com/T122981 and https://feedback.bistudio.com/T80537, as they are related to the fix?
It's not really related to this, but https://feedback.bistudio.com/T79683 can be closed too.

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791

Revision: 151791