Pushback and Concorde Visor?

[nickpike 0]

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.

[rcbarend 37]

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

[rcbarend 37]

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)

[nickpike 0]

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.

[rcbarend 37]

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

[nickpike 0]

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.