ILSvector

Ryan, you are reading way too much into these posts. I would support any developer who makes a better version of any airport I fly to/from frequently. I was simply arguing your assertion that the Blueprint KMSP was essentially no better than a freeware version was an unfair assessment. No one here ever said they shouldn't make KMSP or any other airport that already exists. And to stay on topic, the Flightbeam KDEN scenery looks excellent! I have their KPHX scenery and would recommend it to anyone. Coupled with BlueSkyScenery's AZ terrain textures and it's marvelous!

Because that's a factual statement. LOL. I don't want to knock this thread off topic, but just gotta say that's an unfair statement. The Blueprint scenery renders KMSP as it should look today with a level of completeness and accuracy not found in any freeware scenery that I've seen. I believe most of the negativity of the Blueprint scenery is really based on the plain vanilla building textures and lack of custom textured taxiways, aprons and runways. They are not made by texture artists and don't appeal to eye-candy junkies. However, the 3D models are complete and accurate, unlike the horribly out-of-scale models in the default scenery that persist in freeware updates. They also add decent seasonally adjusted terrain textures to the airfield and surrounding area. I think their scenery is fairly priced accordingly.

Dillon, I was responding to the point of the OP as to whether the type of issues would go away with P3D, which was to make a point that there are so many third-party add-ons contributing to the complexity of problems that can arise with the architecture of FSX, P3D. That architecture hasn't changed. P3D v2.2 and beyond can still have issues caused by something indirectly related to P3D. I'm fully aware of all the improvements in P3D related to the sim itself. As an example, after installing ASN, I had strange issues with my frame rates that were tied to a setting I had in FSCopilot. Change, the setting in FSCopilot and ASN plays nice in the sandbox. That same type of issue could easily affect P3D just as it did FSX. I'm not really sure if you're suggesting that I'm spreading "bull", "hostility" or some ill-conceived "static opinion". I wasn't suggesting to the OP that he shouldn't get P3D, I was suggesting that he doesn't get it if he thinks those type of issues will magically go away. As for my own plans, I will move to P3D at the point where I can legally use specific add-ons I currently use in FSX. I'm not a hater. Say, aren't you the guy who skipped FSX altogether? You sound a bit to me like a guy who is continually trying to justify that move. Just sayin'. -Chris

P3D is not the panacea for your FSX ills. It's FSX code and architecture that is being extended and modified. Remember, FSX is an fairly open system allowing a ton of third party add-ons to change things or change the way those add-ons interact that you may not even be aware of. Whenever FSX "was working" and "now it's not", the first thing you should ask yourself is, "what changed"?...graphics driver, add-on update, etc. Those same basic issues, therefore, still reside with P3D. Yep, it can all drive you crazy.

Well played indeed. Now those VATSIM controllers are going to get a lot of thunderstorm deviation requests this spring/summer!

I think they forgot to mention the free interface cable for use with the new PMDG full motion hydraulic platform to be released with SP1. More popcorn anyone?

My first thought to "Man builds 777 replica made out of manila folders" was... "and who hasn't"? All kidding aside, I'll never look at a manila folder the same way again. He's a very talented modeller.

Yep, you are correct...and that's what I kinda figured might've happened to you as you transitioned those levels with such a strong jet stream using default weather. Things must've been well-behaved that day.

Other than shaving a couple hours off your flight, that had to be unpleasant with default FS weather wind shifts...LOL.

Because you're finally getting accurate and complete wind data... I know OPUS and ASN weather addons use the World Area Forecast System (WAFS) wind model with a high degree of resolution, usually 1x1 or even 0.6x0.6 degrees lat/lon at all the standard forecast wind levels. That means you get accurate coverage even in oceanic regions while minimizing or eliminating [horizontal] interpolation issues found with the relatively sparse or nonexistent upper level wind reporting stations in the default FS weather. ASN also does a great job of vertical interpolation to avoid sudden wind shifts as you transition through different wind levels. That's also what makes a model, like Edouard posted, possible. Note: The WAFS wind model is sometimes referred to as GRIB winds, which is a misnomer. GRIB is an acronym for GRIdded Binary, the file structure format used to store the data.

Probably more about the stronger, more complex winter upper air patterns than OPUS itself. Winds are usually spot on, but traversing the wind LAYERS in climbs/descents can cause some radical shifts (which can be somewhat mitigated using OPUS settings at the expense of accuracy). This is where I find ASN really shines...the vertical interpolation between layers make transitioning between a 40 knot headwind at lower levels to a 160 knot tailwind at upper levels just silky smooth. I had what I would characterize as pauses, not stutters. If you're using FSCopilot, make sure you disable the multi-core options (Addons>FSCopilot>Multicore) and that will go away. Proper affinity mask setting, which had unknowingly been messed up on my machine, also made a big difference.

Charles, did you update your Nvidia driver recently too? Just curious if you can confirm going back to an older version fixes this issue without any workarounds.

Yeah, if you think about it, you probably updated your video drivers recently. If you're using an Nvidia GPU, try reverting back to your previous driver. That worked for me. Also see this thread... http://forum.avsim.net/topic/421555-pmdg-777-fsinn/page-2

Despite some good FS Inn tips from Bill Casey, I too was still having this issue that began only recently. We all tend to install and update things besides the recent PMDG 777, so I was trying to think what else CHANGED on my system... BINGO! Video driver! I had been running the Nvidia version 310.90 driver and recently updated it for a <cough>game</cough> to the beta 331.40 and subsequently to the WHQL 331.58 versions. Upon re-installing the older 310.90 drivers, FS Inn no longer freezes on startup after loading either the 777X or NGX at any complex airport. I'm sure other older versions work too, this just happened to be the one I had been using. I hope that helps anyone else with this issue using Nvidia drivers. I'm guessing those without the issue haven't updated theirs or are using AMD GPUs.

They all probably drank milk too. That doesn't make it a direct cause or correlation to what they did. 99.9% play video games without doing those things. Mentally ill people do mentally ill things.

Sorry, I initially skimmed over this thread and thought the confusion over "vertical stabilizer config" vs "config stabilizer" had been resolved. Naturally, my post above was assuming (ugh) others had experienced a problem similar to mine which only references the latter.

I experienced this for the first time today and immediately noticed my pitch trim indication was zero (full nose down). I moved it back to the takeoff setting (2.25) using my joystick trim button and it started moving back to zero by itself. Then I noticed the pitch trim lever was stuck forward causing it move. Using the mouse, I set it back to neutral and reset my pitch trim. I could reproduce the problem this way. I used the mouse (which I typically don't do) to initially set the trim. Upon reaching your desired setting, if you move the mouse away from the trim lever prior to releasing the right or left mouse button, the lever stays in that position (either up or down) continuing to move the trim to maximum deflection. Solution: Verify trim indication stopped moving and the trim lever is neutral. If you are quickly moving through your configuration, you could easily miss this as apparently I did. :huh:

Ryan, If this is happening to you "a lot" then what you are doing "wrong" is not resetting your MCP altitude soon enough thus forcing the energy compensation to kick in (what Kyle said) which lowers your airspeed to potentially allow you to recapture the VNAV path. Judging from your screenshots and your vertical deviation indication, that's what's happening. If energy compensation has kicked in, the technique I like to use (a r/w pilot posted this once) is to use the SPD INTV button and then crank your airspeed back up to say 280 kts (when above 10,000 feet obviously) on the MCP. Now you're trading altitude for airspeed and your V/S should increase significantly until the target airspeed is reached. Once the vertical deviation is back on track, press VNAV again on the MCP to get back to VNAV PTH mode. If possible, reset your MCP altitude before TOD is reached and this won't be an issue. You should get the FMC MESSAGE to do that just prior to that point. I hope that helps a little.

I am officially scolding myself for speaking in absolutes. "Always" was a bad choice. Perhaps "frequently" or "most often" would've been better.

Thanks Phil. No, I understand commercial planners can do this. For routes originating or terminating in the United States, I can always use FlightAware to get current routes flown by the airlines on a given day as they always fly the most advantageous routes for winds aloft.

This planner seems to incorporate a great many cool detailed features into it--and that's super. What continues to disappoint me with flight planners is they all seem to generate the shortest route over the ground and then factor in the winds aloft to calculate fuel burn. When dealing with long range flight planning, sometimes taking a longer route over the ground is faster in the air when taking advantage of winds aloft. Or say avoiding 100+ knot jetstream headwinds by flying at lower altitudes. By not factoring the winds into the route is like using Mapquest to generate a route, say New York to Los Angeles, using the "shortest distance" option instead of "shortest time" (go ahead, try it :wink: ). So unless something has eluded me, this appears to be yet another flight planner ignoring winds aloft at the time it generates its route but then applies detailed winds aloft to its calculations after the route has been generated. Because there really isn't anything more tragic than wasting precious virtual fuel, is there? :Nerd: That's my beef. Carry on. :Peace:

I believe the intention was for you to return to the LEGS page after selecting runway 08 in the DEP/ARR page and THEN perform the described actions. I scratched my head a bit at this at first too.

I for one can say there is no part of this simulation that goes unappreciated. The fact that we have an entire complex aircraft simulation we can run on our desktops for under $100 is amazing. The FMC/CDU alone is worth at least double that. Thanks again for everything!

Hi Ryan,I can tell you that I did both 1 & 2 and I can duplicate this. However, it looks by the number of pages in your legs that didn't select the RNAV19 approach?Sorry, this really isn't that big a deal, I'm just curious about what causes it.Also, try just creating a KLAX to KORD route with just the BENKY1 arrival with either no selected approach or the RNAV09L approach (I think just about any RNAV appch works too at KORD since they all have an AT OR ABOVE restriction right before the RWXX leg). Set your cruise alt to say FL370, then manually enter the FL240 restriction at BDF in the LEGS and look at the subsequent waypoint altitudes. Pretty common route--surprised more haven't seen this unless everyone is setting ILS approach which does NOT cause an issue since it does not have an AT OR ABOVE restriction in the legs right before RWXX.Thanks!Edit: I posted this after you already caught the missing approach...thanks again for looking at this Ryan.

Input format s/b 00234. Entering 234 means FL234 which is above the altitude contraint at DRUZZ.