Lower Priority Events Are Voice Stealing Highest Priority Events

Have a number of dialogue events that are set to a variety of priorities based on whether they should voice steal from each other or not.

Currently it seems that the priority system on our dialogue group and sub groups are not working with Highest priority dialogue events being stolen by events that are set to lower priority.

The following video demonstrates the issue:

Is this a bug with teh priority system or are we doing something incorrect with the setup?

We’re likely going to need to build a queue system anyway in order to make sure that dialogue lines dont overlap, but it would be good to save some work if possible.


Justin French

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.
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”.
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.

1 Like

Thanks for taking a closer look at this for me Cameron, its very much appreciated; I didn’t realize that Setting the Instance limiting on the top level bus would negate the priorities system, interesting behavior. I think my thought process was that I wanted to make sure that there was no overlapping at all, though during the past weeks tests this behavior has lead to some comical results for our testers where one sentence will blend into another creating some quite strange lines of dialogue.

Your suggest use of snapshots to duck events should be good for medium / low / lowest events but it looks like we’ll need to create that queue system I mentioned for the high and highest priority events in order to make sure that nothing is missed, at least for the non-time sensitive lines. In addition to this we’ll have to find a way to maybe delay lines so that if one does steal from another there’s a nice little 1 or 2 second gap between lines triggering so as to not create the comical dialogue we’ve seen this week. I imagine triggering the ADSR on the event in this case would sound cleaner than a hard cut.

Anyway, thanks again