Proposal: Stackable objects of same type in the same SnapDropZone

[bkensey]

Overview

I'm proposing the addition of new functionality to VRTK_SnapDropZone to accommodate the stacking of identical VRTK_InteractableObject based items.

This will be useful for me in particular in building an RPG style inventory, but I can imagine it being useful in other contexts too (eg. tracking grenade count in an FPS chest-mounted inventory a la Onward)

Code In Progress

• Made rough working changes to VRTK_SnapDropZone to tally the number of objects being stacked
• Added a (very) rough test to determine whether an interactable object is the same kind already snapped to an SDZ.
• Tweaked VRTK_InteractableObject to add a new "stackable" property

Demo

For discussion

• Is this functionality generalized enough to merit inclusion into VRTK?
• What is the best way to perform interactable object type comparison (tags, subclass comparison, id variables?)
• Should all of the proposed functionality, like the item counter, be added to VRTK_SnapDropZone or should it be added to a subclassed prefab instead?
• What are the implications for communication between SDZs. Users might want to prevent multiple stacks of the same object, meaning that an SDZ would have to check in with each of the other SDZs in its group to see if they should receive the interactable object instead. Perhaps a VRTK_SnapDropZoneGroup component is worth considering.

[thestonefox]

I quite like the idea of having a snap drop zone allow multiple items of the same type to be snapped to it and have a counter for them.

I don't think you'd need to extend the interactable object, but also need to be aware that a snap drop zone can have any number of items snapped to it so you could get into a situation where you snap a cube then snap a sphere and in that case the counter shouldn't go up? Perhaps you can only have multi item snapping if the same item is snapped to the drop zone?

[bkensey]

That's what I was thinking too. I currently have a rudimentary, easily broken test to determine item type and prevent stacking one type of item on top of another. I've been considering how to improve the test though. In my game, I need to include a large number of items, and I plan on subclassing VRTK_InteractableObject for each one (potions, weapons, other consumables) in order to inherit shared behaviors and differentiate use behaviors. At least in my case, I'm leaning towards adding an "item type" variable to VRTK_InteractableObject that can either be modified in the inspector, or (in my case) hard-coded for each subclassed item. An "item variant" variable might be appropriate too (eg to differentiate between blue potions and purple potions even though they're both potions). Thoughts?

[bkensey]

PR with fix: #1547

[noorbeast]

Moscartong has the inventory basics here: https://github.com/moscartong/VR-Inventory

[m0o0scar]

How's the PR going? Would this feature be merged into the next version?

[bddckr]

@moscartong It has merge conflicts and wasn't updated yet to do the requested changes. You can see that on the PR page.

[thestonefox]

Also, 3.3.0 is now pretty much version locked to only include the new example scenes and the windows mixed reality native support. Anything else is just going to slow down it's release.

[m0o0scar]

@thestonefox Understood. Good news that MS MR support is finally here 👍.

I'll do some workaround on this matter for now. I recently try to use two snap drop zones together to form a super snap drop zone that, in effect, could hold multiple items with the same type, without changing a single line of VRTK code. Could take a look at it if you guys are interested :)
https://github.com/moscartong/Snaaap-Drop-Zone