Not as good as I thought I was...

[Guest Albatross7107]

SIM: FS2004GOAL: Make a "gauge" that "senses" when Exit 2 is open (exit 2 lowers the landing lights); When open ladning lights on, when closed landing lights off. (A:EXIT OPEN:2, percent) 50 > if{ (>K:LANDING_LIGHTS_ON) } els{ (>K:LANDING_LIGHTS_OFF) } My trouble is I can't see where anyone has used A:EXIT OPEN:2 before, only a few references say "use this..." which I did, and it didn't work.As it is, any attempt to turn on the landing lights directly results in a "flash bulb effect"...(I would do this the other way, and make turning on the landing lights automagically extend the landing lights, buuuuut, since there is only (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) to open/close the exit, the lamps on and off could get out of sync with the lamps being up and down, resulting in lamps being on when up and off when down...

[phjvh 0]

Hi,May be this is helpful:http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchJan"Beatus ille qui procul negotiis..."

[rcbarend 37]

I.o.w. For Exit-2 you should use (A:EXIT OPEN:1,percent) :-)Important !Your code induces the infamous "continuous event" bug, since your gauge now is continuously giving either a LandingLightsON of OFF event. Which disturbes multi-keystroke commands like "Shift-E 2" or Pushback heading selection. What you should use: (A:EXIT OPEN:1, percent) 50 > if{ (A:LIGHT LANDING,bool) ! if{ (>K:LANDING_LIGHTS_ON) } } els{ (A:LIGHT LANDING,bool) if{ (>K:LANDING_LIGHTS_OFF) } } Iow: always test the state of the variable if you really need to give the event.About "Exit-2 following the state of the landing lights".This is also possible, but a bit more complex.Synchronisation isn't the problem, since FS always starts up with it Exits closed. So you know the initial state of Exit-2, and can set Exit-2 accordingly by toggling it when LL are initially ON.More complex is the criterium when to toggle Exit-2.Because after toggling Exit-2, this isn't immediately visible in the (A:EXIT OPEN:1, percent) variable. So if you do nothing, you end up issueing toggle commands indefinetely :-)And what it makes it even more complex (if you want to code it properly): you have to "protect" yourself against user-given ToggleExit2 commands.Several ways to solve that (like introducting a "dead" time after issueing a toggle Exit-2, tracking the direction in which the Exit variable is changing: open, opening, closing or closed, and alike).SO it's doable, but your first solution is by far the easiest to code..Cheers, RobPS: And about the "subject" line: all of us designers experiance this at one time or another ....LOL

[Guest Albatross7107]

Perfect, thank you sir!

[Guest Albatross7107]

Now I'll share what I was able to do, via the code you left for me. Again thanks - I do much better with these examples then with the SDK... (A:LIGHT LANDING,bool) if{ (A:EXIT OPEN:1,percent) 100 == if{(>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) } } els{ (A:EXIT OPEN:1,percent) 0 == if{(>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) } } With this gauge, hitting "Shift+E-2" does nothing (which is fine because it's dodgy anyway) however, hit the landing lights and the lights lower (Exit 2 opens) turn them off, and the lights rise up into the fuselage (Exit 2 closes).I believe that if the system gets reversed (IE lights down and off or up and on) then it should be self resetting and straigten it's self out... I leave this here for those who, like me, come here to learn about the coding of gauges.Thanks a ton.

[rcbarend 37]

Just two more tips:1. Don't use 100, but > 99.99 instead.Because of rounding errors in FS, a fully opened exit (or variables like for gear, spoiler, etc ...) may not be exactly 100% .2. To be safe, use an "update frequency" of 2 or 3 in the gauge (resp. scheduling of 0.5 or 0.33 sec). Because at the standard schedule frequency (55 msec), the "open" variable might not have changed already as a result of a "toggle" in the previous schedule.Which means the gauge keeps giving toggle commands, and the exit never opens. Or opens only after opening/closing for a few seconds :-)This might e.g. occur at low framerate....Cheers, Rob

[Guest Albatross7107]

Ok, now I'm using this... (A:LIGHT LANDING,bool) 1 == if{ (A:EXIT OPEN:1,percent) 0 == if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) } } els{ (A:EXIT OPEN:1,percent) 99.99 > if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) } } Which seems to have fixed a problem I found last night. That problem was, unless the lights were in transistion (or rather Exit 2 was in transistion) I could NOT open or close exit 1.I suspect the "" is what fixed this...The one "glitch" it has now is this. Load AC with landing lights off, and it works fine.Load AC with landing lights on already and after a moment the lights drop down (exit 2 open) BUT when I switch the lights off, the lights stay down. Cycle the lights (on then off) and they retract (Exit 2 closed) and after that they work OK. Odd...EDIT: ARRRUGH!! Just flipped back the FS after posting this and the #### things wouldn't work again... did a fast cycle of the power (before the lamps could fully close) and now they toggle backwards!!Why the &(#*@$ couldn't they have put in a EXIT_OPEN and EXIT_CLOSE command....~sob~

[Guest Albatross7107]

ALright... At the risk of discovering some other failure mode when I'm done posting :) Here goes... (G:Var1) 0 == if{ (A:Light landing, bool) 1 == (A:EXIT OPEN:1, percent) 0 == && if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) 1 (>G:Var1) } (A:Light landing, bool) 0 == (A:EXIT OPEN:1, percent) 100 == && if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) 2 (>G:Var1) } } els{ (G:Var1) 1 == if{ (A:EXIT OPEN:1, percent) 100 == if{ 0 (>G:Var1) } } (G:Var1) 2 == if{ (A:EXIT OPEN:1, percent) 0 == if{ 0 (>G:Var1) } } } The addition of the G:Var1 makes a "flag" whereby the code can track two important questions "Is exit 2 on the move?" and "Which way is it going?"The which way part is important for checking if Exit2 has made it to it's destination or not. Once it has the flag (G:Var1) is set back to 0, allowing checks of the light toggle and exit position.This was needed because with out it, the system didn't have enough time to move the exit to 1% or 99% (depending on direction) before the next check, and when it saw the 0% or 100% again it re-triggered the exit toggle...I went though a lot of "it looks like 'this' is happening" only to find out later that I was no where near correct...(Of course and unfortunately, this does NOT take into account the player hitting "SHIFT+E 2" manually...)

[rcbarend 37]

You are finally getting the hang of it ...LOLBut if it's any comfort to you:I must have programmed about 500+ gauges by now, and this was probably the most difficult XML code (because of it's real-time aspects, lack of proper events/variables and time/framerate dependancy)to get working properly under all circumstances (including "protection" against users trying to "interfere").If you want to know how I solved it "fool-proof": have a look at my VTOL gauge in the rcbsc1-9.zip package; in which a simular problem is solved with folding wings mapped onto Exit-2.The essence of the whole problem is: FS doesn't immediately react to a "toggle exit" event because it has a built-in delay time for the possible follow-up event: either nothing, or a "Select_*"What I did built-in too, to "protect" against user keyboard events AND avoid continuous repetitive toggle events from the gauge: besides checking for the "direction" of movement of the exit, make sure that if the gauge issues a toggle event itself, either because the "landing lights" variable changed or to "undo" an unwanted user action, it will never do that within one sec. after it has issued one itself. Iow: if the gauge issues a toggle-exit event, it won't issue another one within the next second (so: use a timer for that).It took me about 4 versions of code to understand the problem fully, and this was the only way I could think of to make it "foolproof".Success :-)Rob