Hi All,Is there an XML var available in FS(X)that indicates when, during flight loading, FS is actually initialised to a state where it is ready to receive K:Events from an XML gauge, and all other A:Vars are in their actual post-loading state (either initial values or values taken from the .flt file) ??Some background on my question:Already in FS2002, I discovered that when an XML gauge is loaded and being scheduled already, some A: or P: variables aren't yet in a post-loading state and issued events are ignored, during the first few schedules of an XML gauge.I simply bypassed this problem with an L: init counter, that increments at every (55 msec) schedule and the main code of my gauge doesnot become active untill that initialisation counter reaches 20 or so.However, in FS9 and especially FSX this problem has become worse (longer load times ?), to the extend that under some conditions the gauge has to run for more than 7 sec., i.e. 126 schedules, before an issued event is actually "seen" by FSX.An example: (but I'm sure it's a generic problem)In one of my control gauges, I want to make sure that, when loading an existing flight, the aircraft's flaps handle var (not: flaps surface) is in a certain position that I force by giving a FLAPS_SET event, before the rest of the gauge code becomes active.Worst case sofar (on my PC of course), FSX was "deaf" to this event during the first 130 schedules of my gauge.This happens when I start FSX after a PC reboot and the first time the filght is loaded (so: no memory cache, and longer load times).And since this might be even worse on a slower PC, I don't want to rely on absolute times anymore for initialisation so I now use an initialisation phase in my gauge where I toggle a function twice (I use Strobes lights) and observe proper reaction of the Strobe lights variable, so I'm sure FSX is ready to receive events from my gauge.This works perfect, but I'm sure there must be a more clever solution ..LoLDoes anyone recognise this problem c.q. can you shed some light on it ?? (especially: the loading proces of FSX during flight loading).Or even better: answer the question I started this post with ?Thanks in advance,Rob BarendregtPS: needless to say, I may be way off with some of the assumptions I make above; without understanding (yet) how the flight loading process of FS works in detail, I can only draw conclusions on what I observed in numerous experiments ... :(

Maybe try something like this -- It would not rely on a timer at all..(L:INIT, bool) 0 == if{ DO ALL THE STUFF WANT TO INITIALIZE }(L:INIT, bool) 0 == if{ CHECK/MONITOR "ALL" THE STUFF TO SEE IF IT IS INDEED INITIALIZED, IF SO, 1 (>L:INIT, bool) }If further gauges that are loaded the rely on this initialization then monitor (L:INIT, bool) and until it turns to 1 keep them from doing anything.Roman

Hi Roman,Your suggestion would be true, if I can rely on the fact that all variables are in their final initialisation state (so including values loaded from a saved flight) when a gauge is scheduled the first time.Which I was unsure of.So I did some more tests, and the above seems to be true !E.g. when I read the FlapsHandle position in the first gauge schedule, it is indeed the position as saved in the flight file.So, indeed, your suggestion works Ok.In the Init=0 state, I now just keep issuing the events for all functions I want to initialize, untill all related variables indicate the set values, before setting Init=1 (and thus enabling the rest of the gauge code).Thanks, Rob

Hi,FS9...Cold and dark i want to have all exits open.So one of the inits:(L:exits,enum) 0 == if{ (A:EXIT OPEN:0,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_1) } (A:EXIT OPEN:1,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) } (A:EXIT OPEN:2,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_3) } (A:EXIT OPEN:3,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_4) } 1 (>L:exits, enum) } I failed, just one opens, mostly nr. 1.What to do?Jan

Hi,FS9...Cold and dark i want to have all exits open.So one of the inits:(L:exits,enum) 0 == if{ (A:EXIT OPEN:0,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_1) } (A:EXIT OPEN:1,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) } (A:EXIT OPEN:2,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_3) } (A:EXIT OPEN:3,percent) 100 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_4) } 1 (>L:exits, enum) } I failed, just one opens, mostly nr. 1.What to do?Jan

Hi Jan,That adds another dimension to the same problem :( Besides the "ignored-events-during-load" problem as described above, this is even more complex since:- The Exit Open variable isn't an "instant-change" variable, but depends on the specified open/close times defined in the FDE.- The AIRCRAFT_EXIT event only has a "toggle" function, not an "on", "off" or "set" function.Since FS9 always starts with closed "exits" (irrespective of how a flight was saved), what would work IMO (not tested):

(L:exits,enum) 0 == if{   (A:EXIT OPEN:0,percent) 0.001 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_1) }  (A:EXIT OPEN:1,percent) 0.001 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_2) }   (A:EXIT OPEN:2,percent) 0.001 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_3) }   (A:EXIT OPEN:3,percent) 0.001 < if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_4) }  (A:EXIT OPEN:0,percent) 0.001 >  (A:EXIT OPEN:1,percent) 0.001 > &&  (A:EXIT OPEN:2,percent) 0.001 > &&  (A:EXIT OPEN:3,percent) 0.001 > &&  if{ 1 (>L:exits, enum) }} 

Rob

Hi,Tried that one already, but no succes.Jan

Hi,Tried that one already, but no succes.Jan

Hi Jan,I suddenly realised this is about the Toggle_Aircraft_Exit event; IMO the worst event in FS (timingwise) :( Problem with this event is, besides it being a multi-event function, that is has a builtin delay: it takes appr. 1 sec. (framerate/performance independant) before the result of the event becomes visible in an Exit variable.Even if the Toggle event is immediately followed by a Select event.Probably a residue of very ancient FS code ... Hence the current code is constantly issueing toggle events, causing the exits effectively to remain closed (unless some unpredictable timing/scheduling causes detection of an Exit value slightly greater then 0)What does work: (tested fully):

(L:init,bool) !if{  (P:ABSOLUTE TIME,seconds) (>L:time,number)  1 (>L:init,bool)}els{  (L:exits,bool) ! (P:ABSOLUTE TIME,seconds) (L:time,number) > &&  if{      (P:ABSOLUTE TIME,seconds) 2 + (>L:time,number)    (A:EXIT OPEN:0,percent) 0.1 <    if{ (>K:TOGGLE_AIRCRAFT_EXIT) (>K:SELECT_1) (>K:SELECT_2) (>K:SELECT_3) (>K:SELECT_4) }    els{ 1 (>L:exits,bool) }  }}

So the code does two things:- It repeats the events should they be lost during flight initialisation (my problem described in the first post)- It ensures that the events are given only once per 2 sec, to prevent a new Toggle event during the "dead" time.Works in FSX as well..Cheers, Rob

Rob,Thank you!!Jan

Hi Jan,Hope it indeed solved your problem as I "advertised" ....Cheers, RobPS: I may have asked this before (but due to my age I forgot), but I always wondered what the latin? statement in your signature means :( Groetjes, Rob

Rob,Werkt perfect.(Horatius, Epodes 2, 1) over het leven op het platteland (Fryslan)Letterlijk vertaald: "Gezegend hij die ver van beslommeringen......"Jan

PS: I may have asked this before (but due to my age I forgot), but I always wondered what the latin? statement in your signature means

For the benefit of those who're language handicapped:

“That one is lucky, who is far from business.” It refers to the country life in the Roman Empire far away from the (stress of the) city and its business.

Fr. Bill,Peccavi, mea maxima culpa.Jan

Wow..... Never expected to learn some more Roman history on a flightsim forum ... :( :( Cheers, Rob

Nota bene: the "business" referred to is thought to be an oblique reference to "politics," which considering the era was frequently quite messy, not to mention unhealthy... :(

In 1833, General Charles Napier captured the town of Sindh in India. He reported his success with a one-word telegram - "Peccavi"