rev.149874 fullCrew output is extended

Look, unassignVehicle unassigns unit role and unit diembarks
leavevehicle unassigns vehicle from every member of the group and units disembark, aditionally leavevehicle un-addVehicle from the group

atm its bit hard to tell with the missing scripting commands for the getters - once these are available, it will make it easier to debug and test the current behavior

@BIS_fnc_KK what does https://community.bistudio.com/wiki/unassignVehicle do differently?

This issue only exists in the NATO parade uniform, looks it lacks camo3 selection in the model unlike other models (CSAT, AAF, LDF uniforms).

Also the disembark happens not straight away. Command unassigns the crew from their vehicle positions then after a bit they disembark. IMO looks like intended

I cannot see explicit order to disembark anywhere so it is probably the result of the effect of removing vehicle from the group use

Yeah that doesnt make sense.

one removes all assigned vehicles

rev. 149858

There is a issue specifically with Intel graphics devices, we have a fix prepared that will go out in profiling branch v2 in a few hours: https://forums.bohemia.net/forums/topic/160288-arma-3-stable-server-210-performance-binary-feedback/

There is a issue specifically with Intel graphics devices, we have a fix prepared that will go out in profiling branch v2 in a few hours: https://forums.bohemia.net/forums/topic/160288-arma-3-stable-server-210-performance-binary-feedback/

Thank you I can see what's wrong, It has been fixed internally and will be included in a future hotfix update. Quickest way to get the fix is to get https://forums.bohemia.net/forums/topic/160288-arma-3-stable-server-210-performance-binary-feedback/
It will be in v2 which will be released in a few hours

This seems to be an issue caused by Intel graphics devices, we are pushing a fix for it to todays profiling branch v2 https://forums.bohemia.net/forums/topic/160288-arma-3-stable-server-210-performance-binary-feedback/

We are pushing a potential fix to todays profiling branch v2 https://forums.bohemia.net/forums/topic/160288-arma-3-stable-server-210-performance-binary-feedback/

Please follow this guide in order to get us the information that we need: https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

Profiling branch today

next dev update probably

When rev.149837 will be on Steam?

rev 149852

It has also just occurred to me that there exists instances of multiple simultaneous types of FCS systems being employed for a single weapon/unit, for this reason the Task is edited as follows:

For clarity, I'll be using example cases (numbers are not exact, but demonstrative) for such scenarios for both the unitAimPosition command and this one; the ones where they'd provide an identical result, or one that can extrapolate an identical result are in bold underline.

rev. 149851

unitAimPosition is for finding the point on a unit's model that AI will aim at. This request is for finding the point in space a vehicle's FCS is currently trying to aim at. There's a little overlap in the 0 and 2 cases, but the other cases are well outside what unitAimPosition can provide - it's coming at it from the opposite angle.

That would be so useful, to prevent physics bugs and even decreasing the negative performance impact of having many rocks with collision on a composition for example... hopefully it gets considered in the future.

The Launcher category refers to the Arma 3 Launcher software, not to missile launchers in the game.

rev.149842 isSameAs

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?