Thanks for all the information you have provided, it has been very helpful.
The Priority and Intance Limiting systems are completely separate and do not take each other into account at all.
The priority property sets how important this event is in terms of virtualization.
https://fmod.com/resources/documentation-studio?page=event-macro-controls-reference.html#priority
We do say “Event instances that have higher priority will not be stolen by event instances that have a lower priority.”
Although, this can esentially be bypassed by instance limiting groups.
Group instance limiting should be thought of as how to “limit the number of event instances being passed through a group bus”.
https://fmod.com/resources/documentation-studio?page=mixing.html#bus-instance-limiting
The max instances property sets an upper limit on how many instances of events routed to this bus can play simultaneously.
Walking up the tree looks something like:
1 Dialogue Bus
10 InGame Callouts Group
1 High Priority Group
1 High Priority Event
The problem looks to be coming from the instance limit set on the top level bus “Dialogue”. By setting the Instance limit on the Dialogue bus to infinite, it will allow the ‘InGame Callouts’ group to control the instance limiting instead.
This will solve the stealing but will not give the desired result of your higher priority event playing over the others. A workaround could be to use a Snapshot to duck the lower priority events while the higher priority events are playing.
To get the result you want, you might need to implement your own system to make sure some specific dialog doesn’t overlap.
It seems more like a misunderstanding than a bug at this point, but please let me know if this is not the case.
Hopefully that clears things up a bit more.