Sign in to follow this  
nickpike

Pushback and Concorde Visor?

Recommended Posts

I use pushback to check the integrity of XML gauges. I find that if a gauge appears to be working ok, but has some sort of corrupt coding, pushback will not turn using the 1 or 2 key press. If pushback works ok, I know the gauge coding is not corrupt.I have a gauge that auto handles air intake doors. If the speed is less than 160 knots, the intake doors are open. These doors are tagged CONCORDE NOSE VISOR.The code is(A:AIRSPEED INDICATED, knots) 160 < if{ 1 (>K:INCREASE_CONCORDE_NOSE_VISOR_FULLY) } els{ 1 (>K:DECREASE_CONCORDE_NOSE_VISOR_FULLY) }If I // out the gauge in panel.cfg, pushback works. Withe the gauge active, pushback does not work in the turns. Is it that pushback will not work with CONCORDE NOSE VISOR?Thanks,Nick.

Share this post


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

Hi Nick,It has nothing to do with "corrupt" XML code, but with code that continously gives an event (like yours :-)).Which prevents FS to interprete the "1" after "Shift-P" correctly (because you give an event in between).What you should do:First test the state of the nosevisor, and only give a command when it's actually needed (so you normally give the command only once instead of continuously).Normally this would only happen if the airspeed crosses 160 knots (in both ways); and if the user sould give a nosevisor command via the keyboard/joystick (which you cannot prevent) manually, then the gauge would immediately correct it via another event.So use:(A:AIRSPEED INDICATED, knots) 160 <if{ (A:CONCORDE VISOR NOSE HANDLE) ! if{ (>K:INCREASE_CONCORDE_NOSE_VISOR_FULLY) }}els{ (A:CONCORDE VISOR NOSE HANDLE) if{ (>K:DECREASE_CONCORDE_NOSE_VISOR_FULLY) }}or(A:AIRSPEED INDICATED, knots) 160 <if{ (A:CONCORDE VISOR NOSE HANDLE) if{ (>K:INCREASE_CONCORDE_NOSE_VISOR_FULLY) }}els{ (A:CONCORDE VISOR NOSE HANDLE) ! if{ (>K:DECREASE_CONCORDE_NOSE_VISOR_FULLY) }}(depending in which state variable NOSE HANDLE returns a TRUE or FALSE).And this construction applies to ALL gauges that give whatever events to force a certain state of a function depending on a certain condition. WHich explains why there are so many "faulty" gauges around.With the most famous being:"condition"if{ (>K:SMOKE_ON) }els{ (>K:SMOKE_OFF) }instead of:"condition"if{ (A:SMOKE ENABLE,bool) ! if{ (>K:SMOKE_ON) } }els{ (A:SMOKE ENABLE,bool) if{ (>K:SMOKE_OFF) } }Cheers, ROb Barendregt

Share this post


Link to post
Share on other sites

Another important thing to realise when using constructions as above to prevent unnecessary events to be given, is to use an UpdateFrequency of 6 or lower (166 msec or more) in your XML gauge.See this post for explanation:http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchCheers, RobPS: An easier (faster) option to check for "faulty" gauges, is the following:Toggle Exit 2 (default "Shift-E", followed by "2").If you see the FS message "Main Exit Opening ....", you have a faulty gauge (FS is opening Exit-1 now)

Share this post


Link to post
Share on other sites

Ah, many thanks. Most useful info. I was actually aware of the smoke gauge issue, and I should have realised this can happen with other variables as well. Your explanation was excellent, and you have highlighted this enough for the reasoning to be attached to a brain cell for further use.Many thanks again for your help.Nick.PS. I've been using update rates of 6 and less according to the gauge's use. I work on the theory that the smaller the number, the less the CPU has to work, or put another way, the more processing power available for scenery generation, etc.

Share this post


Link to post
Share on other sites

Hi Nick,""I work on the theory that the smaller the number, the less the CPU has to work, or put another way, the more processing power available for scenery generation, etc.""Yes, you are right.But you have to write extremely complex XML gauges if you ever can detect a substantial difference in fps, with the gauges running at the default 55 msec schedule, or at (let's say) 300 msec.Depending on your PC speed of course.I once did this test with a very complex, all-XML gauges C4SST-panel (are you THAT Nick Pike ???) and couldn't see any noticeable difference in fps.Cheers, Rob

Share this post


Link to post
Share on other sites

Yes, I have to admit it, I am THAT man.I didn't attempt to reduce gauge updates in that panel and like you said, frame rates were ok. However, I suppose it does no harm trying to optimise things.Nick.

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