play_sound(...) - is there any 'rate limit' to the API?

[aaron311]

Hi,

I have a mod that (conditionally) uses luaForce.play_sound(...) in a on_entity_died event handler. Despite my best efforts and tracing through with a debugger, I'm finding that the sound does not reliably play despite the function call for sure executing.

Is there any circumstance where play_sound will ignore the call? Maybe some global rate limit per tick or per event callback, or something like that?

My guess is I've just done something dumb in my code. But I'm kinda at a loss so just double-checking expectations. I seem to get more consistent results calling play_sound when I 'defer' the calls to be executed later (e.g. in an on_tick() callback). That's why I'm asking about rate limits.

I DO know about the sound definitions having (configurable) limits on concurrency. But in this case no other "copy" of this particular custom sound file is playing, yet nothing plays.

[Donion]

play_sound() calls can not play the sound if it would play with 0 volume due to it being played too far from the listener, if the sound position is covered by fog of war or if all audio resources are already exhausted. Or if the sound exceeds the aggregation limits, but you mentioned this is not the case here.

[aaron311]

play_sound() calls can not play the sound if it would play with 0 volume due to it being played too far from the listener, if the sound position is covered by fog of war

Makes sense. But in this case I'm using luaForce.play_sound() with a nil PlaySoundSpecification.position thus I believe it's auto-selecting the position of every player in the target force. So this would not be the case here?

or if all audio resources are already exhausted.

My guess is that "all audio resources being exhausted" would only happen in extreme cases (i.e. I had spammed a ton of sound plays, etc). Is this right?

[Donion]

Makes sense. But in this case I'm using luaForce.play_sound() with a nil PlaySoundSpecification.position thus I believe it's auto-selecting the position of every player in the target force. So this would not be the case here?

Correct, in that case the sound would be played globally ("from the middle of the screen").

My guess is that "all audio resources being exhausted" would only happen in extreme cases (i.e. I had spammed a ton of sound plays, etc). Is this right?

Yes, it would happen if almost 200 other sounds were already playing.

If you post (or send it to me via PM) a piece of code with which you're experiencing the issue I can take a look further to see if there is some bug or unexplained behaviour.

[aaron311]

Thanks for confirming! I am willing to send you my code if I get desperate, but let me troubleshoot more before I burn more of your time.

I was already thinking this was a PEBKAC error on my part, and just wanted to rule out that there was some subtle API misunderstanding I had. Your replies here have ruled that out. So now it's time for me to do some deeper debugging of my logic. Thanks much <3