Looks to be fixed in 2.18, unless OP means something different. HitPart now properly has missiles in it.

Updated repro script again, now includes blue shapes that have alignWithMap=false

Updated repro to add rotation over time:

Probably related to gas stations blowing up several times too. Some MP mess is going on.

I'd add shot into command name to distinguish it from triggers. Also maybe use same names as titles for values in https://community.bistudio.com/wiki/getShotInfo ?

The repro is identical, just change the vehicle and class in init.sqf. If you still want another ticket, I'll do it.

I think checking if input backpack was nil as a flag to keep old backpack would be the best solution here. Best backwards compatibility-wise.

In T165080#2646086, @BIS_fnc_KK wrote:

In T165080#2425929, @SaMatra wrote:

I think its better to bite the bullet and fix this, make drawRectangle/drawEllipse/drawIcon treat angle as world angle rather than UI angle, same as markers currently do.

As much as I want to do this it can break things quite badly. Besides the workarund is rather trivial, it is to add ctrlMapDir _map + yourangle

Another related issue is that backpack UGV which uses similar model and same texture re-textures differently, would love both vehicle and backpack to be made re-texturable together.

Haven't tested it yet, does it trigger for countermeasures on vehicles?

Will this trigger on mode and muzzle change too? Perhaps all 3 can be included somehow.

If this ticket has a chance to be implemented, let me know and I'll make scripts to quickly test it.

Found through comparison with alpha where it works, you need to have hit > 10 for it to work.

class CfgAmmo {
    class Grenade;
    class GrenadeHand:Grenade {
        hit = 10.00001;
    };
};

Really weird choice but seeing that alpha uses same grenade config as OA probably means this engine part wasn't touched for years.

Bug found in inAreaArrayIndexes, it ignores c for height:

private _area = [positionCameraToWorld [0,0,0], 20, 20, 0, true, 20];
[
     [player] inAreaArrayIndexes _area
    ,[player] inAreaArray _area
]

> [[],[B Alpha 1-2:1 (Sa-Matra)]]

Sure, but they already do that with proper cheats bypassing SQF and creating own shot messages. Is it really *that* much worse than creating shots with createVehicle and createVehicleLocal? You can already do a lot of mess with {createVehicleLocal ["HelicopterExploBig", getPos player, [], 0, ""]} forEach allPlayers and its not even logged in createvehicle.log. (Censor this if needed)

Since source for roadkill damage changed from being a driver to an actual vehicle, damage from physx objects is still unit itself.

v = createVehicle ["Land_ToiletBox_F", player modelToWorld [0,10,0]]; 
pos = getPos v; 
onEachFrame {v setPos pos; v setVelocity [0,100,0]}; 
u = group player createUnit [typeOf player, v, [], 0, "CAN_COLLIDE"];

Here is a repro script to kill a unit with PhysX object.

v = createVehicle ["C_Hatchback_01_F", player modelToWorld [0,10,0]]; 
pos = getPos v; 
onEachFrame {v setPos pos; v setVelocity [0,100,0]}; 
u = group player createUnit [typeOf player, v, [], 0, "CAN_COLLIDE"];

Same repro with a vehicle instead of object properly attributes the vehicle as damage source

In T180323#2597801, @reyhard wrote:

Those are not visible in game and that's why they are not defined. I guess I could try hiding those magazines better in Eden box editor if they are visible over there

They aren't visible in Eden, but these wrong icons are explicitly defined in the config. Maybe just remove these definitions so there are no pictures for them at all.

I wonder if we can just get general engine-driven calculation for predicted projectile hit position? This way you could run it in Fired to find out where AI was firing. This will differ a bit from where AI *wanted* to fire though.

Nice. I guess its fine with closing the ticket until there somebody has a really big need for single-return syntax.

Command return is very different in nature - model name string, skeleton boolean, placing point vector, mass number. Pretty sure in 99.9% cases you'll only ever use a single value (like I do in all my usages), thus the suggestion to have it return only wanted value. I don't REALLY need it but it would be nice to have.

Or maybe call it setCustomEntityInfo by analogy with getEntityInfo, getModelInfo commands

I'd like to also ask for custom picture.

In T175562#2590856, @dedmen wrote:

isADS would be https://community.bistudio.com/wiki/cameraView == "GUNNER"? If so then I don't think I can do that. That wouldn't work for AI's which don't have camera, and would also be a problem in MP.
That would always return the state of the players camera. I could check if the unit holding the weapon == cameraOn. In all other cases it would always be zero?
You'd have to combine it with isselected anim source, to make sure you don't animate when player is in ADS somewhere else.

I'm pretty sure that remote units camera state is broadcasted because it changes for you automatically when you watch remote players with _remotePlayer switchCamera "INTERNAL" it follows whatever camera view that player is having on their client.

Repro

Not sure if this can be considered resolved, it doesn't solve the issue where it matters the most.

Version with RHS tank, still broken.

Okay, here is the repro:

In T178958#2565016, @BIS_fnc_KK wrote:

Make a ticket, if it is feasible in context of the event then why not. Keep in mind HitExplosion =/= Explosion

ENTITY Explosion is called alongside ENTITY HitPart has projectile entity and source in it, might as well have instigator there.

In T178958#2564970, @BIS_fnc_KK wrote:

Also added shotInstigator param to events:

ammo HitPart
ammo AmmoHit
entity HitPart
ammo HitExplosion
0nFlare.sqs

Repro hint output:

Repro RPT example:
Server:

22:20:45 #############################################################
22:20:45 # ProjectileCreated: 10: rocket_rpg7.p3d (R_PG7_F)
22:20:45 local = true
22:20:45 source = B Alpha 1-1:1 (Sa-Matra) (B_RangeMaster_F)
22:20:45 instig = B Alpha 1-1:1 (Sa-Matra) (B_RangeMaster_F)

Client:

22:20:45 #############################################################
22:20:45 # ProjectileCreated: 10: rocket_rpg7.p3d (R_PG7_F)
22:20:45 local = false
22:20:45 source = B Alpha 1-1:1 (Sa-Matra) REMOTE (B_RangeMaster_F)
22:20:45 instig = <NULL-object> ()

Is this related to lack of vehicle or instigator on the entity in lastEntityCausingDamage @ T178711? I think it would be correct for entities to store both last damage vehicle and instigator and then use it for proper Killed event handler arguments and these explosions parents.

Okay, after lots of testing, here is a patch that fixes all vanilla flare issues:

class CfgAmmo {
	class FlareCore;
	class FlareBase:FlareCore {
		intensity = 500000;
	};
	class Flare_82mm_AMOS_White:FlareCore {
		intensity = 1000000;
		effectFlare = "FlareShell";
	};
};

40mm flares inherit from FlareBase. From my tests 100k intensity (that RHS has) is nowhere close to OA or early A3 GL flare brightness, I tested 500k and it seems to be too bright it seems to be close to whatever original A3 had:
original A3:

Here is what RHS does it:

class rhs_ammo_flare_m485: F_40mm_White
{
    intensity = 100000;

and vanilla config only has intensity defined in 2 classes, checked with

"'intensity' in (configProperties [_x, 'true', false] apply {toLower configName _x})" configClasses (configFile >> "CfgAmmo") apply {[configName _x, getNumber(_x >> "intensity")]}

Test script snippet to reproduce the issue with visible values

t = 0;
st = 0;
z = 0;

Works great, can be closed as resolved

Here is a suggestion on how getVariableCall can be incorporated into existing command with backwards capability and also address original ticket idea:

getVariable ["var", {123}] // Return {123} code if "var" is not found
getVariable ["var", {123}, false] // Call {123} if "var" is not found and just return it
getVariable ["var", {123}, true] // Call {123} if "var" is not found, write into "var" and return it

Perhaps it can also work with non-code 2nd argument and true 3rd argument. You'll need code returning code if you'll want to default set the code though.

Looks like its fixed @ T120107

In T172490#2546510, @BIS_fnc_KK wrote:

handledamage alters damage locally after all the networking is done but thats not all. static building damage isaccumulative dam = olddam + newdam, now say new damage is 0 because you handed it, see where Im going? setHit is actually implementable

In T172490#2546504, @BIS_fnc_KK wrote:

HandleDamage and static buildings is a won’t fix, but might fix setHitxxx instead

In T171357#2544976, @BIS_fnc_KK wrote:

how do you see this? there could be many players connected but the connection is processed locally so all you can do is check if a particular player is connected to uav where player is local

There is isUAVConnected that checks it and it works in multiplayer, remote units get true when somebody is connected, isn't there a link from UAV to whoever is connected to it? Thought it is technically possible to have several players connected through a bug, then this command won't tell the full picture. Is there any other list in the game that could help with this, apart from iterating through every unit? Add an event handler that fires when somebody connects and disconnects their terminal so such list can be tracked by script perhaps?

In T171357#2481618, @BIS_fnc_KK wrote:

3. is done in T171207

Ticket can be closed as resolved.

Tested, works great now!

Semi-related ticket: T177724

This also happens in RHS, when you fire HEDP grenade ammo rhsusf_40mm_HEDP (shotShell), it has submunitionAmmo = "rhs_ammo_40mmHEDP_penetrator"; (shotBullet) which is also duplicated. It does damage only on one client but effects are multiplied by number of clients (lots of craters and thick smoke deleting all smokes from the scene due to hitting cloudlets limit).

Can make a repro with event handlers logging if needed.

Better repro mission:

I'd prefer this to be a fully local setting.

In T172144#2536389, @Leopard20 wrote:

@SaMatra can you please test the latest dev branch? both issues should be fixed now

Tested, both network sync and save-load work properly now.

Confirmed, units with VisualSensor see targets through objects, including in repro, knowsAbout return 4 right away

https://community.bistudio.com/wiki/remoteControlled
https://community.bistudio.com/wiki/isRemoteControlling
This was recently added too

In T172144#2529324, @Leopard20 wrote:

Sync issue has already been fixed. Will look into the saving issue

I hope command doesn't broadcast and its just synced in generic update message. Personally I'd preferred if it wasn't synced at all, but I'm fine with either.

Seems to be related to my ticket again @ T172490 something isn't propagating scripted damage right over the network.

[
     diag_codePerformance [{player isNil "testnil"}]
    ,diag_codePerformance [{isNil{player getVariable "testnil"}}]
]

>

[[0.000365157,100000],[0.000616879,100000]]

Perfect, pretty much twice as fast!

Did some testing, works great!