I am wondering if there is an easy way to make interactables more versatile? (I am quite new to using them so it could be my use scenario that is suboptimal).
Take the door example in the demo = two interactables - one for each side requiring two interact abilities.
For example, if you wanted to open or close (dedicated animations) from either side = four interacts (and some hacking with the trigger events to get them to recognised new opportunities when remaining in the same colliders (eg. turning trigger colliders off an on briefly after you have opened the door so the new trigger events allows the close interact).
Add to this, locking/unlocking the door and any other oddity you care to imagine and it seems quite cumbersome.
Maybe there is an easier way (perhaps already existing)?
I can see an option where an Interactable has an "interaction state", set to default to -1 it is essentially the same as the ID, set to anything else and the interact ability can use this as an animator int (instead of the ID).
Or maybe an interact ability can recognise a range of Interactable IDs.
With these last options a monobehaviour using the interactable interface can update the ID/state based on its status allowing repurposing of the interactable and dedicated animations from a single interact?
Thoughts on approaches would be welcomed, thanks
Take the door example in the demo = two interactables - one for each side requiring two interact abilities.
For example, if you wanted to open or close (dedicated animations) from either side = four interacts (and some hacking with the trigger events to get them to recognised new opportunities when remaining in the same colliders (eg. turning trigger colliders off an on briefly after you have opened the door so the new trigger events allows the close interact).
Add to this, locking/unlocking the door and any other oddity you care to imagine and it seems quite cumbersome.
Maybe there is an easier way (perhaps already existing)?
I can see an option where an Interactable has an "interaction state", set to default to -1 it is essentially the same as the ID, set to anything else and the interact ability can use this as an animator int (instead of the ID).
Or maybe an interact ability can recognise a range of Interactable IDs.
With these last options a monobehaviour using the interactable interface can update the ID/state based on its status allowing repurposing of the interactable and dedicated animations from a single interact?
Thoughts on approaches would be welcomed, thanks
