Iceman, could I get an update whether this is working as intended or a bug? Thanks.

The issue is assigned to programmers internally so it is a bug and will be solved

Possibly related: Commands do not work on AI units in vehicle (such as enableSimulation/hideObject/disableAI)
http://feedback.arma3.com/view.php?id=21702

Issue in this ticket may of been "Driver" discovered by Wolfenswan:

• if(_x != leader _this && {!(isPlayer _x)} && {!("Driver" in assignedVehicleRole _x)}) then { //doesn't work, driver is cached

+ if(_x != leader _this && {!(isPlayer _x)} && {!("driver" in assignedVehicleRole _x)}) then { //works, driver isn't cached

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Should be fixed in current version. Issues caused by http://feedback.arma3.com/view.php?id=19246 will be solved in that bug. Marking this one as resolved. Thanks for feedback!

This seems to be the cause: http://feedback.arma3.com/view.php?id=19246

works for me on todays dev

Did you try several buildings? Some seem ok, while others are broken. It's the same for everyone on the server, too.

PS: The NPC/AI that was having this issue also had allowDamage false and enableSimulation false, in case one might be related.

Those uniforms do not work with civilian units either. My bet is on those uniforms being misconfigured or not finished rather than on broken command.

Oct 2015 - this issue is still broken.

This also affects the Seize module.

How such a ticket can remain "NEW" for more than one year? Amazing!

@PiepMGI - its beacuse they are not focused on basic, they are focused on new features (pretty useless) like car customization.... and off course Tanoa (before it will come out, i'll play 20 more maps from armahollic. Its pretty sad they work this way - they will never finish the game this way. So big potential, so much waste....

Completely agree with Etgo

Still broken

When defend module was released, the module worked without zeus. So it was only player vs ai, not player vs zeus.
And i think that it worked very well.

It is the description/in-game help which is broken.

It works by synchronizing the Curator game-logic (F7>Zeus>Game Master) to the attacking side. You can unpbo missions_f_curator.pbo in ARMA3\curator\addons to see how it's done.

Also the Defense module needs to be named "BIS_mission" and the triggers for the attacking side must be synced directly to the side logic, no Area logic in between.

Can you please fix this?

yes a fixing is needed because they were funny modalities to play and the are broken since almost 1 year as of now

Any chance this will be addressed in the next update?

Look at that Ticket: http://feedback.arma3.com/view.php?id=19056
I found why its not working.
We have to wait until they fix the BIS_fnc_isCurator function

It would be great if this issue could be resolved - I have a few Workshop missions that are dependent on this scripted capability - i.e being able to force the AI pilot of a heli to switch the searchlight on - via 'player action'. Apparently this used to work about a year ago in Arma 3 - but it subsequently became broken.

http://feedback.arma3.com/view.php?id=19544&nbn=2#bugnotes

I know... :(

I'll do a diag_log of these empty detectors prior to delete, and also a diag_log of the time-of-death of players and anything else relevant i can think of.

Any luck?

(you can also utilize the https://community.bistudio.com/wiki/logEntities command)

"Yes, with zero use of 'createTrigger' on server or client, there is still accumulation of 'emptyDetector' at [0,0,0]."

Do you, please, have any such test mission where this could be observed? (I&A uses triggers)
Or should just one simple MP scenario with many playable units and nothing else be enough to reproduce this?

No luck sorry.

I'll have one more poke at it today, will edit this note later on with results.

i don't even know if it is still occurring, have not done the MP server admin thing in some time.

Best way to observe it is find a busy MP server you have console access on. I have not been able to reproduce on my private dedi, and no longer own/run a public server.

EDIT:

I have doubts it is still occurring. Ran some tests on populated MP server and have not seen any orphaned triggers.

I just enter this code into console, private exec:

• spawn {

private ['_oTriggers'];
_oTriggers = [];
{

		if ((_x distance [0,0,0]) < 1) then {
			0 = _oTriggers pushBack _x;
		};

} count (allMissionObjects 'EmptyDetector');
diag_log str _oTriggers;
hint str (count _oTriggers);
};

If you can find a busy server (40+ players any gamemode) which has been up for 3-4 hours, and exec that code, that would determine whether its still occurring or not.

Back when I was working on it, I could reproduce in any gamemode, with/without scripted triggers.

BI scripts are located in some of the PBOs in the client Addons folder. If you unpack the PBO's, it is possible to use some text-search-all-files-in-folder (e.g. Notepad++) to find "trigger". The results of this approach will be less empirical and more exhaustive.

Do you what respawn type/settings were used in the scenario?
Thanks a lot

One more thing - any official modules or functions are used?

Really appreciate your help, thanks!

// Invade Annex
Respawn = 3; RespawnDelay = 4;
RespawnDialog = 0;

// Altis Life
respawn = BASE;
respawndelay = 10;

Occurs in both scenarios, dedi MP. I hazard to say it also occurs in King of the Hill although I have only tested in Altis Life and Invade Annex.

Could it be the "Logic" that attaches to a player on respawn? A "Logic" vehicle type also falls under "EmptyDetector" class.

From my BattlEye attachTo.log:

15.01.2015 12:56:08: NAME (IP:PORT) GUID - #0 4:2 Logic 2:1197 B_sniper_F -1 [0,0,0]

I would assume that Logic is just attaching to the 000 center of the player model, not world position. Perhaps if this logic gets created but the player is a null object at the time ... ? Speculation.

Just a curator module.

I might have time for one last attempt.

I'll do a diag_log of these empty detectors prior to delete, and also a diag_log of the time-of-death of players and anything else relevant i can think of.

This is indeed a bug, still.

KK, imagine if occasionally dead bodies were not getting removed, for instance if the player CTD'ed instead of disconnected the expected way, their dead body did not get registered properly in the allDeadMen array. That would likely be a bug, no?

Local triggers are just the same, except triggers also represent a 0.5s evaluation thread.

This seems another issue that emerges in MP that is very hard to reproduce in sterile session (and thus ignored).

Speculation: I imagine it has something to do with an unstable player disconnection, leading to an orphaned local trigger. On unstable disconnect, the trigger becomes persistent (escapes engine deletion). We can already see when a player disconnects, objects/vehicles local to the player remain in the session, passed back to the server.

EDIT: After a little while of close observation, it seems to have more to do with a death event than a disconnect event, and the accumulation occurs a few at a time. IE none for a little while, then 2-3 within a few seconds. Also occasionally see triggers get removed from nullPos. Can't glean much from the object data.

We also know that each player object does have a trigger attached by the engine, which--among other things--controls default proximity addActions (such as those seen when interacting with a vehicle).

In the meantime, (for others reading) this is a workaround to treat this bug, to run in a cleanup loop:

{
if ((_x distance [0,0,0]) < 1) then {

		deleteVehicle _x;

};
} count (allMissionObjects "EmptyDetector");

------

QUOTE Killzone Kid:

Client created triggers will transfer to the server when client leaves but those can be deleted no problem, just checked. Nothing unexpected here either.

If a scenario not once has the code 'createTrigger', should there be an accumulation of EmptyDetectors? To say that we CAN delete these engine-created accumulations, is a different discussion.

EDIT: There is a trigger created on server when using the function BIS_fnc_randomPos, as it uses BIS_fnc_worldArea which does create a trigger, however it is managed and does not accumulate:
...
if (isnil "hsim_worldArea") then {
...
hsim_worldArea = createtrigger ["emptydetector",_mapCenter];
hsim_worldArea settriggerarea [_mapSize,_mapSize,0,true];
hsim_worldArea
} else {
hsim_worldArea
};
...

So it can happen even without triggers created or scripts that could create them or modules (incl. Respawn)?

I've done some testing, but hasn't been able to achieve that so far :/

Yes, with zero use of 'createTrigger' on server or client, there is still accumulation of 'emptyDetector' at [0,0,0].

It is tricky to reproduce. I observe even with 50 players in the session running around killing/dying, that only about 10% of death events produce this orphaned trigger.

I tried to gather data on how the player died when it occurred, such as if they were in a vehicle, but that did not yield anything useful.

Perhaps if the player disconnects to the lobby during the death event? I'll give that a try later.

Perhaps also of note, this occurs in all common community MP scenarios. KotH, Altis Life, Domination, I&A, Patrol Ops, etc. I have not done any tests in Support to see if occurs in that gamemode too.

Hey! We'd definitely need more on this. Could you please attach or send me the mission, rpt and output from the allmissionobjects when such thing happens?

Regarding the EmptyDetector - do I get it right, that you create some on the client side, client disconnects, EmptyDetector gets transferred to the server, you attempt to delete it there but it's not possible, correct?

Does it happen reliably to you? Under what circumstances?

---

Regarding #smokesource and #destructioneffects - under what circumstances has the allMissionObjects returned these? Could you please provide more info - any mods used, config adjustments?

Thanks a lot!

oukej
Regarding the EmptyDetector - do I get it right, that you create some on the client side, client disconnects, EmptyDetector gets transferred to the server, you attempt to delete it there but it's not possible, correct?

Does it happen reliably to you? Under what circumstances?

It is more related to a player death event than a disconnect event.

No scripted triggers are created on the client. The engine creates this trigger at some point during the death and respawn process.

1. Player dies
2. ???
3. A chance that an EmptyDetector is created by the engine and it appears at [0,0,0].

Over the course of a scenario, they can build up to hundreds of these EmptyDetectors.

Reliability of repro is naturally difficult with these MP issues, though it does happen consistently, it is very difficult to predict exactly when one will occur. Many death/respawn events occur without this orphaned trigger, so what the exact circumstances are, I don't know.

As for where to start looking, have a look at any EmptyDetectors that are created engine-side in the death and respawn event.

EDIT:

I assume there is a trigger created on a player object when they are spawned. Is this trigger deleted/accounted for before the dead body is returned to the server, after a death event?

EDIT:

And we can remove these EmptyDetectors by periodically checking and deleting any EmptyDetectors at [0,0,0], however that is a different discussion to whether they should be accumulating in the first place.

Another interesting observation is that in a mission with not a single trigger, both server-side and client local, "EmptyDetector" exists and grows in number over time.

The specific problem here is that this is essentially an unmanageable, irrecoverable but identifiable use of resource, otherwise, known as a "memory leak".

This means that the server will have to be restarted over time.

#destructioneffects are not the same as craters. Craters are removable objects.

Deleting EmptyDetector, #smokesource and #destructioneffects objects only makes them unplottable on the map or resets to position [0,0,0], but they remain in the object space. Please check the histogram system text that the code produces. The numbers remain unchanged even after you relog, which means its not local.

There is no evidence of the server garbage collecting #destructioneffects and #smokesource. It simply builds up to astronomical numbers in a heavily populated MP server over time.

I'd appreciate proper investigation and less guesswork or flippant comments please.

Need more info about this ticket. Mainly what exactly is the problem here.

(allMissionObjects "") - (allMissionObjects "All")

This will return a lot of static objects that are map placed and cannot be removed like decals. On client it will also return tonnes of local objects, which are also terrain specific. Destruction effects like craters will remove themselves after sometime, looks like hardcoded too and are not available to be removed by deleteVehicle.

Client created triggers will transfer to the server when client leaves but those can be deleted no problem, just checked. Nothing unexpected here either.

Do you have a specific problem you are experiencing? Please do share. Otherwise I will go ahead and resolve this ticket as no bug.

Thanks

Sure, I will next time :)

Thank you very much! We greatly appreciate your effort.

Worked good for around 30minutes, but then it crashed again just when saving game (with savegame command + my own savegame function was running - worked stable before). Uploaded new crash dumps.

Exception code: C0000005 ACCESS_VIOLATION at 0126E6E4
...
Fault address: 0126E6E4 01:00E6D6E4 G:\Steam\steamapps\common\Arma 3\arma3.exe
file: WholeLottaAltis
world: Altis
Prev. code bytes: C4 38 C2 0C 00 8B 4C 24 50 8D 54 24 28 52 8B 01
Fault code bytes: FF 50 04 8B F0 85 F6 75 0C 8D 44 24 28 8B CB 50

Registers:
EAX:00000000 EBX:0254F0A8
ECX:6272F880 EDX:0254F05C
ESI:00000000 EDI:00000000
CS:EIP:0023:0126E6E4
SS:ESP:002B:0254F030 EBP:FFFFFFFF
DS:002B ES:002B FS:0053 GS:002B
Flags:00010246

Added new 7z with 3 more crash dumps from 1.40RC. Some could be when exiting the game, the newest was suddent crash during playing. FPS started to stutter while fps_diag still showed 68FPS, then in seconds sound cut off and game froze.

Hello, is it possible to create new tickets for crashes separatelly? It's becoming a little messy. Thank you a lot.

Hi, sure I will. :)

New crash with official build.

Mods: @SaOkNew
Extensions:
Distribution: 0
Version 1.38.128937
Fault time: 2015/01/26 20:26:01
Fault address: 58363BED 01:00142BED C:\Windows\system32\nvwgf2um.dll
file: WholeLottaAltis
world: Altis
Prev. code bytes: 8B 49 18 89 45 08 8B 51 04 8B 41 08 85 D2 74 05
Fault code bytes: 89 42 08 EB 06 8B 55 08 89 42 04 8B 51 08 8B 41

Registers:
EAX:0000016A EBX:00000001
ECX:3BD48074 EDX:00000001
ESI:1D69C110 EDI:4C5792E0
CS:EIP:0023:58363BED
SS:ESP:002B:1F1DF9AC EBP:1F1DF9B8
DS:002B ES:002B FS:0053 GS:002B
Flags:00010202

The PhysX crashes seem to go away after disabling animals in official build. I let you know if the crashes still appear while having animals off, but so far looks good.

Still suffering the physX-crashes:
Mods: @SaOkNew
Distribution: 0
Version 1.29.127147
Fault time: 2014/09/12 21:38:35
Fault address: 555E21CB 01:001511CB G:\Steam\steamapps\common\Arma 3\PhysX3_x86.dll
file: WholeLottaAltis
world: Altis
Prev. code bytes: 85 C0 74 1D 8B 50 40 F6 42 4C 01 75 14 8B 40 60
Fault code bytes: F6 40 2C 01 75 0B 51 50 57 E8 97 FF FF FF 83 C4

Registers:
EAX:00000000 EBX:84129E60
ECX:793D9980 EDX:734981E0
ESI:7A15EE48 EDI:70172760
CS:EIP:0023:555E21CB
SS:ESP:002B:024AE1DC EBP:024AE1F0
DS:002B ES:002B FS:0053 GS:002B

Flags:00010246

I also experience a lot of game crashes lately. I've also jumped between DEV and stable and same crash experience. Will try to help share more details in future

I have had two crashes to desktop recently at the end of the mission briefing when clicking on "Continue"

This is in 1.28 stable branch. RPT Logs submitted.

Getting much PhysX crashes in the DEV-build even with animals set off. In official build, toggleing animals off seemed to make the crashes more rare.

Attached dumps.

Hello,
we applied a fix on rev. 128455, could you please try it?

Had a small bug, there might have had some animals spawned when those DEV-build crashes happened. Will let you know if crashes appear with animals set off again.

Edit: Nevermind, just crashed again and there was no animals.

Official build have been stable, but tried DEV-build today, crashes in 3s-1min from mission start (WLA SP). Attached dumps.

Exception code: C0000005 ACCESS_VIOLATION at 00EA960B
graphics: D3D11
resolution: 1920x1080x32
Addons:
...
Mods: @SaOkNew
Distribution: 0
Version 1.37.128434
Fault time: 2014/11/27 20:11:49
Fault address: 00EA960B 01:00AA860B G:\Steam\steamapps\common\Arma 3\arma3.exe
file: WholeLottaAltis
world: Altis
Prev. code bytes: CC CC CC CC CC 8B 44 24 0C C1 E0 05 03 44 24 08
Fault code bytes: 66 8B 4C 41 30 8B 44 24 04 66 89 08 C2 0C 00 CC

Registers:
EAX:FFFF42CA EBX:00002360
ECX:7C901600 EDX:7C901600
ESI:71BC6040 EDI:0254F6A0
CS:EIP:0023:00EA960B
SS:ESP:002B:0254F638 EBP:00005F40
DS:002B ES:002B FS:0053 GS:002B

Flags:00010287

note: Minidump has been generated into the file C:\Users\Santeri\AppData\Local\Arma 3\arma3_2014-11-27_20-04-23.mdmp

Thank you, high command is reproduced and under fixing.

Thanks, great to hear. :)

There is also arma3.exe crashes coming randomly when in map view (usually High Command enabled). Attached dumps.

Another map crash, also had High Command enabled.

Just shot CSAT AA-vehicle with titan and game crashed instantly when the rocket hit it. There was also no launcher locking sound effect before that.

Mods: @SaOkNew
Distribution: 0
Version 1.25.126281
Fault time: 2014/08/01 17:00:51
Fault address: 6A4D4627 01:00033627 C:\Windows\system32\d3d11.dll
file: WholeLottaAltis
world: Altis
Prev. code bytes: 5E 59 C3 CC CC CC CC CC 8B FF 57 8B F8 8B 47 20
Fault code bytes: 8B 40 0C 8B 08 50 FF 51 10 83 67 20 00 8B 47 10

Registers:
EAX:00000001 EBX:0C192650
ECX:28657618 EDX:00501761
ESI:28531A40 EDI:28531A44
CS:EIP:0023:6A4D4627
SS:ESP:002B:1C50FE08 EBP:1C50FE14
DS:002B ES:002B FS:0053 GS:002B

Flags:00010246

note: Minidump has been generated into the file C:\Users\Santeri\AppData\Local\Arma 3\arma3_2014-08-01_16-53-32.mdmp

Played days only the official build and got only one physX crash (in maybe near 6-8h playtime, mostly jumping between editor and mission start). Changed to test the todays DEV-build and crashed after 10 seconds. Seems like it crashes most likely when units, vehicles or animals are spawned.
Mods: @SaOkNew
Distribution: 0
Version 1.25.126334
Fault time: 2014/08/05 19:08:44
Fault address: 659C21CB 01:001511CB G:\Steam\steamapps\common\Arma 3\PhysX3_x86.dll
file: WholeLottaAltis
world: Altis
Prev. code bytes: 85 C0 74 1D 8B 50 40 F6 42 4C 01 75 14 8B 40 60
Fault code bytes: F6 40 2C 01 75 0B 51 50 57 E8 97 FF FF FF 83 C4

Registers:
EAX:00000000 EBX:5510D460
ECX:56A65D80 EDX:58FB54A0
ESI:58FA7708 EDI:378FA520
CS:EIP:0023:659C21CB
SS:ESP:002B:0208E1DC EBP:0208E1F0
DS:002B ES:002B FS:0053 GS:002B
Flags:00010246