Honestly, this is awful. I believe players enjoyed this feature. At bare minimum, give server devs the option to enable or disable it as they wish. As obviously at this point we are quite used to aerial vehicle radar, not everyone will agree with this choice.

Yes people did grow quite comfortable with the All-Seeing-Eye. I for one prefer it this way, as it allows much more flexibility with ground vehicles, when a guy with 12000 view distance in a hummingbird cannot spot a moving quad bike across the island, via the little radar squares.

Was thinking about this again today. If BIS engine code or internal scripts makes use of this command there may be a reason to not (yet) provide clients the ability.

Please add this command, to remove it. If not possible to prevent re-writing of the code, then we need the ability to simply remove it after use.

Upvoted.

AH-99 can score 24 main battle tank mission kills* without needing to re-arm. DAGR should be equivalent power of DAR at best, not ATGM HE-ATs.

Repro:

Put crewed MBT T-100 on island.

Put AH-99 4-5km from the MBT. Climb to altitude to gain line of sight on the MBT. Gain lock. Fire DAGR. Crew will dismount and a mission kill is scored. Repeat 24 times.

Solving this issue can be done with a 2nd variant of the AH-99 with the pylons some want, then nerf the DAGR down to realistic effectiveness.

Dictionary:
mission kill (plural mission kills)

(military, slang) An attack or damage inflicted by a weapon that does not destroy a military vehicle but results in it taking no further part in its intended mission.

I am unable to call it via server script now.

_baseArsenal = [box1,box2,box3];//names of objects in editor
{
["AmmoboxInit",[_x,false,{true}]] call BIS_fnc_arsenal;
} forEach _baseArsenal;

However this command works when looking at the box:

["AmmoboxInit",[cursorTarget,false,{true}]] call BIS_fnc_arsenal;

Entering it into the init field of an object does not work (for me at this time):

["AmmoboxInit",[this,false,{true}]] call BIS_fnc_arsenal;

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.

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

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.

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.

Fixing VON should have been a very high priority task.

Note I say should, as its been broken for so long that the ArmA playerbase has already been dented by such a deteriorated ability to socialize ingame. I personally have a friend who stopped playing for good, after being shouted at to "Get off side! its lagging! shut up!".

Any (good) MP game designer knows how important it is to be able to communicate with one another, in terms of player retention and game popularity.

'The social' is a very important principle to nurture in game design, and a broken VON really impacts beginners and newbies from getting connected and socializing in the community.

Sure us 'vets' know about Teamspeak and related plug-ins. But I first entered 'the community' through VON chat in the beta, before it was broken.

For 18 months now, the state of VON and in-game CHAT actively discourages communication between newbies more experienced members. Try to speak on VON, no one can hear you and you get yelled at. Try to type, and BattlEye swallows up your text with its systemChat spam.

We are two years after game launch, so it's history now. Still worthy of a fix, but the community has already been heavily impacted.

I say this as someone who has 'been there done that' as both a server admin (christmas day 2013 there were over 200 players on our community servers), and as one of the core developers of Invade & Annex with AhoyWorld.

Regards,
Quiksilver

Just a note, you can actually overcome the stuttering VON on side/global, simply by transmitting for upwards of 30 to 60 seconds.

Cliffs:

The more you use it, the clearer it gets.

Small audit of current weather issues, 15/06/2015, 1.46:

Summary:

Overcast sync still the big one as far as issues. Time to sync is one part, the other part (a bigger issue) is clients having high overcast value but the clouds do not reflect this value.

setWind / wind / windRTD appears to be working fine, fully synchronized between server and client. No issues.

setOvercast is borked still. Client can have high overcast value but clear skies, and time that client overcast value takes to catch server value is too long, by 10x.

overcastForecast appears to be working okay locally, but not synchronized in the same way in MP. See KKs data above for more detail.

setRain / rain appears to be okay for connected clients though I have not tested reconnection issues. Setting rain on the server will correctly be propagated to connected clients.

humidity. Humidity value drops way too fast for realistic simulation, and is not representative of actual humidity. If its raining, humidity = 1. If its not raining, humidity = 0.

windDir works fine.

setWindDir can stuff up vector magnitude wind values, and you will end up with stronger/weaker wind by using setWindDir.

setWindForce / setWindStr / windStr require more documentation in the wiki before I can assess if they're working or not. I can have a wind blowing at 5m/s using setWind, but windStr will be 0. What unit of measurement is windStr using?

setGusts / gusts. Local. Setting value on server in dedicated has no effect on client gusts value. Also more documentation is needed, as I cant see any environmental change with high gusts value.

setFog / fogParams syncs fine on connected clients, I have not tested connectING clients yet. I may be wrong with this, will update in a day or two after next round of testing.

fogForecast. Seems to work fine for connected clients.

setWaves / waves. Local. Server does not broadcast waves value to client.

setRainbow / rainbow. Local. Server does not broadcast rainbow value to client. Client starts with default rainbow value of 0.35 and setting it on the server does not change the client value by itself, requires some PVEH fiddling.

setLightnings / lightnings. Local, in MP server does not broadcast to the client.

setSimulWeatherLayers has strange and irreversible effects. Eventually after enough fiddling, only high level stratus clouds will form, no low level cumulus clouds will appear regardless of overcast value.

simulWeatherSync causes some lag. There was another issue, ill update this once I recall it.

nextWeatherChange shows erratic behavior on the client in dedicated server, with the number changing quite frequently and illogically. See KKs data above.

forceWeatherChange seems to work to patch setOvercast/overcast issues by refreshing the Simul Weather library, but of course has the nasty stutter. If we are updating weather conditions gradually (small change every 5 minutes) then this is unacceptable.

Will update this post once I clarify a few more things.

Re the minefield drawing.

There is no evidence in the code that any attempt was made to limit it by side/faction.

Example from the BIS_fnc_drawMinefields:

_missionMines = allmissionobjects "TimeBombCore";
if (count _missionMines == 0) then {_missionMines = allmissionobjects "MineBase";};
_dis = 0;

{_dis = _dis + ((position _x) distance [0,0,0]);} foreach _missionMines;

^ All mission objects 'timeBombCore', not (detectedMines SIDE).

Also, createMarker global is used, so regardless of what faction you are on, you will see where all the minefield markers are.

Regardless of intentions, the code indicates that the function author thought all mines should be revealed to everybody.

---------------------------------

			{
				_cluster = _x;
				_clusterCount = count _cluster;

				//--- Find cluster center
				_avgX = 0;
				_avgY = 0;
				{
					_pos = position _x;
					_avgX = _avgX + (_pos select 0);
					_avgY = _avgY + (_pos select 1);
				} foreach _x;
				_pos = [
					(_avgX / _clusterCount) - (_avgX % 5) + (_avgY % 1),
					(_avgY / _clusterCount) - (_avgY % 5) + (_avgX % 10)
				];

				_avgDis = 0;
				_maxDis = 0;
				_maxMine = objnull;
				{
					_dis = _x distance _pos;
					_avgDis = _avgDis + _dis;
					if (_dis > _maxDis) then {
						_maxDis = _dis;
						_maxMine = _x;
					};
				} foreach _x;
				_maxDis = _maxDis + 10;
				_avgDis = (_avgDis / _clusterCount) + 10;

				//--- Create marker
				_marker = createmarker ["bis_fnc_drawMinefields_" + str (["bis_fnc_drawMinefields_counter",1] call bis_fnc_counter),_pos];
				_marker setmarkerdir ([_pos,position _maxMine] call bis_fnc_dirto);
				_marker setmarkersize [_maxDis,_maxDis + (_maxDis - _avgDis)];
				_marker setmarkercolor "colorred";
				_marker setmarkershape "ellipse";
				_marker setmarkerbrush _markerShape;
				bis_fnc_drawMinefields_markers set [count bis_fnc_drawMinefields_markers,_marker];

				_marker = createmarker ["bis_fnc_drawMinefields_icon" + str (["bis_fnc_drawMinefields_counter",1] call bis_fnc_counter),_pos];
				_marker setmarkertype _markerIcon;
				_marker setmarkersize [1,1];
				_marker setmarkercolor "colorred";
				bis_fnc_drawMinefields_markers set [count bis_fnc_drawMinefields_markers,_marker];
			} foreach _mineClusters;
		} foreach _allMines;

onEachFrame? yikes!

My guess is one of the Devs has bad RL family experience with land mines and would just rather they weren't in the game, and so put a while TRUE loop in the MP framework to reveal all mines and thus prevent mine-related deaths ... A subtle nudge to scenario designers to follow the Geneva Conventions? :)

https://community.bistudio.com/wiki/BIS_fnc_drawMinefields

//--- Script already running - terminate and send command to refresh the loop

^ No allowance to terminate the loop. The function just updates the positions for the persistent A3 Geneva Loop.

Some documentation that may support it is intentional to prevent scenario designers from disabling the drawMinefield loop (note the last line):

Placing explosives
Explosives and mines placed by Zeus have a special behavior:
All selected explosives can be detonated by pressing [End].
Explosives are instantly revealed to everyone who's on the same side as Zeus.
Approximate minefield areas are visualized on the map for everyone.
Anti-Personnel (AP) mines are banned by international laws of war. Use them with caution!

https://community.bistudio.com/wiki/Arma_3_Field_Manual_-_Zeus

Moricky please! This Geneva Loop is idealism, not simulation.

Wow! The implications are profound. Well done!

I do appreciate Xenos humor on the issue :) how prophetic his words

This is not necessarily--only--a MP locality issue.

I have seen, as a mission designer/scripter/server admin, this issue affect server<-->server as well.

A rough guide to repro:

1. create conditions: write a really nasty piece of code that spams your rpt hard and creates huge file in short time.

2. spawn vehicle: using createVehicleArray at a bis_fnc_randomPos.

3. spawn units: similarly, assign to crew seats and move them in to the spawned vehicle.

Positive confirmation of the above on any vehicle with crew seats. Off the top of my head, I have seen the issue with armed MRAPs, MBTs, and WY-55 Hellcat, though I am confident it would work for any with crew seats.

--

Does it need to be in a MP environment? Unknown. The point of this post is to mention that I have seen AI spawned on the server, be afflicted by the same issue when trying to enter a server-spawned vehicle.

Just to elaborate on this issue:

It appears to only affect vehicle non-driver crew seats.

ie.

On a tank: It can affect Gunner position, possibly Commander.

On MRAP: It can affect Gunner position, although rarely seen.

On Transport Helicopters: It appears to be limited to co-pilot seats and door-gunner seats.

On attack helicopters: I have not seen the issue on attack helicopters such as the AH-99.

So yeah, vehicle crew seats.

The UH-80 Ghosthawk is especially susceptible to this bug.

It also appears related to multiplayer 'de-sync'.

The mounted weapon light is indeed far too weak, and limits scenario flexibility. Night time scenarios is either NVG or go home.

Modern weapon lights far brighter.

https://www.youtube.com/watch?v=2aOlrRrD-LQ

Pretty much a Hatchback Sport headlight mounted on the gun.

Is the reason why this is not fixed more related to the 'light goes through walls' issue? If so then that does make sense, but this should be made clear to us.

Can this be marked as resolved too? Sound is different inside now.

From the biki:

In Arma 3 this command is disabled since "UNCONSCIOUS" lifeState doesn't exist in Arma 3

cliffs:

Ignore/dont use setUnconscious unless/until BI implements proper functionality.

I wouldn't mind a functional lifeState BOOL which we could manipulate, instead of using setVariable for incapacitated states.

If BIS does does not expect or intend setUnconscious to work, it's not a bug. Many scripting commands go back 8-10 years and do not work as expected anymore, if at all.

Can I ask ... Has lifeState/setUnconscious ever worked at all? If not, then it seems crazy to rely your scripts on these unfinished/barely implemented engine functions.

It doesn't strike me as a bug, just an unfinished/incomplete feature for ArmA 3.

What do you expect to happen to the player if that state returns true?

Fact is there is no unconsciousness simulation/advanced wounding system, so it would do nothing even if it did work.

Any update on this?

Overcast synchronization in MP is much better in 1.48, from preliminary check. Good job!

setWind / wind / windRTD are fine.

Gusts still local.
Waves still local.
Rainbow still local.
Lightnings seems fine, good work!
Haven't checked fog.

windStr / setWindForce / setWindStr not sure if these are obsolete or how they fit into the picture.

speechless :)

Can provide more info on the issue and how it was fixed? Quite curious. Could not figure out if it was a uiNamespace issue, a client issue with Simul Weather, or ...

Not just players, AI will also cause wall to collapse if killed beside wall.

This issue deserves more attention as it is quite immersion breaking and detrimental to urban combat, to have walls falling over onto players without legitimate cause.