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.

Thanks for the hint that we have the visor up model, that makes testing easy

class CfgWeapons
{
	class ItemCore;
	class H_HelmetB : ItemCore
	{
		class ItemInfo;		
	};
	class H_PilotHelmetHeli_B : H_HelmetB
	{
		class ItemInfo: ItemInfo
		{
			modelHMDOff = "A3\Characters_F\Common\headgear_helmet_heli_visor_up";
			uniformModel = "A3\Characters_F\Common\headgear_helmet_heli";
		};
	};
};

Config name for this is modelHMDOff
Behaves same and switches at same points as the HMD item.

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, which is unfortunate when lots of things just aren't 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

I don't see the need to spam commands for every place where this pattern appears.
I'd rather improve the performance of getModelInfo instead.

The sound was considered annoying and was intentionally disabled in mid-2018 (Data131653).

Man::Sound weaponInstance

The problem is that everytime a user is added/removed/changed(ready status) in that list, the scrollbar is reset.
Quite hard to reproduce, without battleye on a dev build.

Need example mission with such a pylon based weapon.
Optimally with script that demonstates the issue

You can add that yourself if you wish.
We will not. The _fnc_scriptName in CfgFunctions is also not automatically added, its in the CfgFunctions init script which prepends a header to every script.
If you want that, you have to script it yourself, just like CfgFunctions does.

Please follow this https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/
We need the log files.

Thats what I deserve for copy pasting code and then only fixing a bug in one of the two.
There is also a memory leak in there, on every save for every hashmap serialization.

I can actually measure the one function that runs there. And I can see the difference but it's so extremely small.

Well it would make sense that you cannot play a game that doesn't exist on playstation, on playstation.

It is a setting, in the Video options under the Display tab.

There are Todo's in code in multiple places saying that Form needs to be handled.
This feature was never actually implemented. Its unlikely that it will.

Please follow this: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/
And please don't dump a huge amount of text into a text field. You can upload files here too.

Not possible.
FSR 1 might be the maximum doable.

BattlEye would need to add it on their end.
Probably into their existing BE server config.

Very unlikely.
static noise and transmission quality maybe. Rest no.

If they don't even support animation at all, then definitely not.

"when you watch remote players" yeah you are moving your camera into them.
I assume local camera state will reflect theirs, and as I'm checking local camera state, it will probably also trigger isADS then. But only while spectating.