Bug #11785

[OA] Peculiarity when inheriting from certain types of class "Man"

Added by JamesF1 about 5 years ago. Updated over 4 years ago.

Status:Expired Start date:07/08/2010
Priority:Normal Due date:01/01/2011
Assignee:- % Done:

0%

Category:Config
Target version:-
Affected ArmA II version:1.52.71816 First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:No NGUrl:
Related to content of DLC: WIKIurl:

Description

This is a bit of a difficult one to explain, but I've replicated it perfectly (and had it verified by others).

When inheriting from certain "Man" classes (e.g. to create a soldier with a different loadout by default), some classes cause issue with the Arrowhead M249 range of weaponry. I have been unable to produce the same behaviour with any other class of weapon, but my tests in that regard haven't been extensive.

An example is easier:

    class US_Delta_Force_MG_EP1;
    class CIT_TestCase_Two: US_Delta_Force_MG_EP1
    {
        vehicleClass = "CIT_TestCase_Class";
        faction = "CIT_TestCase_Faction";
        displayName = "Succeeding Soldier";
        weapons[] = {"M249_m145_EP1", "M9", "ItemGPS", "NVGoggles", "Throw", "Put", "ItemMap", "ItemCompass", "ItemWatch", "ItemRadio"};
        magazines[] = {"15Rnd_9x19_M9", "15Rnd_9x19_M9", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "HandGrenade_West", "HandGrenade_West"};
        respawnWeapons[] = {"M249_m145_EP1", "M9", "ItemGPS", "NVGoggles", "Throw", "Put", "ItemMap", "ItemCompass", "ItemWatch", "ItemRadio"};
        respawnMagazines[] = {"15Rnd_9x19_M9", "15Rnd_9x19_M9", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "HandGrenade_West", "HandGrenade_West"};
    };

This example inherits from the default Arrowhead unit "US_Delta_Force_MG_EP1" and works as expected. The resulting unit has all of the above-listed weaponry, but is placed in the new class/faction and has the new display name.

However, the following soldier, which has the exact same config (differing only in name, and the underlying soldier from which it inherits), performs abnormally:

    class US_Delta_Force_EP1;
    class CIT_TestCase_One: US_Delta_Force_EP1
    {
        vehicleClass = "CIT_TestCase_Class";
        faction = "CIT_TestCase_Faction";
        displayName = "Failing Soldier";
        weapons[] = {"M249_m145_EP1", "M9", "ItemGPS", "NVGoggles", "Throw", "Put", "ItemMap", "ItemCompass", "ItemWatch", "ItemRadio"};
        magazines[] = {"15Rnd_9x19_M9", "15Rnd_9x19_M9", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "HandGrenade_West", "HandGrenade_West"};
        respawnWeapons[] = {"M249_m145_EP1", "M9", "ItemGPS", "NVGoggles", "Throw", "Put", "ItemMap", "ItemCompass", "ItemWatch", "ItemRadio"};
        respawnMagazines[] = {"15Rnd_9x19_M9", "15Rnd_9x19_M9", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "200Rnd_556x45_M249", "HandGrenade_West", "HandGrenade_West"};
    };

This example results in the soldier not receiving the M249, or any of the associated ammo. As a result, the unit ends up with the M9 pistol and 2x clips, and two hand grenades... but no M249 or ammo. I am certain this is not the expected behaviour.

This is only exhibited on some units - ones that I have observed initially have been the above "US_Delta_Force_EP1" and "US_Delta_Force_Assault_EP1"... but my testing hasn't extended past that.

No error is generated in the RPT or on-screen when loading the game, or during play. This problem seems to be something a little more 'internal'.

REPRODUCTION
Below is attached a PBO containing the above two config entries, and only those two entries. The problem can be easily observed by starting the game with only the attached PBO, loading up the mission editor, and placing the "player" as each of these units in turn, and observing the results. The "Succeeding Soldier" (as it's named in the config) will have the expected main weaponry, the "Failing Soldier" will lack this weaponry, despite having the same config.

Additionally, this can be reproduced (not sure if this happens 100% of the time, though) on the same unit classes (e.g. by creating a "US_Delta_Force_EP1") and using removeAllWeapons this; this addWeapon "M249_m145_EP1" in the unit's init line.

This is, as far as I am aware, new to Arrowhead... I've not observed it in A2. I am, equally, not sure that this is constrained merely to these two classes, but I thought I'd flag the issue anyway.

config.cpp - Config from within the PBO (2.4 kB) JamesF1, 07/08/2010 23:08

CIT_TestCase_Soldiers.pbo - PBO for reproduction (2.5 kB) JamesF1, 07/08/2010 23:08

CIT_TestCase_Soldiers2.pbo - PBO for reproduction of same problem with M107 (2.5 kB) JamesF1, 07/09/2010 10:22

CIT_TestCase_Soldiers3.pbo - PBO for reproduction of problem solved (2.5 kB) JamesF1, 07/09/2010 10:34

History

Updated by oblivion180 about 5 years ago

Reproduced as described using provided PBOs

Updated by VKing about 5 years ago

Have you tried this with another weapon that occupies both primary and secondary slots, e.g. M107?
If that doesn't work, I'd guess the bug is caused by certain soldier classes having backpacks in the configs (US_Delta_Force_EP1 has, but not US_Delta_Force_MG_EP1 for obvious reasons) which occupy the secondary slot.
As far as I know, they aren't removed by the removeAllWeapons command, either, since they're technically not weapons.

Updated by JamesF1 about 5 years ago

Correction to the above post, I've typo'd M249_m145_EP1 as M249_m415_EP1 in the post - but it is correct in the config.

I tried VKing's suggestion with the M107 and the same problem arises (PBO attached - completely independent from first PBO. Faction named "CIT Test Case #2"). Due to the sheer number of combinations, I'm unable to conclusively test whether it happens only on units with backpacks, or not, but from what I have tested, this would seem to be the case. However, this still doesn't make complete sense - if the weapon is removed because of the backpack, why should the corresponding ammo be removed along with it?

Updated by kju about 5 years ago

  • Due date set to 08/01/2010
  • Category set to Config
  • Status changed from New to Feedback

Why not just disable the backpack in the given class to test it.

backpack = "";

Updated by JamesF1 about 5 years ago

Wasn't aware of that - thanks kju.

Tested (updated PBO attached) and it would seem to be related to the backpack. That being the case, I guess this ticket more becomes "is this expected behaviour?" rather than anything else. Seems a bit odd that the backpack would remain, but the weapon and all ammo for it would be lost?

Apologies for wasting everyone's time :)

Updated by Fireball almost 6 years ago

  • Due date changed from 08/01/2010 to 09/15/2010
  • I am using some Mods set to No
  • Reproducible for you set to No

Giving some more time for feedback, maybe BIS may shed some light on this.

Updated by kju over 4 years ago

  • Due date changed from 09/15/2010 to 01/01/2011

Last chance for feedback (from BI .. doh).

Updated by kju over 4 years ago

  • Status changed from Feedback to Expired

Also available in: Atom PDF