Sign in to follow this  
rcbarend

How to prevent xml gauge from execution at panel load?

Recommended Posts

Hello " Gods", "Gurus" and " Dalai Lama's" of the xml coding. As some of You already know I'm trying to put together a virtual co-pilot. As the work progresses i bumped into a problem that was somewhat expected. Since I already have some 25 "comments" from the diligent co-pilot active the problem is that all of the sounds that meet proper execution criteria for the flight situation are played at once as the panel loads. Is there a way to prevent this?

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Well, some extra info would be helpfull :-)- What is copilot gauge ?- what soundgauge/version are using to initiate sounds from your gauge ?Rob

Share this post


Link to post
Share on other sites

Here we go. For generation of sounds I'm using the latest version (3.5.2.0) of dsd_xml_sound3.gau by Mr. Doug Dawson.What I call copilot gauge is actually a bunch of xml gauges that triggers proper "comments" (maybe I'll also add actions thru K: events) as per SOP's for a certain type of aircraft thru various A:vars. For the not so well informed the cockpit becames quite a noisy place with all the announcements from the non-flying pilot. So far all the sounds from parking brakes release at the gate to the level off at a certain flight level are covered.My problem is that when the plane loads, immediately two files are executed if the parking brakes are set and that is actually expected behaviour, only a bit annoying to say at least. One is phrase "parking brakes set" generated with this:(A:BRAKE PARKING POSITION,enum) 0 > and the other is "manual braking" using this: (A:AUTO BRAKE SWITCH CB,enum) 0 > plus (A:SIM ON GROUND,bool) in both cases. I don't know of any other A:vars that could generate this sounds according to the proper state of the simulation, but event use of other if there are any siutable won't prevent the sound from playing as the flight loads, so something else is needed . .

Share this post


Link to post
Share on other sites

Hi,>What I call copilot gauge is actually a bunch of xml gauges>that triggers proper >"comments" (maybe I'll also add actions thru K: events) as per>SOP's for a certain type of aircraft thru various A:vars. Use your own L:Vars to trigger the "comments" instead of FS A:Vars.For example, if you want the copilot say "parking brake set" when you actually set it via a keyboard/mouse/joystick command, use something like this:(L:Parking Brake set, bool) if{ *SOUND CALL* }Then, to update the Lvar value, inside something like:(A:Brake parking position, percent) 50 < (>L:Parking Brake set, bool)Hope this helpsTomEDIT: even would be better to make the call directly inside the event, like (A:Brake parking position, percent) 50 < if{ *SOUND CALL* }, avoiding the first and the need of a second var to prevent continuous calls.

Share this post


Link to post
Share on other sites

I actually like Tom's suggestion - detect the Parking Brakes event and have your co-pilot act accordingly.As an alternative, if you just want to stick to the A:Vars, you could prevent the gauges in question from playing sounds until the opposing condition has been met. For example, the "parking brakes set" sound would be inhibited until the parking brakes have been detected in the "off" position. You could inhibit the "manual braking" sound until the aircraft's ground speed has become non-zero.Doug

Share this post


Link to post
Share on other sites

As Tom said, the On Event with included test on actual state of the A:Var would be the best trigger for a single-shot sound.However, for some callouts there might be no related event.Example; suppose you want a callout "80 knots" when the aircraft passes 80 knots during takeoff run.Since there is no related FS event in this case to trigger a one-time sound, you can create this trigger by comparing the previous value of the variable with the current one.I.o.w. at the end of the gauge code, you have to save the "current" variable into a L:var or G:var that you interprete as "previous" value in the next schedule.Now, in addition, if you want to make sure you don't get any "transient" callouts during panel load, you can apply the following code: (L:Init,number) 18 <if{ (L:Init,number) ++ (>L:Init,number) }and 'protect'all your other code with the test:(L:Init,number) 18 ==if{ ... }This prevent any calls with one second (with the default 18 times/persec schedule rate) after panel (=gauge) load.cheers, Rob

Share this post


Link to post
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
Sign in to follow this