Massive RPT spam when some virtualised RHS vehicles are attacked

[1ncontinentia]

When some virtualised vehicles are attacked, the RPT log quickly fills up with thousands of lines of the following:

18:51:00 Error in expression <ileToAttackHealth select _randomIndex;

_randomHitPoint params ["_randomHitPoint>
18:51:00   Error position: <_randomHitPoint params ["_randomHitPoint>
18:51:00   Error Undefined variable in expression: _randomhitpoint
18:51:00 File x\alive\addons\sys_profile\fnc_profileSimulator.sqf, line 665

I've so far managed to get a repro on all armed RHS M1025 and any vehicles that inherit from them (including those in Project OPFOR). Does not happen when the vehicles aren't virtualised. May happen with other vehicle types too but these are the only ones that I've managed to nail down so far.

Does not occur on vanilla vehicles as far as I'm aware. Repro mission requires RHS.

HitpointRepro.Stratis.zip

Arma3_2017-02-11_18-45-50.txt

[1ncontinentia]

Did a bit of digging. Seems that for some reason, "rhsusf_m1025_d_m2" call ALiVE_fnc_configGetVehicleHitPoints returns [] while it should return an array of hitpoints like:

["HitHull","HitFuel","HitAvionics","HitEngine1","HitEngine2","HitEngine","HitHRotor","HitVRotor","HitGlass1","HitGlass2","HitGlass4","HitGlass7","HitGlass5","HitGlass3","HitGlass6","HitGlass8","HitGlass9","HitGlass10","HitGlass11","HitGlass12","HitGlass13","HitGlass14","HitGlass15","HitWinch"]

this is from ("O_Heli_Attack_02_black_F" call ALiVE_fnc_configGetVehicleHitPoints).

I'm going to try to run a test now to see which vehicles return with no hitpoints.

[highhead]

thanks for the report!

as far as I understand it, RHS messed up the vehicle hitpoints on this vehicle and this fucks up ALiVE. I believe profileSimulator should fail with grace on such a mistake.

[1ncontinentia]

Yup, seems like a good solution. I just ran some code to see which vehicles will fail and here's a list from Project OPFOR and RHS:
["RHS_AH64D","RHS_AH64D_GS","RHS_AH64D_CS","RHS_AH64D_AA","RHS_AH64D_noradar","RHS_AH64D_noradar_GS","RHS_AH64D_noradar_CS","RHS_AH64D_noradar_AA","RHS_AH64D_wd","RHS_AH64D_wd_GS","RHS_AH64D_wd_CS","RHS_AH64D_wd_AA","RHS_AH64D_noradar_wd","RHS_AH64D_noradar_wd_GS","RHS_AH64D_noradar_wd_CS","RHS_AH64D_noradar_wd_AA","RHS_AH64DGrey","RHS_AH1Z","RHS_AH1Z_GS","RHS_AH1Z_CS","RHS_AH1Z_wd","RHS_AH1Z_wd_GS","RHS_AH1Z_wd_CS","rhsusf_m1025_w_m2","rhsusf_m1025_d_m2","rhsusf_m1025_w_s_m2","rhsusf_m1025_d_s_m2","rhsusf_m1025_w_mk19","rhsusf_m1025_d_Mk19","rhsusf_m1025_w_s_Mk19","rhsusf_m1025_d_s_Mk19","rhssaf_m1025_olive_m2","LOP_AA_M1025_W_M2","LOP_AA_M1025_W_Mk19","LOP_IA_M1025_W_M2","LOP_IA_M1025_W_Mk19","LOP_PESH_M1025_W_M2","LOP_PESH_M1025_W_Mk19","LOP_PESH_IND_M1025_W_M2","LOP_PESH_IND_M1025_W_Mk19","LOP_ISTS_M1025_W_M2","LOP_ISTS_M1025_W_Mk19","LOP_ISTS_OPF_M1025_W_M2","LOP_ISTS_OPF_M1025_W_Mk19","LOP_IRAN_AH1Z_WD","LOP_IRAN_AH1Z_GS","LOP_IRAN_AH1Z_CS"]

I've tested a few of these at random and the error appears predictably. Like you say, seems like failing with grace is the only viable solution to this one!

[DavisBrown723]

If there is an alternate way of grabbing hit points please let me know, otherwise these vehicles when used as profiles, will be killed instantly.

[1ncontinentia]

I've been trying to find a way around it for the past half an hour or so with no luck. No idea why the hitpoints don't return but I'll try again tomorrow.

Here's the code I ran to get all these vehicles just in case it's of use to anyone:

private ["_cfgVehicles","_return"];

_return = [];

_cfgVehicles = configFile >> "CfgVehicles";

for "_i" from 0 to (count _cfgVehicles - 1) do {
    _entry = _cfgVehicles select _i;

    if (isclass _entry) then {
        private ["_hitPoints","_result","_type"];
        _type = configName _entry;
        _result = [];
        _hitPoints = configFile >> "CfgVehicles" >> _type >> "HitPoints";

        if (
            (getNumber(_entry >> "scope") >= 2) &&
            {configname _entry isKindOf "LandVehicle" ||
            {configname _entry isKindOf "Air"} ||
            {configname _entry isKindOf "Ship"}}
        ) then {
            for "_i" from 0 to ((count _hitPoints)-1) do
            {
                _hitPoint = _hitPoints select _i;

                _hitName = configName _hitPoint;
                _result pushback _hitName;
            };
            if !(_type isEqualTo "") then {
                if (_result isEqualTo []) then {_return pushBack _type};
            };
        };
    };
};
copyToClipboard str _return;

[HeroesandvillainsOS]

Incontinentia, perhaps a formal bug report on RHS's bug tracker would be warranted here too? It may be good to make them aware, especially if this is not something the ALiVE guys can workaround.

[1ncontinentia]

I was just doing that but I have a feeling it's a "feature" to do with their fancy armour system. I'll try to find out if there's an alternative way to get the rhs equivalent of hitpoints. Even getAllHitPointsDamage doesn't work on these objects.

EDIT: getAllHitPointsDamage does work so I'll keep digging for a way...

[1ncontinentia]

@SpyderBlack723 I've just had some success using this:

_result = []; 
_hp = [(configfile >> "CfgVehicles" >> _type >> "HitPoints"),0] call BIS_fnc_returnChildren;  
{_result pushBack (configName _x)} forEach _hp; 

This returns a list of hitpoints for the vehicle when the other method doesn't, but it is around 13 times slower. Could be a fallback option if the original returns nothing?

[1ncontinentia]

Final comment of the evening!

Changing line 575 from this:

if (_targetToAttackType == "entity") then {
  _profileToAttackHealth = +([_targetToAttack,"damages"] call ALiVE_fnc_hashGet); // must be copied so that calling "removeUnit" doesn't alter the new damage array
} else {
  _profileToAttackHealth = [_targetToAttack,"damage"] call ALiVE_fnc_hashGet;

  // if vehicle hasn't been spawned yet
  // init hitpoint values

  if (_profileToAttackHealth isEqualTo []) then {
      private _vehicleClass = [_targetToAttack,"vehicleClass"] call ALiVE_fnc_hashGet;
      private _totalHitpoints = _vehicleClass call ALiVE_fnc_configGetVehicleHitPoints;
      {_profileToAttackHealth pushback [_x,0]} foreach _totalHitpoints;
  };
};

to this:

if (_targetToAttackType == "entity") then {
    _profileToAttackHealth = +([_targetToAttack,"damages"] call ALiVE_fnc_hashGet); // must be copied so that calling "removeUnit" doesn't alter the new damage array
} else {
    _profileToAttackHealth = [_targetToAttack,"damage"] call ALiVE_fnc_hashGet;

    // if vehicle hasn't been spawned yet
    // init hitpoint values

    if (_profileToAttackHealth isEqualTo []) then {
        private _vehicleClass = [_targetToAttack,"vehicleClass"] call ALiVE_fnc_hashGet;
        private _totalHitpoints = _vehicleClass call ALiVE_fnc_configGetVehicleHitPoints;
		if (_totalHitpoints isEqualTo []) then {
			private _hp = [(configfile >> "CfgVehicles" >> _vehicleClass >> "HitPoints"),0] call BIS_fnc_returnChildren;
			{_totalHitpoints pushBack (configName _x)} forEach _hp; 
		};
        {_profileToAttackHealth pushback [_x,0]} foreach _totalHitpoints;
    };
};

...solves the issue with the same functionality as before. I don't know the code well enough to say whether the 1.3 ms (vs 0.2 ms) hit is going to be worth it performance wise but at least there's a way around the issue for now.

[DavisBrown723]

Thanks for the effort, I'll try to find some time next week to take a look at it. I'm sure we can find a way to only use the slower method if the first fails.

[1ncontinentia]

In theory that's what it does already - the slower code is only called if ALiVE_fnc_configGetVehicleHitPoints returns []. What I don't quite know is why BIS_fnc_returnChildren works when ALiVE_fnc_configGetVehicleHitPoints doesn't as they look similar from a quick glance. I suspect that BIS_fnc_returnChildren contains a lot of code that could be trimmed regardless.

[DavisBrown723]

Speed isn't really a problem then if that's the only case where it's called. The Profile System will still progress at the same rate anyway.