ozbeowulf

Why use CAB files in the first place?AFAIK, MSFS used CAB files in FS2002 to reduce the size of downloads, which was fair enough in those days of limited bandwidth and small hard drives. But.... and it's a big BUT... retrieving a gauge from a CAB file is definitely slower than retrieving the same gauge from a simple folder. The project will be a bit larger but that's a one time hit. Faster gauge retrieval pays off every time a panel is opened or a new window is called up.I gave up on CAB files a few years back. I use folders instead. The only problems have been the occasional downloader who decides to open the gauge folder(s) and manually move the loose files into the FS GAUGES folder. But so what? We'll never eliminate RFTI errors.Just one man's opinion....Glenn

Whether or not you use FSUIPC can make a big difference, too.Cheers,Glenn

Hi, Gavin...MGH is quite correct. Revs should increase during the takeoff roll. Likewise, a dead engine with a fixed prop (or an unfeathered variable pitch prop) will windmill while in flight. Generally speaking, the only way to stop a fixed pitch prop in flight is to slow down to stall speed or below. Occasionally, props on small GA aircraft will stop as the aircraft enters a spin, but you can't count on that.Cheers,Glenn

HI, Vern...I don't think you can completely eliminate an AI aircraft from the Select Aircraft menu, but you can easily minimize its intrusion. In EACH section of the offending aircraft's aircraft.cfg file, modify the "ui_manufacturer=" line so it reads something like this: "ui_manufacturer=AI Military." Obviously, it could just be "ui_manufacturer=AI" if you don't want subsections.AFAIK, this is as close as you can get to reducing the appearance of AI aircraft in the Select Aircraft menu.Cheers,Glenn

Thank you, Bill...Email on its way.Cheers,Glenn

Thanks, Cal, but this was an aircraft that Bill had modified. It shows in the aircraft selection pop-up menu as Eaglesoft.Viewed from above, the "aircraft" is a flat array of concentric squares centered on that FS9 red cross you mentioned. The advantage of Bill's gadget is that when you zoom way down there is no aircraft fuselage visible, just the transparent squares. Used with EZ-Scenery and the overhead view, it is perfect for aligning buildings with a tarmac edge, for instance.In case it joggles any memories, the cockpit view from Bill's gizmo is an early open-cockpit from WWI or the early 20s. I can't remember which aircraft he used as the basis for the placement tool.Cheers,Glenn

Oh, boy, it sure is fun rebuilding after an HDD crash.Bill (or anyone who remembers)....A few months ago, you posted a "aircraft" model with a crosshairs box to accurately place FS9 scenery objects using the overhead view. I've been trawling back through the forum, but I think it might been in a thread with a name that didn't relate to that tool. I've come up empty.It was a very useful gadget and I'd like to find it again. Any ideas where it is, anybody?And, yes, what you're thinking is absolutely correct. I'm off now to buy an external HDD for frequent backups.Thanks, Glenn

Hi, Bob...No need to push values into panel swap K events. Try this instead... (>K:PANEL_2)(>K:PANEL_1) or (>K:PANEL_1)(>K:PANEL_2)Another variation: To switch to a flight engineer panel (if there is a window involved) use.... (>K:PANEL_1) (>K:VIEW_RIGHT) (>K:PANEL_4)Cheers,Glenn

Hi, Willem...I don't know how you'd handle it in the VC view. I was guesstimating an approach for a 2D panel in FS9.Good luck with your experiments!Glenn

I haven't tried this, but it should work...Create a transparent full-screen bitmap (R,G,B, 0,0,0), as the basis for a pop-up window. Then add a layer of, say, 25% opacity gray (50,50,50, perhaps). Code that window to pop up whenever the situation suits. You could use as many pop-ups as you like, each with increasing opacity level. The obvious problem is that each change would be abrupt.There is probably some way to perform a top-to-bottom "wipe." Using Flash, perhaps, but that's beyond me.Good luck,Glenn

Very interesting, Herv

Maybe I can help; maybe not.First off, the important thing about the ubiquitous WWII-era four position automatic mixture controls is that they control the fuel/air RATIO. Auto-Rich, for example, does not deliver a single metered amount of fuel regardless of power setting and/or altitude. When the throttle position is changed, more air is allowed to enter the induction system so the automatic mixture control adjusts the amount of fuel accordingly but it always maintains the same fuel/air RATIO. Likewise, during climb or descent, as the air density varies the amount of fuel delivered changes but the fuel/air ratio does not. I do not know the specific fuel/air ratios for the system installed on the A-20, but I'd bet they are the standard ratios developed for Amelia Earhart's long distance flights by Kelly Johnson (of Skunk Works fame i.e., 0.073 for economical cruise power and 0.083 for standard climb power.Last year, I developed such an automatic mixture gauge to do this job after a public query about automixture by FSAviator. This is the relevant section of xml code...(L:automix sel, enum) 0 == if{ (>K:MIXTURE1_RICH) } (A:Eng1 manifold pressure, inHg) 34 > (L:automix sel, enum) 1 == && if{ (>K:MIXTURE1_RICH) } (A:Eng1 manifold pressure, inHg) 34 < (L:automix sel, enum) 1 == && if{ (G:Var1) 0 == if{ 1 (>G:Var1) (P:Local Time, seconds) 10 + (>G:Var2) } } els{ 0 (>G:Var1) } (G:Var1) 1 == if{ (P:Local Time, seconds) (G:Var2) > if{ (>K:MIXTURE_SET_BEST) } } (L:automix sel, enum) 2 == (A:RECIP MIXTURE RATIO:1, enum) 0.073 < && if{ (>K:MIXTURE1_INCR) }(L:automix sel, enum) 2 == (A:RECIP MIXTURE RATIO:1, enum) 0.075 > && if{ (>K:MIXTURE1_DECR) }(L:automix sel, enum) 3 == if{ (>K:MIXTURE1_LEAN) } A few points: 1 - I was unable to get the code to work correctly if I used A:RECIP MIXTURE RATIO to assign values to both Auto-Rich and Auto-Lean. That's why I used K:MIXTURE_SET_BEST for Auto-Rich. That delivers a fuel/air ratio of 0.0846, which is close enough. (Accordingly, K:MIXTURE_SET_BEST can be used to, in effect, toggle FS9's Automixture function on and off.) 2 - This system worked fine during flight tests according to AFSD. However, FSAviator believes that FS9 would not behave correctly if the fuel/air ratio is set to 0.073 and would alter the flight model. I did not see any evidence of that, but my flight-testing of this system was fairly brief. I was deep in another project with manual mixture controls (but fuel/air ratio meters) at the time.FWIW,Glenn

Hi, Bill...I am happy to see your post and relieved to learn that I'm not the only one who is bemused by all the useless caterwauling.Cheers,Glenn

Might I suggest that too much effort has been invested in the straining of gnats?Don't overwork the physics; look at the desired output and work with the cause and effect relationship. When the cold and dark aircraft is sitting on the ramp, the brake temperature is the ambient temperature as shown on the OAT gauge. Let the code change the temp variable by a small percentage each time it refreshes. Adjust the variable pos/neg value and the gauge refresh rate so the temp increases slowly whenever brakes are applied and decreases slowly (but never below ambient) when brakes are off. If you want to get fancy, introduce an aircraft speed variable to the process. Test-taxi the aircraft (including aborted takeoffs) and adjust values as necessary.In the end, you'll have a gauge or gauges that follow the dynamics of the brake heating/cooling cycle. It won't be perfectly accurate, but sometimes we have to accept that FS9 cannot model reality to the nth degree.Cheers,Glenn

Hi, Martin...FWIW, I use code like this...(>K:PANEL_2) (>K:VIEW_RIGHT) (>K:PANEL_4)This gauges is located in Panel 2. It toggles panel 2 off, swaps outside views and toggles panel 4 on. (The view change element is needed because both panels have windows and they face in different directions.) If your overhead panel doesn't fill the monitor screen, you only need (>K:PANEL_2) to pop-up the overhead panel.Good luck,Glenn