configClasses or BIS_fnc_getCfgSubClasses doesn't return all "classes"

[pierremgi 4739]

Hi,

This example can be tested for more general purpose, comparing a main class of vehicles with its inheriting ones.

configClasses or BIS_fnc_getCfgSubClasses doesn't return all "classes", but only supplementary ones when inheriting, so not what is displayed in config viewer.

 

This adds difficulty to script with these command/function for any inheriting vehicle.

 

Example: On an IFRIT, when using:

"true" configClasses (configfile >> "cfgVehicles" >> "O_MRAP_02_F" >>  "AnimationSources");

It returns:

[config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitReserveWheel,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/Door_LF,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/Door_RF,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/Door_LM,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/Door_RM,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/Door_rear,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitGlass6,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitGlass7,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitGlass8,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitGlass9,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitGlass10,config.bin/CfgVehicles/MRAP_02_base_F/AnimationSources/HitGlass11]

 

more useful, on my mind:

(configfile >> "cfgVehicles" >> "O_MRAP_02_F" >>  "AnimationSources") call BIS_fnc_getCfgSubClasses;

returns:

["HitReserveWheel","Door_LF","Door_RF","Door_LM","Door_RM","Door_rear","HitGlass6","HitGlass7","HitGlass8","HitGlass9","HitGlass10","HitGlass11"]

 

 

Now, let's use these command/function for an IFRIT HMG ("O_MRAP_02_HMG_F"):

same configClasses will return:

[config.bin/CfgVehicles/MRAP_02_hmg_base_F/AnimationSources/muzzle_rot,config.bin/CfgVehicles/MRAP_02_hmg_base_F/AnimationSources/muzzle_hide]

and function:

["muzzle_rot","muzzle_hide"]

 

So, my two cents:

 

1- why configClasses or BIS_fnc_getCfgSubClasses doesn't return the whole list of subclasses (as in config viewer), but only the "delta" difference between main class (IFRIT) and derived class (IFRIT HMG) ?

 

2- BIKI is wrong (https://community.bistudio.com/wiki/configClasses):

"true" configClasses (configFile >> "whatever cfg") is not the same as (configfile >> "whatever cfg") call BIS_fnc_getCfgSubClasses,

because configClasses returns an array of configs but BIS_fnc_getCfgSubClasses returns an array of strings with sub-classes.

 

[hoverguy 177]

It does really depend on what you want to achieve.

Considering your point #2, it is nowhere stated that configClasses is the same as BIS_fnc_getCfgSubClasses, I guess you're referring to the first comment which states:

"It is recommended to use configClasses instead of BIS_fnc_getCfgSubClasses and BIS_fnc_uniqueClasses on subclasses collection or conditional selection."

 

He clearly said that it is recommended to use the native command for subclasses collection or conditional selection else use the functions.

[pierremgi 4739]

It does really depend on what you want to achieve.

Considering your point #2, it is nowhere stated that configClasses is the same as BIS_fnc_getCfgSubClasses, I guess you're referring to the first comment which states:

"It is recommended to use configClasses instead of BIS_fnc_getCfgSubClasses and BIS_fnc_uniqueClasses on subclasses collection or conditional selection."

 

He clearly said that it is recommended to use the native command for subclasses collection or conditional selection else use the functions.

 

It does really depend on what you want to achieve. ????

 

The description:

"Returns an array of config entries which meet criteria in condition code. Command iterates through all available config sub classes of the given config class."

is wrong except if you argue "O_MRAP_02_HMG_F" is not a config class. So, why not returning all sub-classes like in config viewer?

As you referred of what could be achieved, If you want to open a door on a IFRIT HMG, you can't pick it in its own sub-classes, like it's supposed to be in the description.

I know there is always a "palliative" solution (often the case for ARMA!) You can find all doors in "parent" IFRIT class, then animate what you want on IFRIT HMG, but it's weird,...

and difficult to automatize that in a script for any kind of vehicle. You can also browse for all possible doors of all possible "land" vehicles... then test until you'll find the good one.Yepee!

 

"I guess you're referring to the first comment."

 

Read just below:

"_faces = "true" configClasses (configFile >> "Cfgfaces");

//same as: _faces = (configfile >> "CfgFaces") call BIS_fnc_getCfgSubClasses;"

 

I spilled some times with that wrong remark.

[commy2 188]

Hello,

 

A few points:

 

- don't use "BIS_fnc_getCfgSubClasses". It was used before "configClasses" existed and has no benefit anymore, but is significantly slower (as far as I can tell).

- "configClasses" as well as "count" and "select" ignore inherited subclasses if at least one other subclass was added in one of the ancestors of the class your are trying to retrieve the subclasses from.

- The similar command "configProperties" has an optional parameter to search through all ancestor classes, but also reports <STRING>, <NUMBER> and <ARRAY> entries as well as subclasses.

 

Solution is to use the "configProperties" command with an isClass filter:

private _config = configFile >> "CfgVehicles" >> "O_MRAP_02_F" >> "AnimationSources";
configProperties [_config, "isClass _x", true]

//["HitReserveWheel","Door_LF","Door_RF","Door_LM","Door_RM","Door_rear","HitGlass6","HitGlass7","HitGlass8","HitGlass9","HitGlass10","HitGlass11","HitLFWheel","HitRFWheel","HitLBWheel","HitRBWheel","HitLF2Wheel","HitRF2Wheel","HitLMWheel","HitRMWheel","HitGlass1","HitGlass2","HitGlass3","HitGlass4","HitGlass5"]

Counter example using "configClasses":

private _config = configFile >> "CfgVehicles" >> "O_MRAP_02_F" >> "AnimationSources";
"true" configClasses _config

//["HitReserveWheel","Door_LF","Door_RF","Door_LM","Door_RM","Door_rear","HitGlass6","HitGlass7","HitGlass8","HitGlass9","HitGlass10","HitGlass11"]

[commy2 188]

More notes about hitpoints:

 

- not all hitpoints in config are actually valid. They all can be damaged by "setDamage", "setHitIndex" or "setHitPointDamage" commands, but if they have no existing selection in the models "Hit-points" LOD, they never actually take any damage from hits and explosions. The configs are all over the place and ignore this fact. (exceptions are hitpoints with linked damage like "HitEngine" in helicopters)

 

A way to retrieve all valid hitpoints would be a function like this below. The only downside is that you need an existing object and not just a classname:

commy_fnc_allHitPoints = { 
    params [["_object", objNull, [objNull]]]; 

    getAllHitPointsDamage _object params [["_hitpoints", []], ["_selections", []]]; 

    private _return = []; 

    { 
        if (_x != "") then { 
            _return pushBack (_hitpoints select _forEachIndex); 
        }; 
    } forEach _selections; 

    _return 
};

Note that "getAllHitPointsDamages" already filters out selections mentioned in config that don't exist in the model.

 

- Hitpoints can have duplicate names. Examples for this are "HitGun" and "HitTurret" which can appear as hitpoints of turrets (e.g. commander turret). "getHitPointDamage" and "setHitPointDamage" cannot read or set the values for these correctly. Exact behaviour for these commands seems to be undefined in these cases, which is why you'll have to use "set/getHit(Index)" if you want to get it right. Selection names don't have duplicates.

[pierremgi 4739]

Hi commy2,

Great thanks for your answers. I learned more here than in any other reading.

The config commands are great, with a little difficulty sometimes, because other commands are waiting for a string (like "muzzle_Rot") rather than a class ( like config.bin/CfgVehicles/MRAP_02_hmg_base_F/AnimationSources/muzzle_rot) ! .The mistake is regular.

 

I didn't success in obtaining directly your results, so I added 2 lines to pick up configName:

private _config = configFile >> "CfgVehicles" >> "O_MRAP_02_F" >> "AnimationSources";
_configs = configProperties [_config, "isClass _x", true];

_strings = [];

{_strings pushback _x} forEach _configs;

 

Anyway, BIKi for configClasses command should be re-written because the description is not accurate.

 

Your notes about hit-points are very interesting.

I always asked me why an empty static weapon gets some "damage" (command) but an empty array for "getAllHitPointsDamage" (as far as hit by a 6.5 mm caliber)! LOD's are probably depending on caliber.

I regret the lack of consistency between "global" damage and these "all hit points damages".

[commy2 188]

Yeah, I was using "configName" too, so my post was easier to read. Didn't know whether you needed the configs or the classnames.

 

Rereading this thread I wandered totally off topic with those hitpoints. I guess it was stuff that was on my mind at that time? Take it as a bonus.

[killzone_kid 1326]

 

- don't use "BIS_fnc_getCfgSubClasses". It was used before "configClasses" existed and has no benefit anymore, but is significantly slower (as far as I can tell).

 

BIS_fnc_getCfgSubClasses:

/*
	Author: Ji�� Wainar (Warka)

	Description:
	Return all child classes of given class.

	Remark(s):
	* Can by called 2 ways:
		* 1st way (general) works for any config.
		* 2nd way is for comfortable working with mission description.ext.

	Parameter(s):
		_this: CFG
		_this: ARRAY of STRINGS - missionConfigFile classes and an attribute.

	Example:

	* 1st way of calling:

		_subclasses = (missionconfigfile >> "Hubs" >> "A1" >> "QuickStart") call Bis_fnc_getCfgSubClasses;

	* 2nd way of calling:

		_subclasses = ["Hubs"] call Bis_fnc_getCfgSubClasses;

	Returns:
		ARRAY (of STRINGS with sub-classes names)
*/

"true" configClasses (_this call BIS_fnc_getCfg) apply {configName _x}