Tabs

Nick, What exactly are you asking for when you say "sponsor"? If it's money or free products, in general we tend not to do things like this for the sole reason that we don't want to be seen as picking favorites in the community. If we do it for one, we have to do it for all, etc. Whenever we have sponsored something in the past it's usually a whole organization rather than an individual person - e.g. a VATSIM ARTCC major fly-in where the want to raffle off a plane or something like that.

We do not use DTG's DLC system in Steam, it'll be sold on our website initially and eventually via partners like Aerosoft.

It ended up quite a bit closer to what A2A does in the end versus what RSR had originally said about it - we added a maintenance pop-up for dealing with the effects of engine damage (both MP overboost and high CHT), oil level, water level for the injection system and stuff like that. Treating the engines badly, ignoring icing and so on will negatively affect the airplane. We're all very much looking forward to A2A's Connie here too - that's going to be an amazing product for sure.

As I clicked this thread I was getting ready to lay the smack down. Totally thought this was going to be the latest ridiculous customer conspiracy theory haha. For what it's worth all those dates were the real ones on the airplane we surveyed.

C's wrong.

I just removed his quote...

Thank you Morton, we appreciate the support. Just as an aside, I bought your 737 last week and I'm quite impressed with it, congratulations!

This is seriously incorrect. Just because we can be skeptical of a claim at first doesn't mean there's something nefarious behind that skepticism. I can think of a ton of examples where we were convinced by community evidence to make a change or fix. The 777's FBW issues and terminal procedure VAS leak are two relatively recent examples where we responded with fixes after being presented with verified evidence on the topic. Very few people making comments about the DC-6 have actually piloted one or even flown on one as a passenger. When we have several people with thousands of hours on type telling us we have it right, we tend to believe them. Our company is also owned by someone who has a vast amount of experience with real life radial engine airplanes. Almost all of us on the PMDG team have actually flown in a radial engine airliner as a result - we're not just making stuff up here.

Also just from talking to one of our tech team pilots who flies the real thing, he said it's very dependent on whether the airplane actually has superchargers installed. A lot of the ones still flying today don't have them and thus they tend to stay below the flight levels. If you put the superchargers on high blower in the sim though you can easily go up into the low 20s with it. As Kyle says though, descent planning and how much time you'd actually have at cruise has to factor into whether you want to go up that high.

Really great shots there Rob, shows her off well!

We tried - to do it on the scale of a whole airplane like this is going to take official support from the XP graphics engine.

Do make sure you read the intro and tutorial - it actually can be fairly simple if you use the AFE to do most of the systems dirty work for you.

The core simulation stuff that we run "outside" the sim will port over fine, but X-Plane and FSX/P3D are pretty different in terms of how the aircraft interacts with the sim, so there will definitely be work involved to move it to another platform like that.

Source on that? Here's a Qantas flight from 2011 actually arriving and it looks just like what we've got modeled.

It's really not that we don't "support" DX10 - if you run a vanilla FSX install with DX10 Preview on, the airplanes should work fine, though Kyle is correct about the shortcomings he mentioned above. The real issue comes from the fact that there are all kinds of third party mods being done to the graphics system at this point. We can't possibly be responsible for supporting things that we have no control over - say a change is made to one of those mods and then suddenly we're inundated with support requests about it. That's not a workable situation for us. To give just one example - back when the 777 was released we had a bunch of tickets come in about the VC becoming partially transparent when in 0 visibility conditions. Vin spent a bunch of time trying to figure out what was wrong with the model and we eventually determined that the entire issue was being caused by a shader mod that the people reporting the issue were using. That's completely wasted time for our team if we have to spend it chasing down things that aren't even our issue. Regarding Nvidia Inspector - I think the old recommendations largely still hold. I have a very old computer actually at this point, I really need to upgrade before doing another guide.

I will not go into the specifics, but we evaluated this option very closely and decided it was not in our best interest to do at this time.

Pablo, 1. Go to the start menu and type "problem" into the search box - click "Choose how to report problems" when it appears as a search result. 2. Select the third option "Each time a problem occurs, ask me before checking for solutions" and press OK. 3. Now reproduce the crash and this time when the window pops up, there should be a small arrow at the bottom, press it and it will show you the detailed crash information. 4. Click in the detailed area and press Ctrl+C to copy the data. Paste it into a reply with Ctrl+V.

Ricardo, If things are running ok for you on 8.1 it's unlikely that 7 would actually perform better. I do suspect Windows 10 will become our new recommended OS shortly. I've been running it since release day without any issues with respect to our stuff or FSX. The standard recommendations hold though, the biggest one being to install FSX to it's own folder outside the Program Files (x86) folder to avoid issues with system protections / UAC interfering with the read/write permissions etc. That causes most of the problems with these later OSes.

Guys, This is an attempt to deal with some engine and atmospheric dynamics inconsistencies in the sim. FSX/P3D isn't a perfect simulation and we have to massage it into behaving the way we want it to. The bug was actually that it didn't go to full idle automatically below 30k until you held F1 - that was fixed in the 777, it should go to true idle there unless you have a calibration issue with your stick. The NGX I believe still has the issue where it doesn't automatically reduce without cycling your throttle or using F1 to pull it all the way down.

Avery, I'm running Win10 here and the OC is working fine. What exactly are you seeing happen with it?

Check out the section in the 777 manual starting at page 31.

Can you post a screenshot of what you're seeing?

To add to what Kyle and Dan said earlier - you would need to demonstrate that there is a leak over time (significant positive slope on a graph of VAS usage, significant negative slope on a graph of free VAS) while on a long distance (preferably over water) route at cruise for us to consider claims of a new or still existing leak. Several users have written tickets with such claims and I haven't been able to reproduce any of them under a controlled environment. Several users had the older version of the 777 somehow still and were seeing the exact issue we fixed in the last update. Here's an example of my test of one of those routes a customer wrote in about. I made this by logging the free VAS using FSUIPC and turning the data into a graph in Excel. Notice that during the cruise phase there are fluctuations but on the whole there is very little drop in free VAS. The line is essentially flat during cruise. This flight was over land for the most part so there is some variance to be expected as new areas load in. The massive drop at the end is the Norcal/Bay Area loading in - FlightBeam KSFO, Orbx Northern CA etc all take up a ton of VAS in that area. We keep telling people how huge some of these sceneries are for VAS and graphs like this drive it home. I've seen a drop of over 1GB as FSDT KLAX loads in too for instance. I landed with around 700MB free (FSUIPC was set to 15 minute log intervals here, so I didn't get the very end - there's a final high detail airport grounds loading that happens on short final that usually drops it significantly more from where this ended. It's also extremely important if you're testing stuff like loading an approach vs. not loading one to keep everything else 100% the same between flight tests. Don't fly with weather, don't use AI traffic or fly online - only load things that you can keep the same. Fly at the same time of day, stay in the cockpit without loading the external views, use the same weights, FMC performance numbers, etc. This is basic scientific method stuff here - you want to isolate the variable you're testing so that nothing else can confound the results.

Guys, If you're running Windows 7 or later, the correct settings for this are the HPET *on* in the BIOS and bcdedit /deletevalue useplatformclock run from an elevated command prompt (this is the Windows default). What this combination of settings does is allow the OS to use the CPU's invariant TSC (time stamp counter) if it has one (invariant TSC is is the more modern timing source that succeeded HPET). If the system doesn't have an invariant TSC it will automatically fall back on the HPET. You don't want to use a TSC that isn't invariant because it'll result in the different cores getting out of sync and the timing values fluctuating with clock speed when the CPU's power management functions kick in. HPET has high latency because it's external to the CPU (it resides on the southbridge chipset) which is why "disabling" it can help performance. If disabling it results in the use of an older TSC without invariance though, you're creating a bunch of potential problems far worse than some latency from calling out to the southbridge for timing information. Article by an MS Windows kernel engineer explaining exactly how this all works: http://performancebydesign.blogspot.pt/2012/03/high-resolution-clocks-and-timers-for.html People really need to stop assuming Microsoft doesn't know what they're doing with deep core stuff like this - the OS already accounts for picking between an invariant TSC and the HPET as long as you're using 7 or 8/8.1, which I hope everyone here is.

The CI scale isn't the same for all aircraft - the Big Boeings are usually in that 80-100 range for a normal flight, while the smaller short/med range aircraft like the 737 or A320 tend to remain around 10-40 or so. The 737 and A320 have different FMS manufacturers than the Big Boeings too. (Smiths and Thales respectively vs. Honeywell I believe)