rcbarend

Hi,Maybe I misread what you write, but I sounds like you just want to move the "eyepoint" (the pilot's head) backward.See the all the commands for moving the eyepoint in the VC (fore/aft, up/down, left\right). They just move the pilots head in the cockpit, without affecting the zoom (including the zoom outside).Rob

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

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

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

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 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 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 ... :(

With already 10 replies, and 256 views, I can't resist ..... :( Cheers, Rob

Another tip, although not relevant wrt. to your question:If you use variables that should retain their value overtime (like you use G:Var1 now), in general try to avoid using G:Vars but use your own defined L:Vars instead.Because under some circumstances (like reloading a panel in FS9 after editting a gauge, or changing from FullScreenMode to WindowedMode v.v.) G:Vars are reset to 0.Which usually isn't what you want/expect :( Cheers, Rob

Alternatively, you can do the following:- In the \Panel\ folder of the aircraft, create a subfolder with the same name as the .cab file.So if the file is named Overland.cab, the folder name should be Overland- Place the new bitmap in this new folder.FSX will now use the modified bitmap in this new folder, instead the original from the .cab file.Quite a handy trick sometimes.Cheers, Rob

As far as I can tell it's just the old Alphasim V22 package under a new company name.Nothing wrong with that, because it's still (IMO) the best V22 model out there. Apart from the lack of true VTOL of course :-)And the reason it's on sale for a day: the modification date of the .mdl files of that Alphasim package is Sept. 16th 2007. Now, that date cannot be a coïncidence ...LoLRob

Hi,If this is for FSX:I haven't tried it, but try to enclose the whole Select structure into an additional Element.FSX seems to be very picky on the syntax of Element nesting, and I have a few examples of my xml gauges that worked fine in FS9, but had to add another Element structure because a bitmap or textstring wouldn't show up in FSX.Example: <Element> <Visible> (A:SPOILERS LEFT POSITION,percent) 10 > </Visible> <Position X="52" Y="24"/> <Text X="47" Y="12" Length="10" Font="arial bold" FontSize="12" Color="#FF0000" Adjust="Left"> <String>AIRBRK</String> </Text> </Element> works fine in FS9, but not in FSX (won't display the string AIRBRK)If I change it to <Element> <Visible> (A:SPOILERS LEFT POSITION,percent) 10 > </Visible> <Element> <Position X="52" Y="24"/> <Text X="47" Y="12" Length="10" Font="arial bold" FontSize="12" Color="#FF0000" Adjust="Left"> <String>AIRBRK</String> </Text> </Element> </Element> it works fine in FSX.RobPS: Next time, use the "Insert code snippet" function to insert XML code into a post; makes it a lot more readable :-)

If you like, you can try out the FSX version of my GPWS gauge (which you can easily strip down to just Alt. callouts if needed).Just drop me an Email.Although it's still a beta, it has been tested by quite a few users already.Works OK with FSX-SP2 or Accel, on XP and Windows7Rob

Hi Glenn :( ,Yes, understanding how Postfix notation (or ReversePolishNotation c.q. a stack-operating language) works, is a key to understanding how XML works in FS.Don't know why Arne's xmlgau01.zip document is blocked for download, but I can mail it to you if you want.For me, it was how I learned understanding coding in XML many years ago ....ALthough the "official" syntax changed from FS2K2/FS9 to FSX (why ??), most of the FS9 syntax still works perfectly in FSX.With a few exceptions:- (discovered by Bill): in some cases, case-sensitivity seems to be an issue (in FS2K2/FS9, there was no difference between capitals or not).- some other minor stuff (I have a few examples of code that works fine in FS9 but not in FSX). But that might be caused because FS9 is more tolerant to "coding-errors" than FSX.Most designers seem to stick to the FS9 syntax, simply because they are used to it (like me).Cheers, Rob Barendregt

:( Thanks Bill, that's what I thought I remembered ....I won't tell anyone else .... :( Thanks again, Rob

Hi Bill (andAnthony),Old habit, I think :( to use the generic Number instead of Bool unit.But of course you're right; using Bool would be more logical....Although, for L:vars, the implementation of Bool in FS is the same as Number, isn't it ?I mean, when I assign the value 1.5 to (L:Test,bool) and read it as (L:Test,bool), the read value is 1.5.Again, this is pretty useless either ... :( , but I'm doing some faultfinding in the "Visibility" tag specified before (because controlling the visibility of that part doesn't work), and I want to exclude the possibility that it has anything to do with the used XML syntax.But I will try it anyway, although I'm pretty sure the problem lies elsewhere.Thanks anyway ...Rob

Hi Bill,Can you confirm that the Code line in:<PartInfo> <Name>Prop0_still_mine</Name> <AnimLength>100</AnimLength> <Visibility> <Parameter> <Code> (L:PropStill,number) </Code> </Parameter> </Visibility> <Animation> etc...... does exactly the same as the Code line in <PartInfo> <Name>Prop0_still_mine</Name> <AnimLength>100</AnimLength> <Visibility> <Parameter> <Code> (L:PropStill,number) 0.5 > if{ 1 } els{ 0 } </Code> </Parameter> </Visibility> <Animation> etc...... ??With (L:PropStill,number) being a boolean, that is set in a gauge to the value "0" or "1" (thereby controlling the visibility of that animation part, depending on certain conditions)Thanks, Rob

Please judge for yourself if you miss it or not :-)What rcbgh50a.zip does:- Adds a permanently-visible Icon on the screen; which you can place in any position on the screen.- Via mouseclicking this Icon, you can open/close the Groundhandling window.- When the groundhandling window is open, it remains forced open (even if you change views).Some people find that very handy, because they can switch to other views (eg. during a pushback) with losing the GH window.Cheers, Rob

Hi Ray,But are you using the permanent Icon addon (rcbgh50a.zip) ?And if so, does switching from windowed-mode to fullscreen mode v.v work OK on your PC ?Rob

Yes, no problem.I have quite a few examples where XML code from one of my addon gauges can interwork (via setting/reading L:Vars) with XML code in the .mdl file.Regards, Rob

Hi John,Can you please send me the panel.cfg you are using via Email (see my READMEs for my Email address) ?So I can verify everything is installed correctly ?Reason I ask: the last few months I get quite some support requests from people that install any of my gauges (groundhandling, Carrier ops, VTOL, etc) on Windows7 systems with a complete re-install, and with one exception it always turned out to be an error in installation.(ie. one user that couldn't get my carrier ops working other than in a non-full, windowed-mode screen).Not saying you made such an installation error of course, but I just want to exclude the possibility.I don't use Windows7 myself, so I can't verify such a problem; and your particular problem is new to me. By itself, that says nothing, but in 9 years supporting all of my gauges, my experiance is that if only user reports a specific problem, then usually the problem lies somewhere else.So I'm very curious to know if any other Windows7 user is experiancing the same problem (your description is very clear, and apperantly repeatable).Or even more: a Windows7 user that DOESN'T have the problem you describe.Regards, Rob Barendregt

Yep, that makes sense :-)I just realised I use a different definition of "hidden" gauge (i.e. a control-type gauge without clickspots)Rob

Try event JOYSTICK_CALIBRATE.Sounds like a misleading name, by that is the event defined in the fs9.cfg file for Control-K (= Toggle Joystick On/Off)RobPS : Although I'm still puzzled by your question.What do you mean by pressing a hidden gauge ... Mouseclicking it ? If so, then it can't be hidden.If not mouseclicking it: why a gauge (since there's allready COntrol-K) ?

A flight is saved in two files: 'flight".wx and 'flight'.fltThe .flt file is readable text (open with eg. Notepad) and contains the panel window size/position/visibility info at the moment you saved the flight.Rob