rcbarend

In fact, Doug Dawson created such a gauge a few years back, named dsd_window_status.gau (freeware).I don't think he uploaded it publically, but you can find a version of it (for FSX) in my groundhandling addon rcbgh50a.zipI use it frequently to monitor the state of a (visible or invisible) 2D-window, in order to keep it forced open after view changes.Rob

Hi,Another reason to be carefull with renaming aircraft folders:- Addons with "configurators" might get confused; especially if they have registered pathnames in the Windows registry.- Same goes for Un-installers- Some gauges in the panel of the addon may rely on absolute pathnames (relative to the main FS folder) for initialisation or configuration files. Like the frequently used XMLsound gauge from Doug Dawson, that uses an .ini file to define relations between private variables and pathnames of related sound files. (unless you adapt them too :( ).Rob

This makes sense, and explains the differences we observe. (and checks out with my EHAM runway I measured).However, one thing puzzles me then.If the angular width of the Loc depends on runway length (or more accurate: the distance between threshold and localizer position), this means that the sensitivity of the algoritme that controls LocHold in an aircraft AP either varies a factor 2, or that algoritme has to know this distance in order to maintain equal sensitivity to Loc. deviations for all airports.Which is it ?Rob

Hi Dai,Using value 1.7 in your formula, means the Localiser width (Beam width) is 3.4 degrees (double).Seems a good average, given mgh's values .. :( Though I still wonder why they are different for airports in FS (are they different IRL ?? )I got my value from EHAM, calculated from measuered distance to the centerline (that is: where the Loc variable indicates +/- 127) at any distance from the Localiser; from what I measured, appears to be lineair.Pitty though that the specific beam width isn't available as a variable.Rob

Yep, you are absolute right :( I used the wrong corner ..... Yes of course, otherwise the FS LOC variable isn't usefull.Another "limitation", although an automated turn (based on ILS) would normally not be initiated outside the beam; unless you're too close to the Localizer, but then there's something wrong with the approach :( Yes; that's why I said "(for simplicity, I assume between 0 and 90 degrees)".Thanks for the correction....Rob

Hi Dai,Here' some other formula's:A few definitions:'a': half the beam-width of the Localizer; i.e. where the LOC-value changes from 0 to 127 (or 0 - -127). Normally this is 1.7 degrees. (I just measured that with my XML distance calculator gauge on several runways in FSX.'b: the value of the FS LOC variable (for simplicity: I only use the pos. part 0 - 127 here)'c': the current angle of intercept between aircraft heading and LOC centerline heading; so 0 means aircraft is on centerline heading (on or parallel to centerline (for simplicity, I assume between 0 and 90 degrees).'x': the shortest distance between the aircraft and the LOC centerline; i.e. via a line from current aircraft position 90 degrees on centerline.''y': DME'z': the distance to the centerline, on the current aircraft heading.'w': the DME value at intercept point, at current aircraft heading.So:-- 'x' = 'b' / 127 * 'y' * sin('a')-- 'z' = 'x' / cos('c')-- 'w' = Sqrt ( 'y'(2) - 'x'(2) ) - Sqrt ( 'z'(2) - 'x'(2) )So given position, airspeed and desired bankangle, it just lacks a formula at which 'x' you should initiate the turn to intercept the centerline with nearly 0 'c'; because that's what you want, right ?I would make this formula adaptive anyway (based on change speed of 'x'), since you also have to take changing winddirection (relative to the aircraft heading) into account.A few sidenotes:Although the formula's above are correct, there are a few shortcuts that will influence it.- DME also includes an altitude component; but at sufficient distance from the runway and normal approach altitude this is negligable.- On most runways I've seen in FS, the DME (if any) isn't located at the Localiser (on or beyond end-of-runway) but at Glideslope position (start-of-runway). But again, at sufficient distance this is negligable.- As said above, not all Localisers are on the runway centerline.- The value of 'a' may not always be 1.7 degrees. Maybe this depends on runway length IRL ?In short: making the perfect Localiser interceptor that works on any ILS, on any airport and for any aircraft isn't as simple as it looks :( In fact, I think one could make a much more accurate (without the shortcuts above) "runway centerline intercept function" based on GPS data for position/altitude of the touchdown point, and not based on the FS Localizer.Succes, Rob

EDIT: Oops, see next post ..

I have to disappoint you on the VC part; I assume that is "wishfull thinking" :( This will in principle be a "compatibility release; a VC would require a new model, and I'm afraid the original source code is lost and the original author has left the FS-scene as far as I know .So that is most likely not going to happen ....Rob

For those who can't wait ...The package is now available at simviation.com, file TB2MOLE-1-1.zip (category FS2004-Misc).I'll upload it here on avsim myself in a day or two ...Enjoy ..Rob Barendregt

Hi Tom,Although I never used this sort of code, the indentation in your code snippet suggest that the delay should be within the Scale tag.So: <Scale Y="-2.3"> <Delay PixelsPerSecond="1"/> </Scale> Don't have a clue if that helps :( If you can't get it working within the animation, you can always bypass that by having an extra LVar:So an boolean Lvar that indicates the position (on or off), and your current L:var displaying the lever. The latter changing value slowly.Something like: (L:Var1,bool)if{ (L:Var2,number) 5 + 100 min (>L:Var2,number)}els{ (L:Var2,number) 5 - 0 max (>L:Var2,number)} So if you change L:Var1 from False to True, L:Var2 will change from 0 to 100 in 20 steps, in 0.9 sec (with max. update freq 18 * per sec). Vice versa.I used such code in a few variants to prevent axis levers (or axis commanded by keys), to jump from one to another extreme value.Calling it "lever-smoothing" :( Just a workaround of course, the other way would be better. Cheers, Rob Barendregt

Hi Dave,That thread started in sept. 2010, so just half a year ago :Big Grin:Unfortunately, the guy that is doing the main part of the work (replacing all of the non-FSX-compatible gauges), has a lot of other real-life stuff on his mind at the moment. So it's delayed a bit.After all, this IS freeware, right ??The good news is, that I have finished almost all of the changes (plus some more extra's) in my own part of the panel, needed to make it run properly in FSX.So you need a little more pacience ....Sorry.. :( Cheers,Rob BarendregtPS: By the way, this won't be a ProjectFokker release, since ProjectFokker has stopped any new development (as explained by Ton on the PF website) last year.But (on a personal note) I have put so much energy in this addon myself, that it would be a waste not to have an FSX-compatible version of it.And as far as I'm concerned, there will be one eventually. When ? Sorry, no commitments ..Hope you understand ....

Hi Martyn,Good to hear from you !!And Yes, I remember .... :( In fact, Libardo is giving you and Brian credit in his README for inspiring him in making this new model :( As you may know, my "VTOL" implementations have quite evolved a bit since we last spoke; but you can judge it yourself when it's released.As far as max speed is concerned: as we have it now, it's doing Mach 1.5; no problem to get it faster, but there are a few reasons not to.Best regards, Rob

Hi Luis,Thanks.Now, since you obviously know you way around the island :( , and both Libardo Guzman (the model designer) and I don't have the first clue about scenery design: would you be interrested/willing in helping us out by implementing any of the features you mentioned (especially the launch platform) ??No need to answer it now (although a Yes would be very much appreciated :( ), untill you've seen what we come up with. We'll most probably release this Thunderbird-2 within two weeks (FS9 first, then FSX), so you can judge yourself if it's worth your effort.Best regards,Rob Barendregt

Right :( Actually, the real Thunderbird-2 was very shiny; don't forget that current technology in FS-design is far more advanced then what animated video technics could handle in the days this TV-series was created .....Hence, our model represents the real Thunderbird-2 far better then the creators back then ever could ...If you understand what I'm trying to say ..... Cheers, Rob

Hi,Just a heads-up for an upcoming freeware release.FS9 first, FSX after that ...Cheers, Rob

That's exactly what I told him ... :( I know I'm a flightsim adict as well, but the amount of time&money this guy is willing to spend on "only" a simulated cockpit environment, exceeds my possibilities by far :( Just another angle to our "hobby" ......Cheers, Rob

hmmm.. I've read you post 3 times, especially the part "" ...by positioning the joystick axis such it matches the "actual" throttle position, prior to disconnecting the autothrottle! .."I guess you mean: ""... by positioning the joystick throttle lever/wheel such that it matches the actual throttle axis position, prior to disconnecting the autothrottle""Right ?If so:No, not possible. That is: not in a 'simple' gauge.Normal gauges just read the FS variable for Throttle Axis, which in your example is the last set value by the A/T the moment you disconnect it; NOT the actual setting of the joystick lever/wheel.The reason you see the "jump" of the lever in your throttle (quadrant) gauge, is that FS detects a change in the value of your joystick throttle wheel/lever. Either because you move it, or the electrical output of the joystick lever/wheel "jitters".You have the same effect in the following case:- Set your joystick lever/wheel in a position where possible "jitter" has no effect: e.g. (if you calibrated your joystick right, with sufficient null zone) in the Idle position.- Press F4 (full throttle). The lever in your Throttle Axis gauge will now indicated "Full Throttle"- Slightly move the joystick throttle wheel/lever. The lever in your throttle lever gauge will jump to the actual position of your joystick throttle wheel/lever.What you're after is a gauge, that shows both the current value of the Throttle Axis as FS knows it, AND the current value of your joystick throttle lever/wheel assigned to that axis.For the latter, you need a gauge/module that reads (via DirectX) the actual value of the joystick wheel/lever.Can most likely be created (FSUIPC does it this way), but it's not simple.And I'm pretty sure that a gauge that displays both the FS throttle axis position AND the actual joystick throttle lever/wheel position has never been made.Including the Whazzup gauge mentioned by Bob; this merely displays the FS variable values.Hope this explains it a bit.Rob PS:For completeness sake: what you are really after, is a way to synchronise your physical throttle lever/wheel with the FS Throttle axis value.And even THAT is possible to make.A friend of mine created a servo-driven throttle quadrant for his home-built cockpit setup, where the physical levers actually move when the FS A/T changes the value of the FS Throttle axis variables. Just like the real thing.But that another leage of HW/SW for the MSFS flightsimulator :(

Hi Luis,Thanks for the info.But would it be possible to make the platform moveable (=tilting, like a blast screen) as well in FSX ??By the way, no need to explain how in detail, since I don't have the first clue about scenery design anymore, or what the FSX gamepack is :-)At this stage, I just want to have a feeling if it would be possible or not.Best regards, Rob

Hi All,With a design-friend, we are releasing a freeware addon aircraft named Thunderbird-2.For those of you not familiar with this old TV series (and movie) about "International Rescue": It's a large, VTOL spaceship that can also be launched from an angled platform.I.o.w.:The aircraft taxies onto the platform and stops, the platform tilts up on one side to about 20 degrees (like the blastscreen of an aircraft carrier) with the aircraft on it, and the aircraft can now be be launched.Is it even possible to create such a scenery object in FS9 ?Or in FSX ?Thanks for any insight ...Rob BarendregtPS: The Launch part itself (FDE) isn't the problem; that's already working (from a hillslope, near the top of a hill, in the scenery)

Hi,I agree with Jan, that if the localiser has a DME, it's rather trivial.If not, two other options are:1. If you can readout the coordinates of the Localiser, it's easy as well.Have several examples in XML how to calculate headings and distances given two sets of coordinates.2. If no Localiser coordinates available:You can create you own DME, by using change-in-CDI-value per timeunit, which of course depends on airspeed, intercept angle and distance from the Localiser. Less accurate though.Rob

Hi, What's unclear about post #5 ?? Because that describes exactly what you want to do.(one gauge in a new window, overlaying a gauge in the main panel window).Just that; no need to change any other window in that panel.cfg

Yes, of course it does.If you change the size_mm of an existing window with a lot of gauges, you have to change all gauge placements ..Manually or with Panel Studio.But that was not your question.You asked about a single pop-up gauge overlaying the main panel. For that you don't have to change the main panel window.Rob

I'm still not sure what you are trying to achieve, but I guess you want to overlay part of a main 2D-cockpit window with another (pop-up) gauge, at an exact location and an exact size (both relative to the underlying main panel window).If so:The accuracy of the window_size and window_pos values (minimal position/size changes) is determined by the size of the overlay window. So it's much better to define a window larger then any screen resolution, and let FS scale it to a fullscreen (transparant) window, using window_size=1,1Like in:[Window**]size_mm=2000,2000Background_color=0,0,0 window_size= 1,1window_pos= 0,0visible=0ident=WhatEverYouUsegauge00='YourGauge', hor-pos, vert-pos, hor-size, vert-sizeThis allows you to position your overlay gauge pixel-precise anywhere on the screen, with pixel-precise dimensions.And also makes it easy to add more gauges in this overlay window, overlaying your main panel window with multiple gauges.Like now(just an example):gauge00='YourGauge', 900,900,200,200 will be visible exactly in the center, with a size exactly 10% height/width, of the window FSX runs in (c.q. your screen when in FullScreen mode).Rob

No.For the obvious reason that Ed mentioned :( Rob

Hi,As David (Opa) says, the main problem of using the FS9 PF-F28 in FSX is the panel (i.e. a lot of the gauges).The model and FDE works perfect in FSX (including things like independant taxi&landinglights).The good news is, that I've allready modified a lot of the XML gauges in the package (that required quite some modifications due to nasty FS9-FSX incompatibilities in XML).And the old-style (incompatible) other gauges are being replaced with FSX-compatible ones.In short: in nothing comes in between, you can expect an FSX-compatible version soon.Still without VC though for the time being, since the original model code (required to add a VC) appears to be lost.Cheers, Rob Barendregt