Hey guys, this might be a question more suited to the Unreal forum, but thought Id try here as well…we’ve recently noticed that all of the footstep samples in our game (UE4) are not releasing when the sample/event stops playing. Ive captured the Lifespan for these events in the Profiler window, and unless we limit the “Polyphony Max Instances” for those events (which is our current fix, but we still want to know why this is happening), they seem to keep stacking up and never release. Oddly this is only occurring with the footstep events (all characters) and not with any other one shot events (ie. Jump Land, Punch, Hit Reaction, etc). These are using a ray cast from each foot socket for material detection, triggered via Animation Notify event tags via Blueprint using the “Play Footstep FMODEvent Using Socket” component. Only the Footstep events are not releasing. Any ideas?
Hey Geoff, I am using two parameters, Surface and Speed for each FootDown event. In the Surface parameter I have one track with six MultiSound events (nested/referenced events) which play back the footstep sounds based on the surface type being sent from the game. In the Speed parameter I have two tracks,. The first track contains three MultiSounds (not referenced events) which play cloth foley based on the character’s speed. The second track also contains three MultiSounds (not referenced events) which play back additional foley based on the character’s speed. I dont have any samples/events placed on the Timeline parameter view.
FMOD Studio only lets events finish when their modules are all finished. For the case of complex events with many levels of nesting, that makes sense (e.g. a car engine) since otherwise it may finish the event early.
But in your case, what may be happening is that the top level event is staying alive since the next level nesting event is alive, since its lower level nested event is alive. That can be the case even if none of the events have any sounds playing through them. For the current version of FMOD Studio, the only workaround you have at the moment is to either define an event with a less complex nesting, or have the code move the parameter values off the nested events so they are no longer triggered.
OK, I guess that makes sense for looping sounds such as engines, but these are all one shots. It was nice and tidy to have everything contained within only a few events, but I suppose we’ll have to split them out into separate unnested events and manage the logic within Blueprint.
Just did a test by removing all the nested events and only use multisounds, and indeed it seems to fix the problem. All the one shots now release once the sounds stop playing. I guess this means that we cant really use nested events then, unless they are looping sounds and need to remain on indefinitely.
The stopping behaviour of events is something we’re going to revisit, but it will have to be done on a major release since it might change functionality, and it may require a migration. It didn’t make it for 1.08 so the behaviour of events is unchanged in that version from 1.07 and earlier.