- 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)
Description
Description
Details
Details
- Severity
- Minor
- Resolution
- Open
- Reproducibility
- N/A
- Operating System
- Windows 10 x64
- Operating System Version
- Windows 11, 21H2, 22000.918
- Category
- Scripting
Steps To Reproduce
- Get into a mission.
- 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
RPT:
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
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"
returns
bin\config.bin/CfgWeapons/arifle_AK12_GL_base_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
Comment Actions
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.
Comment Actions
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.