# Group bus instance limiting for continuously playing events

**URL:** <https://qa.fmod.com/t/group-bus-instance-limiting-for-continuously-playing-events/22914>\
**Category:** Unity\
**Created:** [May 8, 2025, 5:28am UTC](https://qa.fmod.com/t/group-bus-instance-limiting-for-continuously-playing-events/22914 "2025-05-08T05:28:21Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![kalman](https://avatars.discourse-cdn.com/v4/letter/k/59ef9b/32.png) [@kalman](https://qa.fmod.com/u/kalman)\
**Post date:** [May 8, 2025, 5:28am UTC](https://qa.fmod.com/t/group-bus-instance-limiting-for-continuously-playing-events/22914/1 "2025-05-08T05:28:21Z")

</div>

We have a lot of vehicles with (different) engines that are constantly running events, and I think this may be what is causing [Stuttering after upgrading 2.01 to 2.03](https://qa.fmod.com/t/stuttering-after-upgrading-2-01-to-2-03/22853). What I want is effectively bus instance limiting with virtualisation, but I know that this isn’t possible, I can see there are a couple of other forum posts about it.

Instance limiting using furthest etc actually stops the events, which for continuously running events isn’t desirable.

The best workaround I can think of is to implement event instance limiting ourselves - periodically calculate the distance of each vehicle from the listener, and make sure that the N closest (where listener distance \< event max distance) are playing, and all others are stopped. Is this what you’d advise? Are there any gotchas about it? Apart from it being a bummer that I need to write some finicky code, the events also don’t start warm… but I don’t think that this matters to us. E.g. no parameters with velocity.