Jump to content
The simFlight Network Forums

A question about the Lua Sound library functions


Recommended Posts

Hello Pete,

I have a question regarding the Lua Library sound functions.

Specifically:

1. "ref = sound.play("name-of-wave")"

2. "bool = sound.query(ref)"

What assigns the "ref" parameter when the "wav" file is played using the first function above?

Does this come from within Lua or from the FSX sound system?

Once the "ref" parameter is obtained via the first function, does it remain the same if that

same "wav" file is played as a result of an FSX "effect"?

Or does the "ref" change each time the "wav" file plays?

An explanation of my desired use:

What I am attempting to do is recognize when the user aircraft is within range of some FLAK explosion effects

so that I can use that information eo effect damage to the aircraft without the user having to do anything.

At the moment the only solution I have for this is to create "dummy" DME stations with very short ranges and

locate them in the FLAK areas. I have an XML gauge that sets the standby NAV2 freq to 117.95 and if the user

tunes the active NAV 2 to 117.95 the "Flak Damage Code" is enabled in the XML gauge code. Once in range of the

DME I sense the signal strength, and if above a threshold level, consult a couple of random number generators to

determine if damage is to be inflicted and the type of damage.

This is rather a kluge in that the "dummy DME" sites clutter up the landscape as I have several hundred

FLAK sites and thousands of "eefect controllers" spread around Europe.

(I started this little project with the A2A B-17G in mind)

I was hoping to use a method that was less of a kluge and since the effect files and controllers with the WAV

file references were already located where I want them, sensing the sound being played would be ideal.

I experimented with a Lua Plugin to use the two functions noted above and then subsequently use the "query" function

to see if I could "see" the WAV file played as a result of the effects but to no avail.

Another approach, albeit very messy, would be to do a Lat/Lon compare but there are just too many sites that

I would have to create tables of min/max Lat and Lon for.

The one "interface" between the user aircraft and external effects, "cause damage", was removed by Microsoft for FSX

as I understand it.

What I wish to do is perhaps possible via SimConnect but I have no experience writing code for that application

so Lua and XML are my choices.

Paul

Link to comment
Share on other sites

What assigns the "ref" parameter when the "wav" file is played using the first function above?

Does this come from within Lua or from the FSX sound system?

Neither. It's a reference for the FSUIPC code to find the details for that sound.
Once the "ref" parameter is obtained via the first function, does it remain the same if that

same "wav" file is played as a result of an FSX "effect"?

What anything else, like FS, does with wave files is completely unrelated to these facilities, so they don't affect anything.

Or does the "ref" change each time the "wav" file plays?

The reference is to the one "Play" request. That's why it is returned by the play request. If the sound is not repeating or is stopped, the reference becomes void, no longer a reference.

I don't understand why you don't find it clear. The only use for the reference is so you can test if it is still playing and/or terminate it.

What I am attempting to do is recognize when the user aircraft is within range of some FLAK explosion effects

so that I can use that information eo effect damage to the aircraft without the user having to do anything.

The Lua sound library is about playing sounds, not hooking into sounds played elsewhere. I've no idea if detecting sounds made by others is even detectable without hooks deep into Directsound. You need a microphone and an input! ;-)

Regards

Pete

Link to comment
Share on other sites

Neither. It's a reference for the FSUIPC code to find the details for that sound.

What anything else, like FS, does with wave files is completely unrelated to these facilities, so they don't affect anything.

The reference is to the one "Play" request. That's why it is returned by the play request. If the sound is not repeating or is stopped, the reference becomes void, no longer a reference.

That's what I thought was the case but wanted confirmation.

I don't understand why you don't find it clear. The only use for the reference is so you can test if it is still playing and/or terminate it.

I understand that operation. I was hoping that there was an outside chance that the "ref" was a parameter supplied by FSX and remained constant during a session for a particular "wav" file. I have no problem detecting the "wav" file playing with the "query" function as long as

I started it with the "play" function. That doesn't help me for my application however.

The Lua sound library is about playing sounds, not hooking into sounds played elsewhere. I've no idea if detecting sounds made by others is even detectable without hooks deep into Directsound. You need a microphone and an input! ;-)

Regards

Pete

The use of the "sound detection" was what I hoped would be a way of determining, from within a XML gauge or

Lua plugin, when an effect was being generated. Alas, there does not appear to be an easy way to get "external

events" such as that into the user-aircraft environment. It seems I will have to resort to a messy continuous

comparison of current Lat/Lon with a table of several hundred "lat/lon rectangles". :(

Thanks for the reply.

Paul

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.