Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

751 Excellent

About Stearmandriver

  • Rank

Profile Information

  • Gender

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
  • Virtual Airlines

Recent Profile Visitors

2,872 profile views
  1. Someone pointed out on another forum that in order to make the eye-adaptation setting of zero give the desired effect, they also had to set color grading to zero. I've had color grading turned off for a long time so it didn't occur to me that the two might be related... but worth a try for anyone seeing no difference when trying to turn eye_adaptation off.
  2. I really don't see any hostility here. I just see folks being emphatic about what was actually happening. No harm in that!
  3. No, Bijan couldn't... but ORBX could. That's the whole point. These AREN'T ORBX trees. They're NOT placed by ORBX. If they were, Bijan's mod wouldn't touch them. The problem that's being created here is being created not by Bijan's mod, but by ORBX. If ORBX cared enough to exercise any control over those trees, then they'd be exactly what ORBX made them and Bijan's couldn't touch them. ORBX didn't care enough. So they just slapped down some autogen.
  4. This is easily manageable by a scenery dev. If ORBX didn't want stock vegetation there, they would have placed a veg exclusion polygon there, and then handplaced tree models. Instead, they decided to just use a generic area of autogen. Thus, this area isn't ORBX's work... it's a generic area of default sim autogen veg. The entire purpose of Bijan's mod is to modify generic areas of sim autogen veg. These areas aren't custom scenery, though custom scenery can contain them. I've built sceneries both ways - using autogen when I wasn't concerned about exact veg models (though I always test with and without Bijan's and have always preferred the Bijan's results); and using autogen exclusion polygons and handplacing veg models when I wanted total control.
  5. No. He's not. If ORBX had actually done their "own" work on this, they would have handplaced (possibly custom) individual tree models there. What they did instead was slap an area of autogen vegetation in the affected area. They probably specified a biome. The biome they specified was probably not supposed to contain conifers, as many of the default Asobo biomes are very wrong. This is why you so often see things like generic conifers in areas of the world that should be upland hardwoods, etc. One of the many things Bijan's mod does is replace these incorrect tree models with more biome-appropriate ones. In summary: Bijan's only modifies stock autogen (for improved accuracy and variety.) If ORBX had actually custom placed anything other than a generic autogen veg polygon there, it wouldn't have been modified.
  6. If you guys could see cloud depictions in the most advanced visuals ever designed for level D sims... ... you'd choke. 😁 Look at all the screenshots in this thread, and then realize they're all happening on your little home computer. Expectations might need some managing lol.
  7. VNAV is the most often used flight guidance mode in a descent (though certainly not the only one, and it is at the discretion of the PF to choose what they feel is appropriate to the circumstance.) VNAV provides speed and altitude protections that other modes do not, though, and so staying in VNAV to the extent practical is a good idea. The most frequent initial descent clearance given in U.S. airspace is "pilot's discretion", meaning that the pilot flying can choose when to start down. This is why VNAV is used: it will start down at its computed TOD. Further on, the descent will likely be converted to a "descend via" (as most airline airports in the US use those now). So if you've got the arrival with all restrictions loaded in the box appropriately and are already descending in VNAV, you're already on the path and just need to set the bottom altitude in the MCP. ATC will sometimes (or often) modify your descent at some point, and/or the actual wind will be a little different than forecast, requiring the use of speed brakes or a thrust addition... but in a perfect world with good data and no modification, the idea is to stay high as long as possible, and then fly an idle-path descent. This is what VNAV tries to accomplish, and that's how the TOD is used.
  8. Yup and even without the eng driven pumps, the engines will suction feed... up to a certain altitude.
  9. I've never understood the "handle of shame" mentality of not wanting to use the speed brakes. Boeing put that handle in the airplane for a reason ;). Honestly, I've watched people over the years get themselves all twisted up with convoluted flight guidance tweaking (being oversped the whole time they're doing this) in an effort to avoid using the brakes (or throw out the gear when it's clearly necessary) in an effort to avoid the rumbling noise for passengers. My two thoughts about this are: 1. We always prioritize precise management the aircraft's flight path ahead of passenger comfort. 2. The pax DO NOT CARE. I commuted for almost 16 years which means I rode in the back twice a week (when I wasn't in the jumpseat), and I observed this over and over. The passengers do not care or even seem to notice things like speed brakes or a gear extension at 250, etc. No one looks up. No one pauses their conversation. The flying pilot might be up there twisting himself into knots of distraction, trying to find a way to magically add drag to the plane without actually adding drag to the plane... but NO ONE ELSE CARES lol. (They also care nothing about standard PAs... they just want you to shut up so they can finish their phone call before the door closes, or finish their movies in flight before the stream gets shut down on landing.)
  10. There are actually quite a few differences between flying an RNAV approach in LNAV/VNAV vs IAN. One of the largest has already been mentioned: IAN is for straight in approaches. A curving approach, especially an RNP (AR) with RF legs, cannot be flown in IAN, which is why most airlines do not use this mode or even have it. Different airlines take different approaches to setting an MCP altitude. Some like to set mins, and then "spin through" current altitude up to the missed approach alt once field is in sight or when approaching mins. The threat here is that the flight guidance might capture current altitude, destabilizing the approach. Another option is to set field elevation in the MCP when cleared for the approach (actually you round down to the hundred foot setting below field elev) and leave it there for the landing. If you miss, you have to get the MCP alt set on the go-around. We tie it to the "gear up" call. Functionally, it does not matter which method you pick, they both work fine... it's just good to understand why you're doing it that way ;).
  11. The 737 BBJ is the obvious answer... you're not going to find anything in a desktop sim that's simulated as well as PMDG does the 737 family.
  12. I've wanted to do this many times, especially with visibility as there's currently (and idiotically) no way to set a specific visibility value; you have to play with aerosol and precip density to get something close to what you want. And yet, live weather can accurately match metar reported vis... but they don't give us a way to specify it. I honestly think the crippled user control of weather is one of the largest glaring errors in the current sim design.
  13. My after start checklist reads "electrical - generators on" and MCE accepts this response as correct with no operation or double check of the gens, no "now on" response etc. I know what you're talking about, I've seen this happen in the past (even before the PMDG change) but not on the current version. For whatever that's worth.
  • Create New...