• Content count

  • Joined

  • Last visited

  • Days Won


Tabs last won the day on February 13

Tabs had the most liked content!

Community Reputation

2,710 Excellent

About Tabs

  • Rank
    PMDG Support
  • Birthday 10/06/1981

Flight Sim Profile

  • Commercial Member
  • Online Flight Organization Membership
  • Virtual Airlines

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Interests
    Music/Guitar, Computers, Aviation
  1. I've seen mine spike to over 80C at stock speed in FSX - I have an NZXT Kraken x62 closed loop water cooler too, one of the best ones out there. It's definitely a really hot chip. Thinking about delidding it.
  2. There's also a section on actual use of the radar in the sim in the Intro manual near the end.
  3. Yep agreed - the mass market AV programs are arguably malware themselves at this point with how much negative effect they have on system performance, false positives and overzealous heuristics-scanning, etc. Use common sense online and in your email (don't open obviously illegitimate crap) and use the default Windows Defender that comes with Win10. Make exclusions for your sim folders, etc. I do not get malware/viruses with this method and I've been doing it for a long time.
  4. We did record every single switch in the real cockpit with professional microphones, multiple times in fact, and the airplane randomly picks one each time to create subtle variation. Not sure what this product is purporting to do that we didn't do already in the base soundset.
  5. The main thing is stopping virtual address space (VAS) related out of memory errors and crashes in the sim. The current 4GB VAS limit in FSX and P3D is a direct consequence of the maximum number size that can be represented in a 32-bit application. (slightly simplified explanation but that's the basic idea) The core FSX/ESP engine that we've been using for 10+ years now was never designed for the level of detail and complexity that current addons are throwing at the sim - all of that extra detail, extra features, and so on comes with an increase in the amount of VAS that must be allocated by the application and Windows. It's bad enough now that you can easily OOM the sim right after loading it, on the ground, without even starting a flight if you have a particular combination of addons installed. (for instance, a complex addon aircraft, photoscenery terrain, a high detail addon airport, a weather addon, and an AI traffic addon) 64-bit applications raise the VAS limit to 256TB (that's *tera*bytes, not gigabytes - 1TB is 1000GB, so this is a huge increase over the 32-bit limit), so there should no longer be an issue with having say 32GB of physical RAM on a PC but OOMing at 4GB of VAS usage long before coming anywhere close to the system's physical limit. To clear up one major misconception I've seen getting thrown around: What 64-bit does *not* mean is that developers no longer have to worry about memory in any way. Physical memory - meaning the actual amount of memory plugged into your motherboard and integrated onto the GPU's board (VRAM) are still limiting factors - 64-bit doesn't magically make the sim able to exceed those physical limits. What it does mean though is that we have room to grow and scale with hardware. If in 5 years, computers have 32GB GPUs and 128GB of system memory or something like that, the sim will be able to take advantage of it and won't crash due to exceeding virtual allocation limits. In an indirect sense I'm sure this will lead to better graphics since higher resolution textures, models, draw/LoD distances and so on will be usable. I would not expect any immediate benefit were a 64-bit simulator to release this year (which is all still speculation, there's been no official announcment of anything) outside of the elimination of VAS OOMs as discussed above though.
  6. It's definitely the Nvidia driver - I have a GTX 1070 and if I roll back to 376.33 or earlier I do not see the constant loss of VAS in flight. We spent a couple days thinking the 747 was somehow responsible back when this started due to the complaints at support - it's reproducible with default aircraft even though and does not occur in FSX or FSX:SE with the newer drivers, only P3D. Problem now is that rolling back to those drivers isn't possible for people with newer cards like the 1080 Ti. Also not feasible for those of us who play other games that require at least the "game-ready" version for that specific new game.
  7. DDU has an option (believe it's enabled by default when you run it) that stops Windows from doing this btw.
  8. The AP doesn't have "calibration" - if your hardware spikes past a certain amount of deflection signal, it's going to disconnect, that's it.
  9. Jack, The only way I could see that happening is if the ILS frequency for the runway as it exists in the sim doesn't match what's in the FMC's navdata (they're two separate things). Regarding VAS - the plane's contribution to it should already be fully present by the time you take off. That 20% increase over the course of the flight has to be due to the sim and scenery. The Bay Area uses a lot more in general than Denver, I'll bet most of it is that.
  10. The autopilot roll rate has nothing to do with whether the flight model is "external" or not. We have full control over our roll rate commands. (as an aside, A2A is not doing the same thing Majestic does with respect to this - they are still using the FSX/P3D flight dynamics engine with modifications on top of it, just as we do. Majestic uses the open-source JSBSim flight dynamics library to create what are essentially slew commands to the sim, which (as we've explained numerous times) we feel creates a number of unacceptable compromises in other areas of the simulation such as the lack of reaction to weather and turbulence, issues with the view and sound systems, etc that are not a road we wish to go down with our products. There is more than one way to skin a cat and we've been at the "doing things outside of FS" game longer than almost anyone in this market)
  11. LNAV has a whole series of rules that determine the bank limit (similar to what HDG SEL does in AUTO mode) - in most flight regimes it will bank up to 25-30 degrees as required by the course change. This is realistic - these systems are not perfect in real life either, and there's a whole host of "tricks" real pilots use to make certain things the autopilot system does more comfortable for the passengers. This is one of them, as Dan alluded to above. On a large course change direct-to, use HDG SEL to get the plane more or less heading in the right direction using whatever bank angle limit you want. At that point you can then execute the direct to in the FMC and then put it back in LNAV. Another similar real-life trick at top-of-descent - the system can be quite abrupt in chopping the thrust to idle and starting down at the T/D marker, so what many real pilots do is start down slightly early in V/S mode using small gradual increases in the descent rate with the wheel on the MCP until intercepting the VNAV path and reengaging it. This way the passengers barely notice the onset of the descent. Always worth remembering that you are the pilot, not the computer systems - if you want it to do something differently, take over with a different mode on the MCP and make it happen.
  12. Updated: Virgin Atlantic G-VROM (400) - fixed wrong engine type (PW instead of GE) on thumbnail image Centurion Cargo N901AR (400ERF) - was incorrectly painted as an ERF, aircraft is now a standard 400F Please note that you'll have to remove the ERF version from the Livery Manager module, then download the 400F version to correct this, it won't update automatically because the aircraft variant changed. Also: All paintkits have been updated at our website to include templates for the thumbnails and for the spines of the manuals that appear in the cabinet behind the FO's seat.
  13. I just love that we have a fellow Lions fan here! I'm from Michigan originally and have remained a die-hard fan through all the years. Please sign your real name to your posts though, forum rule, thanks.
  14. FSX:SE

    Far more likely that this is an error in the coding for the approach in the navdata than it is a rendering problem - there's only so much the code can do when it's asked to draw impossible or nonsensical things.
  15. Those two dlls are core Windows system files and crashes in them usually indicate deeper system-level instability. I believe what Robert is talking about here is the MSVCR120.dll crash associated with using the 2D popups.