No persistent event instance with callbacks?

I’m working on a “dye and retry” kind of game, coded in blueprints, and at the moment we reload the level at each death. Which means the level is destroyed and recreated, thus I need some persistent data, which has to be stored in the game instance. Storing a FMOD event instance in the game instance works well and plays the music continuously across level reload. But the problem is that I need to use callbacks, and callbacks are only available on FMOD components, and components are only available on actors, and actors are (by definition) placed in a level. So when the level is reloaded, the FMOD component is destroyed.
To summarize, it seems impossible to have a persistent FMOD event instance with callbacks…

Did I missed something? Is there a workaround? Maybe is it possible to retrieve FMOD callbacks from a C++ class, which is not an actor? (since actors are automatically affected to a map and destroyed with it)

Couldn’t it be possible in a future release to expose callbacks in blueprints directly in FMOD event instance, instead of only in FMOD component? That would allow us to put a music track in the game instance (which is the only persistant class across all the game), for a more seamless audio experience.

If you need persistent actors between level restarts (level restarts that are triggered by a scene reload), you could try creating a global level that holds a persistent audio component and load/unload a child level as required using level streaming.
Here is the level hierarchy, with “GameLevel” added to a some other persistent level.


And here is an example blueprint, in this case the level is being switched on and off rather than immediately restarted.

That should give you smooth playing, callback-able audio across level restarts. Otherwise, the only other thing I could think of would be to change the level restart behaviour to not rely on scene loading.

1 Like

I already tried a bunch of things, including persistent level. But not a unique streaming level in the persistent level yet. I’ll definitively give a try, thanks @jeff_fmod. We’ll probably change the restart behaviour one day (but it’s a lot of work, and it’s only a prototype at the moment).
I eventually found a crazy solution, by exposing beats as parameter changes, with command instruments!


With a loop to “listen” the parameter changes:

However, is there a technical reason for not exposing callbacks on event instances?

Wow, that is a crazy workaround, not ideal but glad you got something working.

FMOD Audio Component is a wrapper for a Studio::EventInstance, so those callbacks you see on the FMOD Audio Component are actually exposed callbacks on the underlying event instance. The fact that the FMOD Audio Component cannot exist outside of a scene is, as you have said, because it is a type of Component.

Because EventInstance is tied to the Studio API I do not think we would be able to expose the callbacks in blueprints without creating another wrapper or modifying the FMOD Audio Component’s inheritance hierarchy.
I have let the dev team know of the limiation here, while you could resolve this issue by using the C++ API, the further people can get with blueprints the better!

Ok, so I tried your solution, @jeff_fmod, of putting every actors that should be reset in a child stream level (FMOD actor being in the persistent level), and unload/reload the stream level only.
It does work but brings another problem: it’s impossible to get (by blueprints) the current stream level name or reference. So actually, my code only works… for one level!

So, definitively, there’s no blueprint-only solution to this problem (else than my crappy workaround).

I finally got away by making my sub-level stick to a strict naming convention, so I can retrieve its name from the persistent level.

Ah, yes when I tested this idea it was only for one level. Sounds like a good workaround, but you are right this is definitely something we need a good blueprint solution for.