Item Context Menu -- Add class-specific actions support

[10Dozen]

When merged this pull request will:

• Rework Inventory actions to use HashMap to store actions.
• Add a way to make action apply to specific class only (without being inherited by child classes).

Note:
Framework allows to apply actions(options) to item class, item type or "#All" wildcard. Actions added to class will be inherited by all it's child classes.
Mods often do not have strict inheritance scheme (class_base (scope=0) -> various class_variants (scope=2)), but may inherit from classes with scope=2. If I want to add some specific action for parent item - it now inherited by all it's childs, which is sometimes unwanted.

This PR adds:

• new param (bool) to prevent actions for being inherited;
• changes usage of CBA_fnc_createNamespace to createHashMap for inventory actions.

Example

Config:

  class CUP_acc_ANPEQ_15: ItemBase;
  class CUP_acc_ANPEQ_15_Black: CUP_acc_ANPEQ_15;

Add action to CUP_acc_ANPEQ_15 only:

[
  "CUP_acc_ANPEQ_15",
  ["VEST_CONTAINER"], 
  "Paint it Black", 
  [], "", {true}, 
  { _this call fnc_replaceItem },  // action code
  true,                            // consume item
  "CUP_acc_ANPEQ_15_Black",        // action code args
  false                            // new flag to prevent inheritance
] call CBA_fnc_addItemContextMenuOption;

[commy2]

Don't like the ! syntax. ! means not.
But really people should fix their inheritance.

[10Dozen]

Don't like the ! syntax. ! means not.

What about $ ? Afaik it's not used in sqf

["$CUP_acc_ANPEQ_15",["VEST_CONTAINER"], ...] call CBA_fnc_addItemContextMenuOption;

But really people should fix their inheritance.

Impossible, imho. Some mods have it for years (and used in compats of other mods), it will break backward compatibility.

[commy2]

Just use an explicit argument for the function.

[10Dozen]

Just use an explicit argument for the function.

Added new parameter

[commy2]

addClassEventHandler uses _allowInheritance with default true. That seems to fit better as var name.
Still don't like the implementation with the prepended classname. Probably should be another hashmap for disallowed inheritance classes.

[10Dozen]

addClassEventHandler uses _allowInheritance with default true. That seems to fit better as var name.

Heh, this was my first guess, but I thought that it should be a bit simplier for public function. Will make similar to what is used now.

Still don't like the implementation with the prepended classname. Probably should be another hashmap for disallowed inheritance classes.

What will be the profit? Prepended classname way is just similar to handling type options (#<itemType1/##<itemType2>) and adding more stuff into current map won't affect access time. The only thing that comes into my mind is to get rid of format [] on access, but feels like type's options needs separate map more.

[commy2]

I thought that it should be a bit simplier for public function. Will make similar to what is used now.

Both are public functions.

adding more stuff into current map won't affect access time.

Performance seems non-issue here.

#(#) syntax is used for implicit typing. Think of them as virtual parents, used where the shitty trees made by BI fail us.

Prepending type names with arcane symbols is questionable. A bcd is not a $bcd, since they have different type names. Making the setting an explicit parameter better describes the behaviour.

I would like if the code refected this as well.

[10Dozen]

Sounds reasonable, thanks for explanation.

[10Dozen]

Hi, any chance to finish the review?
I still want this feature as literally every mod inherits from scope=2 items sometimes (even ACE https://github.com/acemod/ACE3/blob/1180be3cdb1d5b92425bb4a8a1216bde51817968/addons/laserpointer/CfgWeapons.hpp#L18)