In T164521#2307664, @BIS_fnc_KK wrote:

An alternate syntax for the existing allGroups

not possible, nulars can have only 1 syntax

Mission is unavailable

Sorry. Uploaded the mission on FT.

In T164321#2300081, @AMark wrote:

I didn't see anything on that page that can help.

So did you make sure you have installed DirectX 11 and VC++ 2013 Redist packages, and verified the game data via Steam?

Where could I find a list of all the required drivers?

You just need the normal drivers needed for running a game. The GPU and Audio drivers are probably all you need.

Your new Windows is probably missing some software needed to launch the game.
Make sure you have installed all drivers (GPU, etc.), DirectX and VC++ 2013 Redist package.

In T164110#2296504, @dedmen wrote:

That's behavior not combat mode...

Not in engine.

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....

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

In T164086#2294737, @LSValmont wrote:

Resolved, or wontResolve?

You can't close it yourself. It will be closed by the devs once the bug is fixed.

In T164024#2293268, @TokyoCowboy wrote:

Sorry, this seems to be a CBA issue.

In T151907#2292766, @dedmen wrote:

If added, diag_getTerrainGrid should be removed

Your game/OS data might be corrupted. Try the potential solutions mentioned here:
https://community.bistudio.com/wiki/Arma_3:_Unusual_process_exit

Shameless bump. I also remade and reworded the ticket entirely.

@simao1234
Read this page.
https://community.bistudio.com/wiki/Arma_3:_Steam_Branches
The code for legacy 2.06 is: Arma3Legacy206

What is the problem? Your rpt (log files) are from several months ago, and there's no error or anything relevant in them.

And direction going precisely up/down together with normal up vector just doesn't work.

What if you simply do something like:

if (dir.x == 0 && dir.y == 0) {
   up = {1,0,0};
}

? Does changing the up manually not fix it?

Duplicate of T154293

There has to be some script side filtering anyways, as the event reports changes in knowledge about friendly and enemy units/vehicles. Its not only about enemy targets. Even civilian groups are receiving events about "targets".

So? Friendly units are targets too. I never said "enemies". Plus a simple side check is nothing compared to a config check to detect what the object actually is.

As all the non vehicle objects are already detected fully on first sight, they will be only reported once, so even in the current state the performance problem is not as much of an issue as it first seemed.

You still have to filter them out yourself in SQF, which is relatively slow. You're only thinking of those non vehicle objects, but your filter will still be in effect for actual targets too.
If the EH trigger is pre-filtered you don't have to do anything. The EH will only trigger for actual targets.

Yeah but my point was more from a performance POV than mere inconvenience.

In T161515#2281542, @dedmen wrote:

They don't check. 4.0 is max value, thats special, they are not checking.