#Just realized how useful it would be to
somber shadow
Rangefinder and binoculars are weapons, yet they are in item slots and this makes them exception to the rule when dealing with items. I have added them to getSlotItemName and already want to remove from it because of un-uniformity they create but the "assignedItems" return them too and "weapons". I guess I need to create another exception for this event handler, and I am not looking towards it
leaden idol
has been a long standing desire among mission makers for a "gear changed" event
with current methods, basically any time "uniqueUnitItems" changes
tepid panther
Rangefinder and binoculars are weapons, yet they are in item slots and this make...
The game is already all over the place with this anyway
player linkItem "Binocular" => Nothing
player addItem "Binocular" => Weapon added to inventory
player addWeapon "Binocular" => Works
player assignItem "Binocular" => Nothing (while having it in inventory)
I guess you're already expected to know that sometimes items and weapons are mixed up
So I'd be totally fine with getSlotItemName working with Binoculars
somber shadow
if them supported as item it is because exception was made
manually
they are weapons
tepid panther
What's interesting is that addWeaponCargo works with Items and ends up adding bugged weapons
As for the event handler, I'd suggest having a separate one for weapons, since knowing when weapons are manipulated is also very useful, and have binocs slot handled there as well.
As for removing binocs from getSlotItemName, I'd just make a warning that binoculars aren't an item but a weapon
leaden idol
my guess is its just not possible or itd have been done awhile ago
tepid panther
Most likely cause for missing essential commands and event handlers: BI didn't need it for their SP missions
leaden idol
why need gear EH when u have "isMultiplayerSolo"
tepid panther
player addWeapon "H_Cap_blk" also works
So having binocs in getSlotItemName is not a big deal if you ask me, just warn mission designers not to treat that slot number as an item but a weapon
Its much less of an issue than feeding items into addWeaponCargo commands for example
Thought if you ask me, I'd fix that too, having bugged item-weapons is not useful to anyone
mellow pasture
a weapon changed eventhandler would be amazing
like both when currentWeapon changes and when primary,secondary,handgun etc change
tepid panther
addItemCargo* adds weapons fine
addWeaponCargo* adds items as bugged weapons
tepid panther
Rangefinder and binoculars are weapons, yet they are in item slots and this make...
assignedItems
Yeah, these commands are all over the place
Some dreaming:
InventoryWeaponChanged:
params ["_unit", "_oldWeapon", "_newWeapon", "_newWeaponTakenFrom"];
````InventoryMagazineChanged`:
```sqf
params ["_unit", "_weaponName", "_muzzleName", "_oldMagazine", "_newMagazine", "_newMagazineTakenFrom"];
````InventoryAttachmentChanged`:
```sqf
params ["_unit", "_weaponName", "_attachmentType", "_oldItem", "_newItem", "_newItemTakenFrom"];
Rename ticket command from InventorySlotChanged to InventoryItemChanged probably
dedmen mentioned that inventory system is a mess so it might be impossible to implement this properly
somber shadow
SlotItemChanged
true added false removed no new old
if you add to existing, removed happen first no need for new old
tepid panther
Add to existing? As in have EH added when you already had something or you mean you add it to certain slot somehow?
leaden idol
oh cool