Having allDisplays return in correct order would work for me. What I meant by topmost was the rendering order and I thought this would be same as input focus. The reason I need the topmost display is so that I can add new controls to it via ctrlCreate so that those controls wont get hidden behind UI elements from other displays

The game already has destroyable doors, they are glass doors. So I thought maybe allowing wooden doors to break wouldn't be such a big task.

Maybe technically so but practically its collision too

I tried with the two EHs but this code did not prevent the tigris from shooting my pawnee:

In T178591#2559564, @dedmen wrote:

Newtarget is not feasible.
Target is already detected before its known. NewTarget triggers, while nearTargets still returns empty list.
Then when unit becomes known, it appears in nearTargets, but NewTarget wouldn't trigger, because the target has already been in the list, it was just updated. And for that we already have KnowsAboutChanged.
Looks like a won't do.

In T178591#2558121, @dedmen wrote:

You're writing about new command. But all I see is new eventhandler?

Dedmen can you please explain why it's not possible? Just so I know not to make impossible feature requests anymore :D

In T173671#2473864, @dedmen wrote:

You already have it. You posted it above
vehicles select { (_x iskindof "AllVehicles") };

If you want to filter further for driveable/manable, you may want to also check for enableSimulation, and whether there are any crew seats available at all (Don't know how UGV/UAV behave in that regard)

sorry no repro, was really random thing

ok, can we then get a command that returns only driveable/manable vehicles?

I have 32GB RAM
and 11GB GPU mem

In T167202#2349853, @BIS_fnc_KK wrote:

Why do you have 2 dll processes?

stack trace would also be good with this, with variables also. like in diag_stacktrace

Example of what kind of error dialog could be achieved by this feature:

In T161588#2250189, @BIS_fnc_KK wrote:

Tested your example with join and joinSilent, the result is identical, group gets deleted

If you empty the group from units with deleteVehicle command the group does not become null, but if you do it with joinSilent the group does become null. So there is this inconsistency with behaviors between those two commands. So I thought it might be a bug

In T160224#2225214, @BIS_fnc_KK wrote:

rev 148073

Also, what you are doing makes no sense, I mean saving mission config in profile namespace, same as saving display for use later. Mission config exists only while mission is running. New mission, new config instance. On top profile namespace is serialized and loaded on game start. way before any mission is started, so mission config saved to profile namespace will give you exactly nothing after you left mission.

This ticket does not actually show the crash which I experienced because I was unable reproduce it in a new mission. Instead it shows how testVar failes to load from "cfgTestSave" and is null. Trying to use this null variable probably is what lead to crash