Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ozbeowulf

  • Birthday 07/13/1940

Profile Information

  • Gender
  • Location
    NE Australia
  1. And the same formula can also be used to scale Vr and Vref.Cheers,Glenn
  2. Try Tom Gibson's CalClassics site.Doug Dawson worked out the two-stage blower problem. IIRC, it requires FSUIPC.Glenn
  3. Patrick has the right idea.In fact, MSFS aircraft are almost always incorrectly set up. In the real world, any supercharged engine will naturally pull more than allowable manifold pressure close to sea level. Accordingly, full throttle at takeoff is used only on small GA aircraft. Otherwise, engine management is required to avoid overboost and subsequent engine damage.Any time limit on WEP (or any other high power setting) is only a warning to the pilot; there is no automatic reduction of power. Well, unless you count engine failures....By setting the maximum manifold pressure in the aircraft.cfg file higher than the allowable max main, realistic engine management is required. It's also accurate (and fun) to code in engine failures if max t/o power is exceeded for more than a short period. (After modifying the aircraft.cfg, the aircraft should be flight tested with AFSD. Other adjustments may be needed to keep performace accurate.)MSFS default aircraft and most add-ons are set up for the don't-read-the-manual/full-throttle-forever/vroom-vroom crowd, but it doesn't have to be that unrealistic. Glenn
  4. Ahhhh, Bob....I think you'll find that most people here make their own gauges.It's not that hard to make simple voltmeters and ammeters, for example. Search here for "tutorials" and have a go. XML, especially, is mostly straightforward (once you get used to the reversed notation).Good luck,Glenn
  5. I used this code recently...(>K:PANEL_3) (>K:VIEW_RIGHT) (>K:PANEL_4)Note this also changes the view because my panels had windows facing in different directions.Cheers,Glenn
  6. Gideon...You have already been advised that manipulating the .air file cannot accomplish what you want to do.You have already been advised that what you want to do would be impractical and unrealistic even if you could do it... which you can't.It seems important to you that you win. Okay, you win. Left is right; bright is dark; hot is cold; if you drop something, it will fall up. Happy now?As the old saying goes, no further correspondence will be entered into.Glenn
  7. Whatever floats your boat...BUT there are several factors you could not see or recognise from seat 5F.First, who knows who or what was actually flying the aircraft. Were the flaps fully deployed before you starting monitoring the power changes? Autopilot on or off? Auto throttle on or off? Autoland on or off? Second, I'm glad you used the 737 as an example. The low-slung engines on a 737 mean pitch trim changes are required whenever thrust is increased or decreased. The bird is well known for that characteristic. Accordingly, I feel safe in saying that there was a pitch change (or pitch trim change, which is essentially the same thing) with each and every power change you heard.Third, you said, "...but the ears and stomach can tell no lie as to what was going on." Sorry, but that is both incorrect and dangerous. When you can't see outside, instruments tell you the truth; stomachs (and ear canals) lie. Always. Think of the old term "graveyard spiral."As I indicated originally, there will always be hangar discussions about which comes first; pitch or power. But the fact remains that regardless of which control input leads, the other must, and will, follow closely behind to maintain a stabilized flight regime.Consider the differences between aircraft and cars. Want to turn a car? It's quite simple. Twist the steering wheel, hold it for awhile, then neutralize it when you're pointing in the right direction. In an aircraft, the same maneuver requires, in order: A roll input plus an increasing pitch input as bank increases and a yaw input to center the ball. Then the roll input is removed, but the pitch input remains and may vary if speed decreases (a bit of power might help here). To exit the turn, a roll input in the opposite direction is needed but it must be removed at the correct time. Simultaneously, pitch is reduced as the wings level while the rudder input is removed in a coordinated movement.You cannot control an aircraft by varying only one input. It may appear that an autopilot is doing that, but other control inputs are taking place simultaneously.But as I said above.... whatever floats your boat. Glenn
  8. Hi, Roelof...When I did some experimenting a while back, MIXTURE_SET_BEST seemed to just be a way to switch the standard FS9 Automixture feather on and off using a gauge instead of the realism menu pulldown. In the admittedly limited testing I did, I saw no need to reset it.Cheers,Glenn
  9. Well, it doesn't work quite like that in the real world. Pitch and thrust are inter-related during climbs and descents.Theoretically, you could climb (poorly) by simply increasing power and, therefore, airspeed. When the aircraft accelerated, the wing would provide more lift at the same angle of attack. To maintain that same exact AoA, you'd have to trim against it, which would mean you were climbing (clumsily) and trimming down at the same time.Climb and descent rates are controlled using both pitch and power.Btw, that "pitch for speed; power for altitude" is only a mantra for beginners. At best, it indicates only which element you introduce FIRST in SOME scenarios. In reality, because pitch adjustments are fast-acting and precise, pitch is used to maintain whichever element (speed or altitude) is most critical in the applicable flight regime at that time. Consider an ILS approach. Staying on the glideslope is more important than a few knots more or less. You get high, let's say, so you lower the nose slightly. That causes the speed to increase slightly, so you also back off the power a fraction. Note: you don't chase the glideslope with pitch; you just adjust the pitch by a degree or two, then hold that new pitch angle until you see how it works.A tight short-field landing is just the opposite. You want that speed nailed close to, but above, stall. Pitch adjustments keep the airspeed correct and power is used to adjust the descent rate.Either way, pitch OR power may be the very first corrective control input, but the other adjustment will probably be needed also.(Boy, oh boy, is this gonna bring the 300-hour instructor pilots out of the woodwork!)Sorry about the long post, but I hope it helps explain why what you want to do is neither practical nor realistic.Good luck,Glenn
  10. Well, first off, the F-16 is limited to 9 Gs, period. That is not an airframe limitation; the onboard computers will not allow more than 9Gs. Remember, the F16 uses an almost rigid joystick. Maximum movement is (IIRC) only 3/8", about 10mm. Transducers measure the amount of force on the stick and adjust the flight controls accordingly. When 9Gs are reached, the computers back off on control surface displacement, regardless of the pilot's control input.It's a good, pilot-proof, system. An F-16 jock can bank and yank as hard as he wants without overstressing the airframe.So the bottom line is, FDE adjustments aside, your G meter should max out at 9.Cheers,Glenn
  11. The site doesn't work for me, either, Ken.I haven't been there for months, but it was falling apart then. The site wasn't being maintained, the bots had loaded it up with porn, etc, and it looked like most of the regulars had gone away.AFAIK, the "new" Easy Gauge never made it past the teaser stage.Fwiw, I switched to xml and, after an adjustment period, I find it easier and quicker than the somewhat clunky Easy Gauge format. Good luck,Glenn
  12. It's spelled "celsius", not "celcius".The incorrect spelling is probably the only problem.Cheers,Glenn
  13. Thanks, Jan...That's pretty much what I'm doing, although you've used a slightly different way to vary the L:var. I'll have a try with your method. There must be something amiss with using my way for both climbs AND descents in cabin altitude. You're quite right about the vsi rate. I'm using a high value for the cabin altitude climb to simulate a rapid decompression, so I just reversed it for testing. I should, and will, use a more normal value for re-pressurization.Fwiw, the Boeing 307 pressurization technology was ground-breaking development and it flowed on into later Boeing aircraft, including the 707, 727, etc. The only major difference was that the 1930s technology did not include an automatic controller, so the flight engineer had to manually tweak the outlet valve to control the cabin altitude. He would have been a busy boy on climbs and descents, me thinks.Cheers,Glenn
  14. I've nearly finished the pressurization system for a Boeing 307, but the last little detail has me stumped. It's probably something obvious I'm missing, but I can't see it.Displaying cabin altitude is simple enough; if the pressurization system is on, the cabin altimeter and the cabin vsi show 60% of the real values. Otherwise, they show real values. All this works properly.The problem is the cabin vsi. In level flight, if the pressurization is turned off or fails, the cabin vsi should show a climb. If pressurization is turned on again, it should show a descent. To get that response, I'm using L:altcabon and L:altcaboff to temporarily stow the 60% of indicated altitude value whenever the pressurization is switched on or off. If the altitude and the L:var differ, the code pushes 4930 or -4930 into L:cabinROC (the value driving the cabin vsi. The L:altcabxx value increases each time the code is read and eventually the L:var and altitude match, so the vsi reverts to displaying either vertical speed or 60% of vertical speed, as appropriate.For some reason, the code below works perfectly when the pressurization is turned OFF but not when it is turned on again. (NOTE: The code values re confusing. "0" is ON and "1" is OFF, so the system defaults to ON for users who don't want to operate it manually.)I am monitoring L:altcabon and L:altcaboff values with test gauges. They are being set properly and are changing correctly.(L:cabpress, bool) 0 == (A:Indicated Altitude, feet) (L:altcaboff,feet) > && if{ -4930 (>L:cabinROC,enum) (A:Indicated Altitude,feet) 0.6 * (>L:altcabon,feet) (L:altcaboff,feet) 4.6 + (>L:altcaboff,feet) } els{ (A:Vertical speed,feet per minute) 0.6 * (>L:cabinROC,enum) }(L:cabpress, bool) 1 == (A:Indicated Altitude, feet) (L:altcabon,feet) > && if{ 4930 (>L:cabinROC,enum) (A:Indicated Altitude,feet) 0.6 * (>L:altcaboff,feet) (L:altcabon,feet) 4.6 + (>L:altcabon,feet) } els{ (A:Vertical speed,feet per minute) (>L:cabinROC,enum) } Any ideas, anybody?Thanks, Glenn
  15. Update...In emails off-forum, Alex and I worked out that I had misread his forum post. I replied referring to the VIEW nnn DIR line in panel.cfg files and I thought he was referring to the DEFAULT Baron, but he meant the DREAM FLEET Baron. "DF", get it?.I have no idea what VIEW nnn EYE means in a panel.cfg file. I've never seen that. Alex says he has seen it in other add-ons, however.Just setting the record straight....Cheers,Glenn
  • Create New...