Arsenal - Add/Fix/Improve/Change numerous aspects

[johnb432]

My aim was to cleanup the old code and fix a couple of things:

When merged this pull request will:

• Everything has been made to work with config case sensitive names.

• Added the ability to add/remove primary and secondary muzzle magazines to weapons where it wasn't previously possible:

  • Handguns: Added secondary muzzle magazines
  • Launchers: Added secondary muzzle magazines
  • Binoculars: Added primary and secondary muzzle magazines

  I added this for weapons like RHS' SMAW, which has two muzzles (primary and a spotting rifle) and laser designators, where you can ensure that a magazine has been loaded.

• Added: ace_arsenal_uniqueBase can be applied to items from "CfgWeapons", "CfgMagazines" and "CfgVehicles".
  I'm unsure about that change, but I felt it matched the documentation on it better. Maybe the documentation should be expanded/changed instead.

• Added: More caches to hopefully reduce some loading times. Sorting now caches results, reducing repeated sorting times drastically.

• Added: When searching, it will keep the currently selected item highlighted, unless it doesn't match the search results (works for items as well as loadouts).

• Added the ability to add items from "CfgMagazines" into the "Misc. items" or custom tabs (thanks @LinkIsGrim for the help).

• Added "baseWeapon" class support for weapon attachments. If a weapon attachment has the config property "baseWeapon" defined, it will take that item and show that in the arsenal.

• Added stronger filtering on item scopes: If scopeArsenal exists, it must be 2 and scope > 0, otherwise scope == 2.

• Added "descending" (default, as it is now) and "ascending" sort order as a drop down menu.

• Added: Unique backpacks in containers can now be removed with either the "-" or "clear all items" button.

• Added: FUNC(removeSort). You can't remove the default sort type (alphabetically) to avoid problems with the arsenal.

• Addresses ACE Arsenal - 'SHIFT + IMPORT' feature not importing data from clipboard #9035 (it should in theory at least).

• Addresses removeVirtualItems - Remove case sensitivity #8844.

• Fixed: Linked items being removed when switching to a new weapon ( Arsenal - Improve magazine removal after weapon switch #8786 removed that accidentally).
  Now it removes the linked items only if they aren't available to the arsenal.

• Fixed: Faces not being JIP compatible. Previously it would constantly overwrite the same JIP ID.

• Fixed: Weapons with attachments that were in containers losing their attachments when changing containers of the same type.

• Fixed: When sorting by a number, 2 decimal points have been added, so that when you sort by weight it returns the correct order.

• Fixed: Both FUNC(addStat) and FUNC(compileStats) actually take priority into account now. Because of that priority on several stats needed to be tweaked.

• Changed: When switching containers of the same type, it will no longer replenish magazines.

• Changed: If there are only items with no mass (e.g. ACE fortity tool), the "remove all items" button shows.

• Changed: Loadouts can be renamed case-insensitively ("Temp" -> "TemP", previously not possible).

• Changed: Converted the arsenal to partially work with hashmaps instead of arrays (for configItems and virtualItems, currentItems is still an array). Because of this, performance of FUNC(addVirtualItems) and FUNC(removeVirtualItems) has improved immensely.

• Changed: CBA disposable launchers are handled differently now: Within the arsenal, you can change weapon attachments on disposable launchers, but you can't change their magazines (primary or secondary). Item info on the right and the stats show correct information.

• Changed: FUNC(addSort) now checks if the new sorting method already exists and doesn't add it if it does.

• Changed: FUNC(removeStat) ensures that there are no gaps within the stat array. So from now on, if there is an empty spot in the stats page, it's because there is a stat, but the condition for it being shown hasn't been met.

• Changed: Insignia now need scope == 2 or no scope property to be shown (like vanilla arsenal).

• Probably more, which I have forgotten at this point, as I have been working on this for several months.

This is still WIP and I have numerous questions for the ACE team as to what I should do in some cases. I'll open reviews for the areas in question.

I do have a couple of general questions though:

• Do Macros for the arsenal need to be backwards compatible or can they be altered (or even deleted)?
• What sort of scopes (private, protected or public) should be allowed for weapons in the arsenal?
• Is GVAR(currentItems) public? Do mods rely on it?
• I'm unsure whether the new functions I have added to common should be placed there or in the arsenal. I figured they could be useful in general, so I put them in common. ace_common_fnc_addWeapon can be removed if Common - Optimize and expand CBA_fnc_addWeaponWithoutItems CBATeam/CBA_A3#1557 gets merged.

---

I have tested it some, but mostly SP (with some 3DEN, but only a little). However, whatever is MP related I haven't tested at all.

IMPORTANT

• If the contribution affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
• Development Guidelines are read, understood and applied.
• Title of this PR uses our standard template Component - Add|Fix|Improve|Change|Make|Remove {changes}.

[johnb432]

The latest commit should address some of the issues.

[BrettMayson]

@johnb432 Can you handle the merge conflicts, and advise if this is ready for a review or if you have any further unresolved questions.

[mwpowellhtx]

Congrats @johnb432, pending merge and such. 👍

[LinkIsGrim]

Scary.

[mwpowellhtx]

Just my two cents, FWIW... doing something similar in my inventory manager effort, presenting addon mod logos and such, along similar lines as the pending ACE COMMON 'getAddon' cache. However, I am noticing that the cohesion with the the prospect of a cached addon (really, mod), is not great, with usage also appearing during various list filling algorithms, i.e. fnc_scanConfig.

Anyway, the approach I'm taking is to cache the mod config itself, as opposed for every single virtual item class config, and either to have that config available, or a HASHMAP bundle of desired modParams. That's the first observation, potential optimization.

Second, rather than "logo", not sure whether "logoSmall" would be more appropriate, just based upon modParams documentation. TL;DR, have not done the leg work to evaluate whether that is actually desirable, or whether "logo" itself is in fact better coverage there. Would be interested to learn what you discover.

And just a third ancillary incidental observation, is uiNamespace intentional? This caches variables in the UI namespace, which if I understand correctly, persists between 'mission' engagements, over the lifetime of the A3 session? Is that accurate? May or may not be desirable, I don't know. But in any event...

Good luck, good hunting!