I believe there is none unless we use EachFrame/Draw3D and call it a day. Smooth transition wouldn't be a concern to consider IMO, from what I can see firing an EH upon cameraView has changed is good enough to detect Visual/Pilot LOD change etc.
However and just thouht of, "BeforeCameraViewChanged" might be an addition to suppress the viewmode update etc I guess. Not really sure how it would have a usecase, so just sayin'.

The issue is identified. Unfortunately the fix didn't make it into the last update - but hopefully next one

Go into preview and here is what you get from this script:

allMissionObjects "" apply {[typeOf _x,synchronizedObjects _x]}
/*
	[
		[L Modules:1,"Logic",[]],
		[L Alpha 1-2:1,"Logic",[B Alpha 1-1:1 (POLPOX),1d79b893580# 3: sign_arrow_f.p3d,1d7954be040# 4: mrap_01_unarmed_f.p3d,L Ambient:1,6: <no shape>]],
		[1d79b893580# 3: sign_arrow_f.p3d,"Sign_Arrow_Blue_F",[]],
		[1d7954be040# 4: mrap_01_unarmed_f.p3d,"B_MRAP_01_F",[]],
		[L Ambient:1,"ModuleCivilianPresence_F",[B Alpha 1-1:1 (POLPOX),L Alpha 1-2:1,1d79b893580# 3: sign_arrow_f.p3d,1d7954be040# 4: mrap_01_unarmed_f.p3d,6: <no shape>]],
		[6: <no shape>,"EmptyDetector",[B Alpha 1-1:1 (POLPOX),L Alpha 1-2:1,1d79b893580# 3: sign_arrow_f.p3d,1d7954be040# 4: mrap_01_unarmed_f.p3d,L Ambient:1]],
		[B Alpha 1-1:1 (POLPOX),"B_Soldier_F",[L Alpha 1-2:1,1d79b893580# 3: sign_arrow_f.p3d,1d7954be040# 4: mrap_01_unarmed_f.p3d,L Ambient:1,6: <no shape>]]
	]
*/

As you can see props and vehicles don't even accept the synchronization. Maybe more objects don't.

Indeed there is no MEH or Object EH to detect it, I've once tried to do similar with remoteExec ways IIRC, but isn't really a good way anyways

I'm not the one who has the responsibility, nor none of Rotators dudes have, but things I want to consider/make it sure:

1. Restart Arma 3 and Arma 3 Launcher
2. Restart Steam too

Hmm had to agree that it is a good idea to have an EH to detect if someone starts to speak or stops.

Oh yeah, I literally forgot that, yeah that would "fix" this too.

focusOn that is introduced in 2.15 solved this ticket partially, but I'd like to see more commands for such things.

Uhh, excuse me, you guys have fixed the cap model not the issue itself? I've thought you've done the entire fix but just tested but 2.14 does still have the issue, as far as I tried, Type 115 does.

In T172179#2447365, @dedmen wrote:

We can skip the config merge, but we cannot unload already loaded PBO's
So all the files of the addon, will still be present even if we skip its load. So like __has_include kind of checking may cause false results

I think it is fine if the files are loaded still.

Pretty understandable concern for a two decades old system. Apparently this is just a (better) workaround of an existed solution so I don't think this should be prioritized. Good to have, actually, though.

In T171323#2425423, @SaMatra wrote:

I wonder if its possible to fix this through config without changing the model?

Thought could be useful to determine/check which commit is done.

Pretty sure the function will not work since it is made for A2:PMC and just carried on without checking anything. There're several functions that won't work because of that.

Late to the party, but it is really obvious that the selection doesn't exist when the return value is simply [0,0,0]. As Leopard20 said, it is really hard to justify this log spam in my opinion.

Really a big bump, but I'd like to see this. class Damage is somewhat hard to understand, unreliable and not good for custom materials (for either config/ingame command).
If this could be a thing, script commands for them are needed as well I think (Like setObjectDamaged/DestroyedMaterial ?).

We're aware about this issue, should be fixed real soon.

This issue only exists in the NATO parade uniform, looks it lacks camo3 selection in the model unlike other models (CSAT, AAF, LDF uniforms).

Because August in Southern Hemisphere is winter so it should be chiller than its January.
...If what the config does is the same thing I imagine.

I was talked about U+0020, which is the character that will be written when we press the space bar on a keyboard.

I found out that hair space (U+200A) doesn't have this issue and have the same width with regular space, so possible to use to do a workaround.

Didn't mention it but if it's possible to change visibility/color via Trigger's Attribute in Eden Editor, is also welcomed.

Actually, the problem is: In any UI settings or interface scale, the font weight of Asian fonts don't correspond to that of Latin fonts so that a text supposed to be bolded will be shown in Light as shown below and some texts are very thin to read especially subtitles after Apex as shown in the description. Sorry to make this confusion, that was a bad title.

Another example.

Suggestion: How about make variants of the font(NotoSans)?
Use Light variant along to some Light font like PuristaLight, use Medium along to, use Bold along to so on.

I don't know this works in dedicated though, place

When they solved this issue? In ["Arma 3","Arma3",183,144605,"Development",true,"Windows","x64"] no this problem.