As the title mentions, I’m using Cutievirus’ MV3D plugin and Quxios’ QAudio plugin. Basically, I wanted to implement proximity sound into the project. QAudio is what I ended up with because someone else made a version that works with MV3D.
For a few seconds, it worked as I wanted. Then the audio got choppy before the test game crashed. I did try to check the console to see the full error, but it also crashed with the test game.
I managed to screenshot the error that did pop up; it said: Uncaught (in promise) DOMException: unable to decode audio data.
I’m not sure if that’s the actual problem, but that’s what it showed before the test game crashed. So I considered a few options:
Go into the plugin and see if I can fix it or edit it (possibly the worst option)
Try to see if anything on the map is causing problems
Try to find a different plugin (
Skip using a plugin and try to make an audio proximity using variables and region IDs
Skip using an audio proximity system altogether
Commissioning someone to make a plugin for me that works with MV3d
I also tried a couple of things before, for example:
Using the original, unedited plugin. The test game still crashed. I even edited the plugin command to be sure.
Changing the audio file. It still resulted in choppiness until the sound stopped playing, but it didn’t crash the test game, so the plugin might not be the sole issue.
It might feel like a long shot, but any help is appreciated.
I don’t have MV3D so I can’t reproduce any of this, but I had a look at Quasi Audio and there’s something in there worth ruling out before you go editing plugins.
The plugin deliberately overrides MV’s createNewBuffer so it doesn’t cache, and the comment in the file says why, so that the same audio file can play more than once at a time. The tradeoff is that every qaudio play builds a fresh WebAudio, which means another fetch and another decode. Nothing reuses anything.
So how are you triggering the play command? If it’s on a parallel process or something that retriggers, it’d be firing off a new decode over and over, and that could line up with what you’re seeing, fine at first, then choppy as they stack, then the decode error once it can’t keep up.
If you have a fixed ID like 1, the plugin finds the previous buffer with that ID, stops it and clears it, so you only ever have one alive. With * it generates a new unique ID each call, so nothing ever matches and every buffer sticks around getting updated every frame.
If that’s the shape of it, the fix would be on the event side rather than inside the plugin, which would be a much nicer outcome. Might be worth posting the event that runs the qaudio command.
One more thing worth checking separately, what MV3D version are you on? The thread you linked is from January 2020 when MV3D was 0.4.x, and it’s 0.9.x now, so an edit from back then may be aimed at a fairly different plugin than the one you’re running.
So I changed the turn trigger from parallel process to Autorun + Self Switch, and I think it fixed the problem. So far, playtest hasn’t crashed.
Though by having it in a parallel process it would keep the audio in loop, but the loop command makes it redundant and it shouldn’t take me too long to realize that. At least I know now.
I might have a concern when more audio events come in, but for now, the issue seems solved.
Yeah I’m on 0.9.x. I don’t think it the update would affect the other plugin as much since the code of MV3D hasn’t changed enough to cause issues.
On the concern about more audio events, give each source its own fixed ID with the idX argument, so idCITY, idWATERFALL, that kind of thing. Before it makes a new buffer the plugin clears any existing one carrying that same ID, so a fixed ID keeps that sound down to one buffer no matter how many times the command runs. Leave the ID off and it falls back to *, which generates a fresh unique ID every call, so nothing ever matches and they pile up. Worth keeping the IDs distinct per sound too, since starting a second sound on an ID that’s already in use stops the first one.