In T181080#2606304, @dedmen wrote:

https://community.bistudio.com/wiki/setPlayerVoNVolume
https://community.bistudio.com/wiki/getPlayerVoNVolume

can be used to mute players.

Don't know if it corresponds with the actual mute button

As actionKeysEx was added, imo this is resolved (it does the job well for me).

Still an issue in 2.17.151825.

The tweak described in this ticket was done in the latest dev update
Can be closed, works good, thanks

Fixed: Any surface impact for grenades was using the ground impact sound

Lastest dev branch update fixed impact sounds for walls and objects but not for surfaces where players can move
See this picture, this is full metal object, after rev. 151825 the green part of object will sucsess play metal impact sound, but red part still will use the ground impact sound

In T181219#2607653, @Schatten wrote:

And? I wrote "at least" since I'm sure about the situation with dedicated servers. The same is likely for locally hosted servers, since from my experience I also couldn't change view distance on such servers.

Have you watched the video? Have you tried the same thing as me? I didn't have this problem before. The view distance was the same for single-player and multiplayer missions. I could change it as much as I wanted. I don't know why it suddenly became like this.

And? I wrote "at least" since I'm sure about the situation with dedicated servers. The same is likely for locally hosted servers, since from my experience I also couldn't change view distance on such servers.

In T181219#2607463, @Schatten wrote:

AFAIK, in MP missions (at least those hosted on dedicated servers) view distance is always locked. The only way to change it is to use third party solutions, for instance: https://steamcommunity.com/sharedfiles/filedetails/?id=837729515

AFAIK, in MP missions (at least those hosted on dedicated servers) view distance is always locked. The only way to change it is to use third party solutions, for instance: https://steamcommunity.com/sharedfiles/filedetails/?id=837729515

In T181219#2607264, @kju-PvPscene wrote:

in MP the server or mission can force the viewdistance - so depends on the mission/game mode (or server side mods)

for reference https://community.bistudio.com/wiki/setMissionOptions

in MP the server or mission can force the viewdistance - so depends on the mission/game mode (or server side mods)

Are there any news on this? I.e. is it being investigated and/or do other players experience this too?

Good morning
Merci,

setMissionOptions thing

Need steps to reproduce

Ref https://feedback.bistudio.com/T181170

See difference in second return index

https://community.bistudio.com/wiki/Arma_3:_Unusual_Process_Exit#0xC0000135_-_STATUS_DLL_NOT_FOUND

The code that crashed there, doesn't run on profiling branch. It failed trying to copy a script variable, that it doesn't need to copy.
Can't see why it failed

Definitely a bug in our code.
We have a possible fix for next profiling branch update. But I don't know if that will solve this.
You said reproducibility always, but you only included one crashdump.

Crash at game end. Known but we don't know what causes it.

https://community.bistudio.com/wiki/setPlayerVoNVolume
https://community.bistudio.com/wiki/getPlayerVoNVolume

Fixed in Dev build 2.17.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.

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.