We’ve got a background music system that juggles big sound cues (each containing multiple layers of looping soundwaves) when moving between areas of the game. It all works nicely: rather than fading out a BGM cue when you leave an area, we simply override the currently-playing cue with the new one. All BGM cues are loaded into an array of components at game start, so:
player overlaps new area
-> trigger volume overlap event contains area name
-> all components that don’t match that name get a FadeOut
-> the one that does match gets a FadeIn
That’s great, and means that the player can move from Area1 to Area2 and get a smooth crossfade between BGM1 and BGM2. But if they cross to Area2 and immediately walk back into Area1, BGM1 has begun its FadeOut and will quickly stop (3s fade), leaving Area1 with no music playing (because FadeOut stops playback at 0.0 vol).
To prevent this, I currently have a workaround with a delay (0.1s longer than the cues’ FadeIn/FadeOut times, so the FadeOut is always allowed to run to 0.0 before a FadeIn is called) which results in a slight gap between BGM when changing areas, rather than a nice crossfade blend.
So it would be awesome if I could arrest/pause an in-progress FadeOut (e.g. BGM1’s FadeOut that was triggered when player entered Area2) when the player suddenly reverts to Area1 - and simply fade it up from its current fade level back up to 1.0. The documentation suggests that the Fade functions change the volume multiplier, but when I monitor the volume multiplier during Fades, they stay the same - seems like they use an internal multiplier or one that isn’t readily available to me.
Can anyone shed light on whether that multiplier is accessible in BPs, or where I might tell our C++ coder to go looking for it, so we can come up with a workaround for this? Or do I need to resign myself to a complicated spiderweb of Timeline logic?
TL;DR VERSION: how can I get the current volume multiplier of an in-progress FadeOut?