Luxart Vehicle Control v3 Help Needed [Solved]

FiveM Resource Development & Modding Discussion
, ,
1

Hello all,

Over the past few months I’ve been working on a version 3 of Luxart Vehicle Control. Some of the main features are highlighted below. However, I am struggling to solve an issue. After a few hours of playing, influenced by activations, all sirens mute, and a NUI error is send to console on attempted activation:

Uncaught (in promise) AbortError: The play() request was interrupted by a call to pause(). https://goo.gl/LdLk22 (@lux_vehcontrol_lite/html/index.html:0)

LuxHUD: A small togglable and adjustable visual representation of the scripts functionality modeled after real siren controllers.

Adjustable Manual / Auxiliary Tones: Change which tone to use for each manual tone (primary and secondary) as well as the auxiliary tone. These are also saved to the client requiring no changes at relog. Custom Button SFX: Change what sound effect are played when using your siren controller.

The code is messy, unconventional, and it is not something I am proud of but, I really, really would like to get this working and out to the community. I’ve seen some pretty harsh critics on this site so I was reluctant to post this but, I hope we can all gain from this release if we can solve these issues. Any help would of course be credited.

I am here to answer any questions and can even go through and comment every line to explain how it works. I have two version of Luxart Vehicle Control v3 a full and lite version. Both face the same issues, so I am going to focus on the lite for now.

Github: https://github.com/TrevorBarns/luxart-vehicle-control-lite

(I’m sorry if I broke any rules mods :frowning: )

1 Like
2

To clarify…

  • Does the sound not play after that error?
    – Do all further sound attempts fail?

You say this occurs after a few hours of playing, however, from the code it looks like it should occur anytime a button is spammed (assuming File Explorer is correct in saying they all have <1 second playtimes, correct?).

1 Like
3

It’s spotty, for example, as it approached complete failure activations will still play the SFX sound (beep) but fail to trigger the siren to activate.

For example, your Primary Siren may fail but, airhorn, manual sirens, and aux sirens, may still work. Then all sirens will behave sporadically for a few (10-20) more activations before failing all together. I have tested this with many people, many times and have yet to see a failure short of 30 minutes to an hour, including spamming. I could try to be more deliberate but I usual spam manual tones.

Other volunteer debuggers report removing SFX button tones increases the time (1 to 2 hrs) it takes for failure but does not eliminate it however, I have yet to test this myself. Are you suggesting that NUI SFX shorter than 1 second could cause an issue?

1 Like
4

Sorry, had an emergency passout.

I’m suggesting that the code is too simple.

I am recanting my earlier suggestion as I’ve just read the documentation provided with the error.

When I read your JS code, this is what I saw being able to happen if you spammed a tone key (Note: This code is from the documentation)

<script>
  video.play(); // <-- This is asynchronous!
  video.pause();
</script>

Essentially, a new call to message(*.playerSound) would try to *.pause() a request that was loading, or failed to load, and cause your crash. It explains why tones can be intermittent, but not why they cut out completely.

There’s two things that should be happening and aren’t.

First, you should be evaluating the Promise object *.play() returns to see if it failed, and why it failed. I’m not sure if you can use jQuery’s promise evaluators here, as it’s not a jQuery object.

            var audioPlayer = null;
            // Listen for NUI Messages.
            var SoundID = 0;
            window.addEventListener('message', function(event) {
                // Check for playSound transaction
                if (event.data.transactionType == "playSound") {
				
                  if (audioPlayer != null) {
                    console.log("Attempting to pause sound # "+SoundID);
                    audioPlayer.pause();
                  }

                  SoundID++;

                  audioPlayer = new Audio("./sounds/" + event.data.transactionFile + ".ogg");
                  audioPlayer.volume = event.data.transactionVolume;
                  var didPlayPromise = audioPlayer.play();
                  console.log("Attempting to load and play sound # "+SoundID);

                  if (didPlayPromise === undefined) {
                    console.error("Sound # "+SoundID+" did not initialize properly; Promise was undefined!");
                    audioPlayer = null; //The audio player crashed. Reset it so it doesn't crash the next sound.
                  } else {
                    didPlayPromise.then(_ => { //This does not execute until the audio is playing.
                      console.log("Sound # "+SoundID+" is now playing!");
                    }).catch(error => {
                      console.error("Sound # "+SoundID+" crashed on load; "+JSON.stringify(error));
                      audioPlayer = null; //The audio player crashed. Reset it so it doesn't crash the next sound.
                    })
                  }
                }
            });

This should update your code to better inform your users when there’s an issue. It’s big, fat, and ugly, but it enables soft landings instead of crash explosions if I wrote it right.

Can you test it and let me know?

Second, but I’m hoping we don’t have to get that far, is individual evaluators for each audio file. This can get buggy if we don’t do it right, but is the best bet if we do. All things considered, I’d prefer avoid this.

Edit: You may also look into this. Look at the second answer as it’s a better basis. If you check if the audio is done playing, you may want to reset AudioPlayer to null to prevent another error case.

Isn’t code great!? :smiley:

2 Likes
5

So far, so good from testing. Since it does take so long to test it will take a while to gather enough data to for sure say this has fixed it.

Definitely is an improvement over not catching the errors. Will update later with findings.

2 Likes
6

So, no issues with button SFX. However, the failure still occurs.

It happens later now, like 2-3 hours after instead of 1 hour. The failure seems to effect all players in a radius at time of failure. Which makes me wonder if it is memory leaks of oversize table (?) that is the only thing I can think of that is time related.

1 Like
7

So the failure behavior can be reproduced by spawning and activating sirens on 100 vehicles. This occurs in Lt. Caines original script and in LVCv3. Car 99 will experience intermediate tone failure (every other tone, randomly changes). Car 100 with have no sirens/horns played from entity at all.

This failure does not occur naturally in Lt. Caines original script while playing (over time) with less than 100 vehicles. However, LVCv3 it does occur depending on the players between 30-180 minutes. I suspect this has something to do with table clean ups and releasing the sound ID. However, I have not changed any functionality in the clean up function.

1 Like
9

it’s not working for me I put the community id as my fivem server, but it stills says error CONFIGURATION ERROR |
COMMUNITY ID MISSING i watched videos to fix it but no i tried to get in the discord but there is none