Page MenuHomeFeedback Tracker

Several issues with "compatibleItems" and "compatibleMagazines"
Confirmed Internally, NormalPublic


  • If you use "compatibleItems" and "compatibleMagazines" on a class with scope = 0, they throw errors.
  • Slots and muzzles handed over to "compatibleItems" and "compatibleMagazines" respectively are case sensitive.
  • "compatibleItems" can return duplicates (e.g. if two different "WeaponSlotsInfo" classes contain the same class) (unsure if "compatibleMagazines" can do that though)


Operating System
Windows 10 x64
Operating System Version
Windows 11, 21H2, 22000.918
Steps To Reproduce
  1. Get into a mission.
  2. Run
compatibleItems "arifle_MX_Base_F"; // Returns full array, throws error
compatibleMagazines ["arifle_MSBS65_GL_base_F", "UGL"]; // Returns full array, throws error
compatibleMagazines "arifle_CTAR_GL_base_F"; // Returns full array, throws error

compatibleItems ["arifle_Katiba_GL_F", "PointerSlot"]; // Returns full array

compatibleMagazines ["arifle_MSBS65_GL_base_F", "uGL"]; // Returns []
compatibleItems ["arifle_Katiba_GL_F", "pointerSlot"]; // Returns []

See error box pop up (unless there was already another error box beforehand) and this in the RPT:

Warning Message: Error: creating weapon arifle_MX_Base_F with scope=private
Warning Message: Error: creating weapon arifle_MSBS65_GL_base_F with scope=private
Warning Message: Error: creating weapon arifle_CTAR_GL_base_F with scope=private
Additional Information

No mods, 2.10.149939

Event Timeline

johnb43 created this task.Sep 17 2022, 11:49 AM
Tenshi changed the task status from New to Confirmed Internally.Sep 20 2022, 12:25 PM
Tenshi set Ref Ticket to Internal Ref. AIII-55378.
Tenshi added a subscriber: Tenshi.

Thank you for reporting the issue, we will see what we can do.

h- added a subscriber: h-.Sep 24 2022, 1:04 AM

Do you have an example for cases where it returns duplicates?

As for the other two issues:

  • The easiest way to work around the private scope error is to just filter out everything that has scope = 0. In your examples you always use a class that has "base" in the name, which are not used for anything other than shared properties for inherited classes. If you were to use addWeapon on arifle_MX_Base_F, for example, you would get that error as well but hold a weapon called "rifle" that has no model or icons. I don't think it is worth the effort to fix it in the engine, as it would mess with more than just this command. The only ways around it are:
    • To check for private scope in engine, which restricts the functionality of the command
    • Have the script command check the config directly, rather than creating a template of the weapon in memory which it currently does, but that would become very cumbersome from a code perspective and proved to have a lot of pitfalls when trying that approach.
    • Have it accept an object that it can check directly, which has the same effect as the first way and prevents you from checking weapons with a private scope unless you decided to use addWeapon, at which point you would still get the warning.
  • The case sensitivity is not something I think is really an issue, other than someone making a typo which they can easily fix. Changing that would affect more than just these commands, so it is something I'd rather not change.
johnb43 added a comment.EditedSep 30 2022, 6:53 PM

Do you have an example for cases where it returns duplicates?

For CUP's MG36 CUP_arifle_MG36. 616 with just compatibleItems, 537 if I arrayIntersect the result with itself. I know it's a modded weapon, but I was hoping it wouldn't return duplicates nonetheless.

johnb43 added a comment.EditedOct 4 2022, 7:20 AM

After a small message exchange with Dedmen, he told me to include all the following information in the ticket:

For a bit of background:

For compatibleItems:
I managed to find that it can return duplicates in a special instance (see the bug report).

For compatibleMagazines:
However, I don't know if compatibleMagazines can return duplicates. I figured if it was the case for compatibleItems, it might be the case for compatibleMagazines.

The reason why I want to be able to check compatibleMagazines on weapons with scope = 0 is because of this example:
configFile >> "CfgWeapons" >> "arifle_AK12_GL_F" >> "EGLM"

I wanted to try update CBA_fnc_compatibleMagazines to work with compatibleMagazines, but the problem is that CBA_fnc_compatibleMagazines can take config paths as an argument. So, somehow a given config must be parsed into a weapon class name, with a muzzle name if passed in the config (like the example above).

My assumption is that getting the original child (e.g. arifle_AK12_GL_F) from its parent (e.g. arifle_AK12_GL_base_F) is impossible and therefore that CBA_fnc_compatibleMagazines will unfortunately not be able to utilise compatibleMagazines.
The same is valid for CBA_fnc_compatibleItems, where it can take weapons with scope = 0, but compatibleItems can't.

I understand the reasons given and I doubt that the commands will be changed to accommodate weapons with scope = 0. As the commands are at the moment, they are already very handy.

Edit: scope can be 1, only throws errors when scope = 0

Interesting case where the muzzle will return the base class rather than the actual parent. Might be something that needs looking into, but out of the scope of this ticket.

Knowing the case of the UK3CB_G3SG1_RIS, where it has two CowsSlot but one of them is missing the lower case s, it might just be that there are duplicate slot entries that add the same items to two different slots. The same could happen for compatibleMagazines, where two muzzles are defined that take the same magazines.

I'm looking into the compatibleItems command currently and hopefully have a fix ready for the next Dev branch update. The issue is though that it will make the command significantly slower, although still faster than using arrayIntersect afterwards.

So the issue with the CUP_arifle_MG36 is that has two PointerSlot's defined: the regular PointerSlot and CUP_PicatinnySideMountG36. So that is where the duplicate items come from, as both of them have the same items defined it seems. Similar to the issue with the UK3CB_G3SG1_RIS, but instead of the duplicate slot defining different items it defines the same items.

Fixed the duplicate entries issue in rev. 149975

This can be closed, it's been addressed.