0
0

I’ve been having trouble with max playbacks behavior in our game, and I’ve been wondering if there’s anything in particular we’re supposed to do in the code to get it working or if we’re just misunderstanding how it works.

As an example, I have 8 objects in front of me, all making the same sound (all using the same event). The sound is a loop that gets triggered automatically when the map loads (it’s an ambient keypoint actor). I have the max playbacks set for 5, and it’s set to steal the quietest voice. The sound has a very sharp max/min distance so that I need to walk right up to the object to hear it. The idea was for the 5 closest (and thus loudest) ones to play regardless of where I walk.

Now when I walk between these objects, I’m expecting to be able to hear the loop playing from each object that I walk to, as I expect that if I come to an object that isn’t audible, that it will steal a voice from a quieter one so that it can play for me. Instead, only 5 of these objects load their voices to play ambiently, while the other 3 remain silent regardless of my distance.

Does max playbacks not work for ambient sounds? Is there something obvious I’ve missed? Or if not, is there a work-around for this problem? I was hoping that I could set a low max playbacks for ambient actors that populate the maps and have the voices just swap when needed whenever I walked near them.

Edit For Clarification: If I have 30 ambiently buzzing lamps in a level, I want to have 2 max playbacks for the 30 to share. Can this be done?

The reason I think something is wrong is that if I take 4 keypoints from the above example and put them near the player spawn point, you’d think that just those 4 would load with 4 may playbacks set to steal the quietest voice, but only 3 of them load. The fourth audible one is on the other side of the map with the other 4 keypoints, so clearly it can’t be stealing the quietest voice.

  • You must to post comments
0
0

Steal quietest should work, imho, but I have a possible workaround for you if it does not.

1) Add a distance parameter as the primary parameter for the layer in the event.
2) Make the sound definition of your loop end just before the max distance on the layer.
3) Now, as you approach an emitter, the sound definition is forced to trigger again, and the voice stealing should be able to do its job at this point.

Note that if you are already using the layer’s primary parameter for something else (such as a non-distance parameter), then this will obviously not be a viable workaround.

-jason

  • You must to post comments
0
0

Thanks for the help. I’ll give it a try to see if it works, but I still wonder if there isn’t something wrong with the playback stealing behavior. You’d think there would be an easier solution to this. :( I mean, on the one hand I could just significantly increase the total max playbacks and then let the virtual voice feature take care of the rest, but then I’d be eating up all that memory, and it still wouldn’t be congruent behavior with one-shots.

Can anyone else comment on this? Does max playback stealing behavior really not work with ambient looping sounds?

  • You must to post comments
0
0

I’m only saying it should work [i:1bro5l7s]in my humble opinion[/i:1bro5l7s]. Sorry if that was misleading. I haven’t tested it thoroughly enough to know for certain if it [i:1bro5l7s]does[/i:1bro5l7s] work or not, but I agree that it should.

A higher-level solution for voice control of ambient emitters is to have a far clip radius on the emitter object or actor that functions to start and stop the attached fmod event(s).

  • You must to post comments
0
0

No, we’re clear, and I appreciate the help. I tried your possible solution last night and unfortunately it doesn’t work. This problem is that distance parameters don’t have the same control over events that regular parameters do, in that event are always treated as end-to-end on the canvas rather than timed segments that can be lifted off when the parameter addresses an empty part of the canvas. Even then, loops can’t be stopped like this even [i:1ow6bsq0]with[/i:1ow6bsq0] a regular parameter. It was a nice try though. :(

I also tried the problematic scenario in Event player and confirmed what the problem truly is, and it’s exactly what your described: there’s no clip radius to allow quiet ambient voices to stop playing to free up voices. Ambient voices can’t be stolen because they all start up at the same time; they never start post-load. If I have 8 objects sharing 4 playbacks, the first lucky 4 to load on startup get the voices, while the others are out of luck. Since those unlucky voices never actually try to start again, they can’t steal voices from any other sibling voice, and that’s the inherent problem.

Seriously though, how does everyone else out there handle this without eating up gobs of memory for voices that won’t even be heard? I can’t be the only one trying this. Would it be possible to code a solution? Or am I just going to have to make a feature request? :)

  • You must to post comments
0
0

[quote="jcobb":27z3bgdq]
A higher-level solution for voice control of ambient emitters is to have a far clip radius on the emitter object or actor that functions to start and stop the attached fmod event(s).[/quote:27z3bgdq]

this is how we do it. each point has an associated radius in our level editor that is typically the same as the point where the sound would fall off anyway (and based off of the same triggers as any of our level design trigger code).

so the engine will fire events when you get close enough to hear them, rather than on level load. the voice stealing only takes place when you are in areas with lots of overlapping emitters, and it becomes more of a placement issue (want 5 maximum sounds? don’t overlap more than 5 in an area.) the max playbacks apply more for things like gunfire/explosions and so forth, not really for just ambience in the level.

  • You must to post comments
0
0

Awesome, thanks for the tip acrosby. I’ll add that to our to-do list.

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.