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

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.

"Unloaded"
[B Alpha 1-1:3 (dedmen),"arifle_MXC_F","arifle_MXC_F",["30Rnd_65x39_caseless_mag",30,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

An expansion of this could be that direct connect doesn't directly connect, but instead displays all servers on the domain (If it can).

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.

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

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

next perf/dev

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.

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

next prof/dev

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

Next profiling and dev branch

This bug happened because the unit needs to be notified that their inventory contents have changed.
With the commands that get the unit as argument its easy, the unit is right there.
But the commands that get a container, first need to find which unit it belongs to, and there might not be any unit at all.

Huh. Weird that we didn't find that before.
Thank you, the crashdump was enough to see what was going on. Fixed next profiling/dev branch.

next prof

I hope it will be fixed with next profiling branch update, v5.

This is essentially the bug we had before.
Where textures referenced in the display, would not be loaded at first, so you need to keep re-rendering the display.

Walking ontop of roadway lod is not a collision.
There is a comment from 2018 on the wiki page stating this.

Wow this ticket is so old that it forced me to edit the line endings in the text :D

[[5: <no shape>,[["rtt2","Internal","Thermal",7],["rtt1","Internal","Normal",0]],false]]

effect is meh.
R2T sources have their own effect, otherwise there is only one global camera effect. Not per-camera.

Ref https://feedback.bistudio.com/T180805
Chains of skippable addons are not supported

It is what I mentioned here
https://feedback.bistudio.com/T172179#2447268

This seems it would just make it easier for cheaters to post bullets impersonating other players.

Won't do.

Please follow https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

Same crash, fixed in todays profiling branch update

UI to texture rendering failed. The rendertarget didn't exist. I don't know how that happened I never saw that before. I added a safety check, won't happen again after tomorrows profiling branch

I have both yes.

You can already get position of a model selection/bone can't you?
So you can calculate the required offset

Very likely that its the same reason yeah. I didn't check the code

We updated the Mac version a few days ago, does it work now?

You mean storing the video in a mod, that every player has?

Won't do. Feel free to write your own, or look at what the firing drill code does.

Very unlikely. The inventory system is not maintainable and this would probably be very complex.

???
attachTo can already attach to selection. And you can rotate it after attaching. Wiki even has example of that https://community.bistudio.com/wiki/attachTo
I don't get this? what is missing? As far as I can see its already all there

Air effects are included by class Air so base class for air vehicles.
"but when flying over that material"
Dust effects are for wheels, not flying. Rolling wheels only. Only when the vehicle has https://community.bistudio.com/wiki/isTouchingGround and moves, then dust is spawned at the wheels.

MissionEventhandlers make sense.
You can already see in your chat display bottom left, who is transmitting right?

The access code is no longer needed, as the update was officially released.

Unlikely

looks like a random one-time crash. Nothing actionable.

createSoundSource already takes array.
Can we just add a "localOnly" parameter to it? should be fine right?

getArtilleryComputerSettings sounds good place to put this.
The position is stored in global UI, "GetAtilleryTarget"
the settings command could also return a reference to the UI display? Like shownArtilleryComputer checks.
Its actually a dialog, the dialog that https://community.bistudio.com/wiki/dialog checks. That could've also just returned the dialog display (which can then be checked for null), but alas we have 20 years of tech debt.

This seems to have been done on purpose, back in 2018.

There is a CommandChanged group EH, but that only works for commands. See below.

The only crashes in your report are from december, where the game crashed when you were shutting it down.
There are no logs newer than december in there.

next prof/dev

getModelInfo player
0.000409759
0.000415021
0.000424912