What about https://community.bistudio.com/wiki/unitAimPosition

With Default Rifleman ("Rifleman" in EDEN) it works:
https://imgur.com/EVYsssu

Should be fixed in rev.149837

its fine, reproed, but it is weird indeed

That's weird. It works for me.

Got it. Try with default rifleman

Here a image: https://imgur.com/OwtesFi
No mods, map Altis, unit "B_Soldier_A_F".

I ran your repro it returns player object

Oo thank you so much

I tested in 2.11.149816 and it's not fixed, still have the problem.

Should be fixed in rev.149836

<Vehicle> laserTarget <Turret> should be doable

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?

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:

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?

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

Just thought about a case, what if turret has laser designator but player can also turn out and use their weapons as FFV turret and use their personal laser designator?

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.

Works fine in 2.11, could you please confirm this works on dev? @keel

Yes, this will make all laser targets accessible.

So would fixing that be sufficient?

Should be fixed in rev.149832

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.

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

Should be fixed in rev.149831

Fixed as of 2.10, please set to resolved.

Unable to reproduce issue 2 anymore too... weird.

@dedmen Please let me know if there is any chance this problem gets fixed. Thank you!

quite some time ago

My mistake. I meant to say it worked fine quite some time ago. I'll create a new ticket for the current issue.

I've heard that getting downed, and then reviving also clears this bug... which isn't a fix, but a workaround.

After looking into it, I can tell you that this is not a bug, this has been done deliberately in the code to have HC stand out for some reason. On top, changing this behaviour may break not only engine handling but existing missions where people might have used this peculiarity to identify HCs. In short is a won't fix. If you really need to have owner of the headless client, send it via param with callback.

Additionally, I have a white dashed circle just below my crosshair with a translucent grey background in the middle of it. It looks like a bombing reticle. It's part of the same system. I tracked it down to one of the first two functions in: .\config\ui\hudShared\shared.hpp I didn't have time to go through it with a fine tooth comb, but when I comment out any of the first two functions, it just breaks the game (as expected).

It used to work before but not anymore.

I just tested it on 2.08 and there is no difference, delay doesn't work in this scenario. Please make another ticket as I am going to close this one as resolved

If this is confirm to happen on all missions and not only in your particular mission setup then I hope devs can look into it and resolve it.

In T123940#2351271, @BIS_fnc_KK wrote:

In T123940#2351226, @celticalliance wrote:

Just tried the Respawn vehicle module after the mentioned fix and I can confirm vehicles do respawn every time now, but I think there's a new issue now. The delay before the vehicle respawns doesn't work. Right now every time you reach the abandoned distance the vehicle does respawn but not with the delay you have set. It just respawns immediately.

Repro please, concrete module setting, concrete actions sequence, expected result vs actual result

@veteran29 thank you, kind sir

Ok issue 2 cannot repro with spawn or without it works as expected

@veteran29 I must have looked at it dozen of times and couldn't see it. A typo! Issue1 is sorted, gonna investigate issue 2

In T123940#2351226, @celticalliance wrote:

Just tried the Respawn vehicle module after the mentioned fix and I can confirm vehicles do respawn every time now, but I think there's a new issue now. The delay before the vehicle respawns doesn't work. Right now every time you reach the abandoned distance the vehicle does respawn but not with the delay you have set. It just respawns immediately.

Could you provide concrete repro steps for both issues?

There seem to be two issues: