I’m having an issue with my blueprint. I’ve told it to play an audio cue after a timeline completes which is working fine, however I’m trying to create a system so if the audio is playing, it won’t play the audio again so as to avoid overlap. All of the events are happening on a dynamic object called “Object Special”. There are multiple instances of the blueprint in the level for the player to interact with (pickup). As far as I can tell my logic is fine but if I pick up a second object when the first one’s audio is playing, the audio files overlap when they shouldn’t.
The default value for the IsAudioPlaying bool is false.
I’d also love to know how to make the delay value dynamically change based on the length of the audio file but I have no idea how to approach doing this so I just set it to a hard coded 15 second delay for now.
So I’m not entirely sure about your logic here, I haven’t tested it locally, but it looks fine.
However the usual way to limit multiple instances of a sound is to use the “Max concurrent play count” in sound cues, which seems exactly what you need here without any blueprint logic.
Thanks for the suggestion G4m4. I wish this fixed the issue but sadly it doesn’t fully fix the problem (Though it did help with stopping the random negative responses from overlapping). The max concurrent play count for each cue was set to 16 by default but since each object uses a completely unique cue file, it doesn’t seem to make a difference when I lower it to 1. The MCPC seems to only work to prevent a wave file from playing on top of another within the same cue file.
What I’m trying to do is prevent two separate cue files from firing at the same time. I’m thinking maybe I might have to add the play audio event to the player character instead and call it when the player interacts with an object instead of when the object is picked up. Maybe this will fix the problem?
Its frustrating though because as far as I can tell, the above setup should work.
I think your idea of playing the audio on the character itself is better indeed: it makes more sense and will be easier for you to have the PlaySound() in one place only.
You could even rely on a pre-created audio component on your character whose sole purpose is to play those sounds, creating a stronger coupling.