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

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.

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.

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

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.

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.

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

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

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

Really appreciate your help, thanks!

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.

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.

"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?

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)

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.