Tested it and CC turns off when engine is turned off.

In T164110#2296504, @dedmen wrote:

That's behavior not combat mode...

Not in engine.

That's behavior not combat mode...

Not in engine.

CommandChanged: A unit EH that triggers when any parameter in the unit's currentCommand or expectedDestination changes. For a simple use case, it can be used instead of looping to detect when unit is ready: waitUntil {unitReady unit}

BehaviourChanged: Another very useful EH. Should be both a group and unit EH.

In T164110#2296495, @dedmen wrote:

It only triggers if the Combat Mode changes automatically. It doesn't trigger if you do it via commanding menu or scripting commands (e.g grp setCombatMode "BLUE" or grp setCombatMode "RED" doesn't trigger)

setCombatMode doesn't set the combat mode, it sets the "Semaphore"
CombatMode is combatBehaviour/setCombatBehaviour/setBehaviourStrong command

This is so confusing....

Ok i tested it on the development build 2.09.149122 and can't reproduce it.

EnableAttackChanged:

Correct, that EH is never called, apparently I forgot that one.

It only triggers if the Combat Mode changes automatically. It doesn't trigger if you do it via commanding menu or scripting commands (e.g grp setCombatMode "BLUE" or grp setCombatMode "RED" doesn't trigger)

Ok, i didn't know if this was expected behaviour.

UnitLeft:

It should trigger after the unit has a group (group of a unit should never be null)

EnemyDetected:

The event handler doesn't seem to trigger at all.

Currently the KnowsAboutChanged event handler triggers for more than just valid targets (those returned by targets/targetsQuery commands). For example see this comment: T161515#2281413

I don't think there are any other objects that can be a threat to (and thus engaged by) the AI...?

This problem has been fix, it was my microphone bluetooth

Remove all these start parameters, they either do nothing or hurt you. And noLogs specifically disables the logs that would let me see what's wrong.

Profiling branch has some tweaks (the driver of the towing vehicle needs to be using prof branch) that should fix this and make towing a bit smoother overall.

Fixed on dev branch and profiling

Fixed on dev branch and profiling

You could also try Arma's profiling branch, it gets early bugfixes maybe there is something fixed in there that caused crashes for you.
But I still have no idea what was causing your crashes so maybe probably won't help.

Arctis 7 Chat

There is a known issue on windows 10 with USB Headsets. Please try if using a different headset or speakers stops the crashing (I think it will)

Arctis 7 Chat

UCEERR_RENDERTHREADFAILURE (Exception from HRESULT: 0x88980406)

at System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
at System.Windows.Media.MediaContext.CompleteRender()
at System.Windows.Interop.HwndTarget.OnResize()
at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)

You get this error message popped up

ErrorMessage: File D:\SteamLibrary\steamapps\common\Arma 3\!Workshop\@-Hohenstaufen- Re-tex Pack\meta.cpp, line 2: '.Hohenstaufen': '\' encountered instead of '='

"The cloud file provider is not running" is the error message you get shown before the game exits itself.
Put that into google, its a Microsoft OneDrive issue.

I cannot diagnose game crashes without the actual crash report file.
Please follow this guide: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

No, not anymore

Arctis Pro Wireless Chat

Same, cannot reproduce.

No

-cpuCount=4 -exThreads=7 -malloc=tbb4malloc_bi_x64 -maxmem=16000 -maxvram=5812 -noLogs -nologs -cpuCount=4 -exThreads=7 -malloc=tbbmalloc
Remove ALL of these start parameters please.
Best case they do nothing, worst case they make stuff worse.
And definitely with -noLogs there are no logs of whatever might be going wrong.

Cannot reproduce.

I'd say thats intentional, manual input overrides cruise control.
Pressing normal Forward speed will make it ignore the cruise control limit and let you go faster, and pressing slow speed will make you go slower.
User input overriding cruise control is expected.

Any news about this?

Spot lights are perfectly functional lights (source: used one yesterday). As with any scripted light source, they need to be set up with the proper commands.

All particle affects are lost This bug never existed until lately so some Arma update broke it. Thanks for your reply anyway.

In T77584#2205279, @dedmen wrote:

https://forums.bohemia.net/forums/topic/140837-development-branch-changelog/?do=findComment&comment=3438862

This is quite a bit of work (maybe a couple days), for VERY little gain.
(Compared with all players) very few use savegames, even fewer will have particles happening when they save.
And overall its more of a minor un-niceness rather than something game breaking.

@dedmen Killzone_kid responded like this when asked in the BI forums about this bug.

Ok, seems to impact also mods and DLCs.

This bug seems to be specific to Vanilla 8 unit weapons squads (BLU,RED,GREEN). I tested with 8 unit recon squads or Western Sahara 8 unit squad and I didn't see that.

Cannot reproduce in vanilla. You're probably using a mod that breaks it.

In T164086#2294737, @LSValmont wrote:

Resolved, or wontResolve?

Resolved, or wontResolve?

Hey Neuromancer,
Thank you again for the feedback.

The issue with ED-1D Pelter is still (or again?) present, 3 years later now.
@Astaroth can you reopen this issue please?

Seems to be fixed now

Asking this because I’ve seen the exactly the same file posted by another user, who posted it before you

The most annoying thing about getting "stuck in rocks" is that, in a sequential tasks mission, one can be 90% complete with the mission and get stuck in a rock. Hours of game play end in failure because getting stuck means RESTARTING the mission from the beginning. THIS REALLY DOES SUCK.

yes it is bis