Cash rewards and penalties are being dealt incorrectly when there are more than one human player inside a vehicle

[Asmodeuz]

When more than one player is crewing a vehicle rewards and penalties for kills are not given to the player that "pulled the trigger" to make the kill.

One example we tested with is a light vehicle with a mounted machine gun:

• When testing with two players, one as the driver of the vehicle and another as the gunner it is the driver that gets the rewards and penalties for all the enemy and teamkills. If the driver switches to the seat next to the driver's seat he will still get the rewards and penalties.

Another vehicle we tested this issue with was a tank with multiple crew slots:

• In this case the player that was firing the available guns (hull machine gun, main tank gun or coaxial machine gun) was the last person to get the rewards or penalties.
• In short it could be said that the rewards went to the player crewing the slots in the following order:
  1. driver
  2. commander
  3. then all the rest (hull gunner, main gunner, loader)

Also when two players were crewing a plane that has a pilot seat and a rear gunner seat it was the pilot that got the kill rewards and penalties that the rear gunner was making.

I might be thinking too far and too early but if there's somewhere code that is using Killed eventhandler, maybe adding "instigator" in the mix would change the behaviour described in this issue. See https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#Killed

• "(Since Arma 3 v1.65) instigator: Object - Person who pulled the trigger"

[Asmodeuz]

Adding additional parameter "_instigator" in fn_aiUnitSetup.sqf and then changing _killer in the lines 26 and 33 to _instigator seems to fix the issue where kill rewards and penalties are being dealt incorrectly when multicrewing a vehicle. With the aforementioned change now "the player that pulled the trigger" (gunner, hull gunner) will get the cash rewards and penalties instead of the driver or commander of the vehicle.

There are a few issues why I am only typing our findings here as a comment and not creating a pull request:

• no one as the crew of a vehicle will get a kill reward or penalty when running over either an enemy or friendly soldier (since running over someone is not the same thing as "pulling the trigger")
• since the change proposed here was made in the fn_aiUnitSetup.sqf file it is not known who will get the rewards and penalties when multicrewed vehicles are killing friendly or enemy human players. It was not possible for us to test this with only two players available for testing.
• the changes in the code that are ultimately offered as the official fix for this issue should probably also take into account dealing XP rewards and penalties which is most likely affected as well (wrong player is getting all the XP rewards and penalties for the kills someone else is doing when multicrewing a vehicle)

Just as an example here's the code from fn_aiUnitSetup.sqf where I did some small changes in the lines 18, 20, 26 and 33

if((getNumber(missionConfigFile >> "CfgClient" >> "enableKillReward")) isEqualTo 1) then
{
    _ai addEventHandler
    [
        "Killed",
        {
            params ["_unit","_killer","_instigator"];

            if(isPlayer _instigator) then
            {
                if((side (group _unit)) isEqualTo (side (group _killer))) then
                {
                    if((getNumber(missionConfigFile >> "CfgClient" >> "enableTeamKillPenalty")) isEqualTo 1) then
                    {
                        [(getNumber(missionConfigFile >> "CfgClient" >> "HG_MasterCfg" >> (rank _unit) >> "tkPenalty")),1] remoteExecCall ["HG_fnc_addOrSubCash",_instigator,false];
                        if((getNumber(missionConfigFile >> "CfgClient" >> "enableXP")) isEqualTo 1) then
                        {
                            [(getNumber(missionConfigFile >> "CfgClient" >> "HG_MasterCfg" >> (rank _unit) >> "xpPenalty")),1] remoteExecCall ["HG_fnc_addOrSubXP",_killer,false];
                        };
                    };
                } else {
                    [(getNumber(missionConfigFile >> "CfgClient" >> "HG_MasterCfg" >> (rank _unit) >> "killedReward")),0] remoteExecCall ["HG_fnc_addOrSubCash",_instigator,false];
                    if((getNumber(missionConfigFile >> "CfgClient" >> "enableXP")) isEqualTo 1) then
                    {
                        [(getNumber(missionConfigFile >> "CfgClient" >> "HG_MasterCfg" >> (rank _unit) >> "xpReward")),0] remoteExecCall ["HG_fnc_addOrSubXP",_killer,false];
                    };
                    if(((getNumber(missionConfigFile >> "CfgClient" >> "enableKillCount")) isEqualTo 1) AND ((getNumber(missionConfigFile >> "CfgClient" >> "enableHUD")) isEqualTo 1)) then
                    {
                        [0] remoteExecCall ["HG_fnc_addOrSubKills",_killer,false];
                    };
                };
            };
        }
    ];
};

[Asmodeuz]

The changes introduced to the fn_aiUnitSetup.sqf with the commit https://github.com/Ppgtjmad/SimpleShops/commit/524a87571f9f581edfc1767a04bc67a3d653fcfc seem to have changed the behaviour how kill rewards and penalties are being dealt when killing AI soldiers. Now when human players multicrew a single vehicle the rewards and penalties end up to the player that makes the kill (to be more precise: to the one that pulls the trigger).

Since we were testing these fixes with just two players we were not able to confirm if the changes introduced to the fn_killed.sqf would have the same effect on dealing rewards and penalties when players are killing soldiers controlled by human players. But we are in good faith that also those changes work as expected.

How these changes were made create another though less crucial issue where the driver of a multicrewed vehicle doesn't get any rewards or penalties for killing friendly and enemy soldiers by running over them. I will create a new issue (edit: see https://github.com/Ppgtjmad/SimpleShops/issues/25) to specifically target this behaviour in the hopes that it could get a fix someday (if there even is one to begin with).

The changes that were made to target the issue reported herein also fix the issue so IMHO this issue can be closed.