Repro adjusted with big visible text on the map:

	testcenter = getPosWorld player;

In T170754#2423769, @dedmen wrote:

It looks a bit stretched/squished in the center display too. But not as much as the others

Yeah, this is a long going bug in the game, since at least Arma 2, probably even Arma 1 or even OFP. I think its caused by messing with your FOV in .Arma3Profile by changing either fovTop or fovLeft and if they're not 4:3 and 3:4, map icons become squished. Here is how I have it at 1080p with

fovTop=0.75;
fovLeft=1.3333334;

Check parameters, maybe you have your mods listed there in "Mods" or "Server-side Mods"

Related ticket to close once this one is done: T128006

Since Arma 3 v1.96 this command returns both driver and gunner units if the UAV is controlled by 2 players.

Can be set as resolved.

Found a hack to fix stuck remote control trough UAV terminal:

I recently had an issue where buildings failed to receive scripted (HandleDamage-returned) damage for JIP players. I chose some building far from the action, damaged it, restarted the game, rejoined and it had wrong damage numbers. My guess was that game mixes up which entity should get which damages, maybe it does it the same with variables. It was pretty reproducible last time I observed it, I'll make a ticket some time.

Does deleting and re-creating the marker again helps to bring it to foreground?

On a side note, log function shows group have fade and scale close to 0.5 but not exactly. They're fine on next frame, looks like ctrlCommited return true one frame before animation actually finishes.

To fix this issue, display your texture in normal UI somewhere before using it inside ui2texture. I have the ticket about this exact issue @ https://feedback.bistudio.com/T170766

The use case is displaying high resolution textures in small sizes to avoid ugly aliasing.

What about having it as procedural texture?

Please let us know how it went, I had similar issues with streaming objects, yet to make a repro and ticket so I'm very interested in your case.

Does this happen for JIP players and not players who were on the server at the moment of "setVariable" use?

@Sergey_rus42 What is your UID? Also, sights are per weapon, you probably bought it for certain weapon.

Another attribute name idea, same property name, different values:
mipmap='#2'
mipmap='32px'
mipmap='0.04'
or usemip or just mip as original idea had it.

mipmap='2'
mipmaph='32'
mipmapui='0.04'
More name ideas

This error also happens if you try displaying .paa pictures without mipmaps inside inner ui2texture display.

Temporary workaround without need to draw inner display anywhere on UI:

I also had a need for such feature and found a hacky workaround. The way to solve it is to attach through a intermediary local object (createVehicleLocal)

Yes its all already possible, its a question of convenience of doing it with a single command.

Example:

_group addEventHandler ["UnitKilled", {
	params ["_group", "_unit"];
	if(units _group findIf {alive _x} < 0) then {
		// Everyone is dead
	};
}];

In T170658#2413276, @Xeno wrote:

Samatra, there is already a killed EH.

This is about an event handler only firing when all units in a group are dead.. Needed for AI groups in Co-op missions for example.

Currently you have to constantly iterate over all units of a group to check if all units are down.

So virtually like the empty group EH which only fires when all units in a group are deleted.

I'd suggest "UnitKilled" event handler instead. There you can check if everyone is dead as well doing something on individual unit death.

In T165080#2413236, @BIS_fnc_KK wrote:

Cant tell what is scripted and what is vanilla on that video. Can you make an Eden repro showing the problem?

In T165080#2413212, @BIS_fnc_KK wrote:

It cannot be just fixed as it may break missions where people used workarounds

In T165080#2413210, @BIS_fnc_KK wrote:

is this the same issue? https://feedback.bistudio.com/T169976

I think that drawEllipse/drawRectangle shapes not being rotated along with the map is a bug. These are map shapes, no display shapes and their coordinates and dimensions should be relative to the map. I'll have a fix in the mission but this should be addressed on engine level if you ask me.

Did a brief testing, works good.

Tested, works great!

Did some testing, works as expected so far.

Tested seemingly all possible scenarios, including MP cases, new alt syntaxes all work perfectly, no issues found.

Did some tests, including MP with different locality, no issues found. Works good!

Did some short tests, works great so far, no issues in MP with JIP players.

Looks great in game under different lighting, fits other vanilla content great, as expected with it being part of original vanilla content.

nils for out of bounds _index might not be really needed as there is

vehicle magazinesTurret [turretPath, includeEmpty]

to get empty magazines so you can find the count yourself.

Maybe its time to finally fix this command. Lets be honest, 99% of usages of this command are to get currently loaded magazine. Who needs *random* magazine ammo count? Lets make this command prioritize loaded magazines.

An idea for a better name for the command: isEqualRef to be in line with existing isEqualTo

What I propose after more tests:

So in total:

1. You can have LDs working in seats without any units in them as long as there is unit somewhere in the vehicle (and turret is local to them maybe?)
2. You can have LTs from both turret LD and personal LD, but turret LD will delete after a bit.

In T167317#2351973, @BIS_fnc_KK wrote:

This is what I thought, that only current target matters therefore whatever unit tracking now is what should be returned, for simplicity and consistency, no?

In T167317#2351957, @BIS_fnc_KK wrote:

So when player is tuned out and using personal LD it would return that target and if turned in and using vehicle LD it would return that target, sounds consistent?

Here is repro to have two laser targets at once which this change to scripting command won't cover:

Right now:
laserTarget playerOnFoot => Target if laser designator is fired
laserTarget playerInVehicle => Always null
laserTarget vehicle => Target if primary turret designator is fired

Just tested that, it is indeed a case, you can have both laser designator on a turret, then turn out and use your own laser designator, both laser targets will exist at the same time and only one will be accessible after proposed changes to the command.

If we are to change original command behavior, then I would also make laserTarget iterate through turrets to find first laser target, so you can safely execute it on Strider and return laser target from commander.

Yes, this will make all laser targets accessible.

In T167317#2351937, @BIS_fnc_KK wrote:

What about querying a particular unit in the vehicle, does it work for different gunners with laser targeting devices in the same vehicle?

No it doesn't, laserTarget always returns null when executed on a unit that's on in turret with enabled laser designator.

Fixed as of 2.10, please set to resolved.

In T150204#2326593, @kju-PvPscene wrote:

@SaMatra please make a new request - otherwise this will get missed

Would be great if systemTime accepted time offset argument so we can easily display server time. The idea is following: Get how much your time is offset from the server and feed the number of hours as arguments into the command. Yes, you can calculate all that with SQF, but when you need to display timer constantly, this eats a bit of CPU time when it could be handled by the engine very efficiently.

<Array> = systemTime <Number>

Still needs a fix

Sure, this can work.

Are new commands isMissionProfileNamespaceLoaded, missionProfileNamespace and saveMissionProfileNamespace result of this ticket? If so, how are they connected to the mission itself? Through the mission filename? If so, then it won't fit for our purposes because we use different mission filenames for different communities (to avoid mission re-download when switching servers) like:
KingOfTheHill_by_Sa-Matra_for_CODE4.Altis.pbo
KingOfTheHill_by_Sa-Matra_for_ARMASU.Altis.pbo
but we need a namespace accessible between these different mission files but within our mission's "universe".