tjahns

Well I must be as blind as a bat because it sure does, i.e. the upper checkbox to the right of the text box button containing the text "Import SimBrief' does indeed import the call sign. I guess my confusion was (from a UI perspective) that the box around "Import SimBrief", which looks like a section divider, implied to me that the checkboxes did not apply to that function. Oh well, now I know. Thank you for the clarification in any event! (Btw, I see the "Import Procs" checkbox works as advertised also.) -Tim

I know this is a bug reporting forum, but I thought submitting a feature request (which might drum up some support from fellow forum users) here might be better than submitting a blind email to Pilot2ATC... So, I am using SimBrief exclusively for flight planning (who doesn't these days? -- with apologies to PFX/LittleNavMap/etc fans) and Pilot2ATC has a nifty feature that allows direct importing of the flight plan (no export/import required!). Of course in SimBrief one sets the airline code and flight# when flying airliners and so I think it would save a step (which I always seem to be forgetting) to autoload the airline (e.g. DAL, UAL, SWA, etc.) and flight# into P2A when pressing the Import from SimBrief button. The same feature could be applied to GA, I suppose: Callsign/tail#, e.g. Cessna 167TJ, Skyhawk 167TJ, Barron 167TJ, etc. I further suppose there could be a checkbox to enable/disable this "auto import callsign from SimBrief" feature (just in case one doesn't want to use it), either in settings, or each time when importing from SimBrief (or both, with the former providing the default specified in Config and able to be over ridden at the time of import). Don't want to make the feature do complicated to implement, though... Anyway, this would save me a lot of heartache when I get P2A connected, listen to ATIS, file the flight plan, get my 737 powered on from cold & dark, and then finally request IFR clearance, only to realize I need to connect P2A over again after forgetting to change my callsign (all while draining fuel while the APU is running). Maybe not a big deal to some, but a HUGE deal to me! Thank you for listening! Tim Jahns / Tucson, AZ / MSFS / ProSim B738 (usually)

Resurrecting an old thread... I just installed (into P3Dv5.3) SXAD_KBHM_P3DV4_V1.035.exe (downloaded from PCAviator.com in late December 2021) and I am experiencing various elevation issues on the runway as well as a few floating buildings on the hillside to the north, as well as AI aircraft sunken into the tarmac near the terminals. Is there a P3Dv5 compatibility fix somewhere (anywhere)? Thanks!

This post pertains to CPU utilization with P3Dv5.3 on Windows 10 with a Core i9-12900K HT at 4K resolution with the following addons: PMDG NGXu, MegaScenery Earth photoreal scenery at cruise altitude/speed, Active Sky P3D (mostly clear skies this morning over New Mexico), Navigraph Charts (and 2112 Navadata), GoFlight Interface Tool, aviaServer (for accessing the overhead via a web browser), a PMDG CDU Device Server v1.9.1.1 (to access the CDU(s) on one or more iPads), and also various system utilities running in the background such as Corsair iCue, Gigabyte AORUS ENGINE, and Samsung Magician. So, I merely allowed P3Dv5.3 to configure it's default Job Scheduler settings, i.e. default CPU Affinity and threading settings (MainThread on Core 0, RenderThread on Core 2, and FrameWorkerThread on Core 4) on my Core i9-12900K in HT mode. The system is overclocked to 4.8 GHz on all eight (8) P-Cores and default 4.0 GHz clocking on all eight (8) E-Cores. I am not running Process Lasso nor did I adjust any of the process priorities/affinities in Windows Task Manager. Further, I used the default "High Performance" power plan in Windows, which apparently results in sleep states on the CPU so not all cores are running "full blast" under load. Lastly, the video card is an nVidia 3090, which never saw a GPU load above 40% (primarily because I am not using volumetric clouds nor god rays). Lastly, my sliders are mostly, but *not* entirely maxed out. LOD was only set at High, but I am using Enhanced Atmospherics (with volumetric clouds disabled in favor of HiFi's ASCA add-on to ASP3D), and scenery complexity is set to Extremely Dense (not that this matters much with photoreal scenery) other than OrbX's TrueEarth products, which are mostly optimized for decent performance on high-end rigs like mine. Now, according to HWinFO64, the only CPU core running "full blast" (on the ground or at cruise) is Core 0, on which P3D configured to run the MainThread. This is also by far the hottest core reaching a max temperature of 80 degrees C, but averaging around 70 degrees C. According to Windows Task Manager, Cores 2 and 4 (in the HT configuration) did not operate at 100%, but all the others (including the E-Cores) mostly maxed out as they processed the MSE photoreal scenery during cruise. According to HWinFO64, however, none of the cores (other than Core 0) reached an "Effective Clock" (which takes into account sleep states) over 4.0 GHz (no where near the 4.8 GHz "all core" o/c) and temps were typically about 10 to 15 degrees C (or more) cooler than Core 0. (Again, sleep states are at work here.) Anyway, the end result: my flight west out of KABQ (TropicalSim's version) with MSE's 4X New Mexico and Arizona (stored on a 4TB Samsung SATA SSD) was very smooth (averaging about 30 fps) at 4K at 30,000 ft in a PMDG 737 NGXu aircraft. Arriving in the Phoenix area for a landing at KPHX (FlightBeam's version) resulted in significant micro stutters as the scenery loaded from SSD disk, and then settled down at about 15 fps on approach. Perhaps lowering the slider settings, relegating the add-ons and system utilities to the E-Cores with Process Lasso (or at least off Core 0), may result in better performance. However, Windows 10 is fairly good at delegating threads to various cores on its own. Windows 11 is *supposed* to be better, particularly when configured for the "High Performance" power profile -- I'll report back if I jump to Windows 11 <gulp> -- but I think P3D's default Job Scheduler settings may be all that's necessary to obtain optimal performance (frame rate) on Windows 10. Not sure whether Process Lasso's "Performance Mode" (which does away with the CPU's sleep states) would make a difference. Maybe, maybe not. I'll report back if I give it a try -- this post mainly concerns default P3D/Win10 behavior. I would like to see those micro stutters cleared up at dense airport environments (like around Bravo's with numerous satellite airports in the area) such as Phoenix. Further, I'd like to see P3D take advantage of all the VRAM available to it (my 3090 has 24GB!) by pre-loading scenery in the direction of travel. (Maybe look at the loaded flight plan a la ASP3D's weather accuracy?) I never saw VAS go above 4.5 GB during my flight. As I recall, back in the 32-bit days P3D was coded to conserve VAS by aggressively dumping scenery out of VRAM memory. With video cards loaded with VRAM, why bother? Oh, and I rarely see my 3090's PCIe 4.0 bus load maxed out. Why not look ahead and cache scenery in RAM (I've got 64GB) and then transfer it into VRAM as needed -- I dunno, maybe LM is already doing this, but perhaps not aggressively enough? (Nobody likes micro stutters. Ha!)

Yup, the "Architecture Overview / Thread Affinity" section covers API calls (only in Windows 11?) for specifying thread priorities under a hybrid CPU architecture such as Alder Lake (and beyond, perhaps). I hope Lockheed-Martin (and other flight simulator software publishers) have gotten the word...

I am merely using "Core 0" as a reference to how P3D (and FSX before it) always ran on the 1st core of a CPU under earlier versions of Windows. Under Windows 10, executing threads are rotated among all available cores on a CPU. (You can verify this by examining Core temperatures while sitting on a ramp in P3D -- Windows Task Manager will show 100% on "Core 0", but in actuality the hottest core rotates among all available cores.) Hence my concern over P3D executing it's busiest single-thread activity (which is what I'm for simplicity sake's referring to as the "Core 0" thread -- perhaps I shouldn't refer to it that way) on E cores. You may wish to examine the rest of this "thread" with that in mind.

To enable the Ultimate Performance plan on a computer not running Windows 10 Professional for Workstations you've got to jump through some hoops (no big deal): Add or Remove Ultimate Performance Power Plan in Windows 10 | Tutorials (tenforums.com) It's mostly about transitioning the computer from sleep to wake states, so increasing performance of a computer that is already fully awake (e.g. while the user is gaming) is not something the plan is intended to do, as is stated in the article you cited, Emerson. Thanks for the tip, but mostly I'd say it's a dead end in terms of improving Windows 10 threading capabilities with Intel's new Alder Lake CPUs. Personally, I'm thinking that Lockheed-Martin needs to do something to enable Windows 11 (and/or Process Lasso) to distinguish its "Core 0" (i.e. single-threaded) code from its other code that does things like load scenery in parallel. That way a PC could be configured to ensure P3D's busiest "Core 0" thread runs on the "P" cores while all the other threads are free to run on both "P" and "E" cores. There's an interesting discussion on Windows 11's thread directing capabilities with the new Alder Lake CPUs at a popular hardware site I follow: Thread Director: Windows 11 Does It Best - Intel 12th Gen Core Alder Lake for Desktops: Top SKUs Only, Coming November 4th (anandtech.com) Given what I'm reading, Process Lasso would definitely be a wise investment (particularly with Windows 10). It'd be an even better investment if P3D's busiest "Core 0" thread could be "lassoed" to the "P" cores, but the rest of P3D's threads still able run on the E cores, in addition to the P cores.

Yeah, it turned out 5.0GHz (on all Performance "P" cores) was too much for either my cooling solution (a Corsair H150i liquid cooler with only 1,600 RBG fans -- that reached over 38 degrees Celsius cooling temperature -- at 100% CPU utilization) or perhaps the particular CPU I ended up with just doesn't cut it at 5.0 GHz. Anyway, dropping the max frequency down to 4.8 GHz (when more than 4 cores are active) lowered temps drastically (like 20 degrees C lower), without much loss in framerate. (The difference between 4.8 GHz and 5.0 GHz is only about 4%, which is largely insignificant anyway.) Btw, I have not yet tried Process Lasso. My feeling is that using it to limit P3Dv5 to just the "P" cores would slow the sim down down with my photoreal scenery and weather software. The sim apparently puts to good use all 16 cores (including the lower-clocked "E" cores) during flight. Perhaps limiting my numerous add-ons (not to mention monitoring software and Edge browser windows) to just the "E" cores would be a worthwhile endeavor (in case Windows 10-21H2 isn't doing it automatically). I still think it'd be nice if LM would add some code (if the Windows 10 SKD provides for it) to limit its "Core 0" activity (which actually seems to get rotated out among all available cores via Windows 10 threading logic) to just the "P" cores, which of course have better single-thread performance than the "E" cores. I'm not sure even Windows 11's thread director logic can pull this off automatically (via Win11's own threading logic) when dealing with P3D's appetite to use all available cores during flight...

Well, I re-enabled the Efficiency "E" cores on my Alder Lake and also performed a Windows 10 Feature Update to 21H2 (a.k.a. November 2021 update), which apparently contains threading improvement with Alder Lake in mind -- there's an Intel VGA driver that reportedly makes use of it). After these two mods, Intel's Extreme Tuning Utility now does not show the GHz drop it did when I was using Win 10-21H1 (with P3Dv5) with all 16 cores enabled. Also, Windows Task Manager did not report the CPU dropping below 4.0 GHz (rather displaying apparently the average of all 16 cores, i.e. ~4.5 GHz or greater). By the looks of the core temperatures, it appears P3Dv5 is keeping all Performance "P" cores fully engaged at 5.0 GHz (o/c'd) but with significant thermal throttling as temps neared 100C most of the time. It is also apparent that Windows 10's threading spreads around P3Dv5's busiest core among the cores on the CPU. Whether it is rotating them to the "E" cores is not something I can determine -- on occasion one of the E core's temps would spike, so perhaps that is indeed what's going on -- but my framerate did fluctuate on a consistent basis (which is not unusual). Perhaps Windows 11 is the cure to keeping P3D's busiest thread/core off an "E" core? P3D seems to like to use *all* cores, though, so not sure how Windows 11 "thread director" would determine the best way to run P3D. Perhaps LM needs to release a HF (or new point release) that can somehow tag its busiest thread(s) as not to be executed on an "E" core? Although this new Alder Lake hybrid "P/E" core business is good for streamers, it may not be optimal for flight simulators. However, theoretically if all my flightsim add-ons could be delegated to "E" cores, reserving the simulator itself to using "P" cores (and what ever left-over processing power remains of the "E" cores) then Alder Lake could be highly desirable. Personally, I'd rather have a homogenous CPU with 10 or 12 (or more) "P" cores and optimize it with Process Lasso. Btw, does anyone know whether Process Lasso is optimized yet for Windows 11 and/or this new Intel hybrid Alder Lake CPU architecture?

Optimizations in Win 11 for the new Alder Lake CPUs with their hybrid core architecture (Performance and Efficiency cores running at different clock speeds with different levels of performance) is a compelling reason. Can anyone comment on P3Dv5.2 and MSFS with these new CPUs? (I'm hesitant to take the "bleeding edge" plunge with my new hardware as I write this.)

Yeah, that thought crossed my mind (of course). Can anyone share their experience running P3D (and popular add-ons) under Windows 11? Maybe I'll be brave and take the plunge. Nothing to lose (but a whole lot of time) on the "bleeding edge"...

Um, there are only three default (built-in) power plans included in Windows 10: Power saver; Balanced; and High performance. Did you create your own power plan? (Perhaps you purchased your computer from a manufacturer that created a custom power plan and titled it "Ultimate Performance"?) If so, what would be the relevant settings (in said power plan) to adjust? Already in the default "High performance" plan the setting for "Minimum processor state" is at 100%...

So I scrounged up the time/gumption/$$$ to upgrade my PMDG 737NGXu / GoFlight rig with a new Z690 AORUS mobo, 64GB of DDR4-3200 CL 16 RAM, a new Core i9-12900K along with the necessary Corsair LGA 1700 Retrofit Kit (for my H150i cooler) and then fired up P3Dv5.2HF1. During my initial flights with high-density city/airport scenery (such as New York City/Airports X, Flight Beam's KDEN, FSDreamTeam's KDFW, LatinVFR's KMIA at highest settings -- don't try this without a card with more than 11GB of VRAM -- etc). At some point I noticed that both Windows 10 21H1 (via the Performance tab in Task Manager) and Intel Xtreme Tuning were reporting a "Max Core Frequency" of well under 5.0 GHz. Actually the speed reported was under 4.0 GHz, which is about default speed of the Efficiency "E" Cores at 3.9 GHz (not o/c'd). Note that the CPU was *not* being maxed out (according to Task Manager), but frame rate could have been a bit better (even though I've pretty much maxed out all the sliders except for Volumetric Clouds with EA, which drives my RTX 3090 to 100% GPU utilization according to GPU-Z, using instead HiFi's ASP3D with the latest ASCA for use with P3Dv5's EA). For laughs and giggles I disabled all eight (8) Efficiency "E" Cores via the motherboard's BIOS and re-ran my stress testing with dense scenery and mostly Ultra graphical settings and I noticed 100% CPU with clock speed staying at/near 5.0 GHz (with the eight Performance "P" Cores overclocked to that rate) with minor thermal throttling (according to Intel Xtreme Tuning) -- perhaps I used a tad too much thermal paste. Other than minor stutters loading scenery (I've got the entire U.S. in photoreal scenery from MegaSceneryEarth and storing them entirely on SSDs is not enough to eliminate stutters) I was getting framerates ranging from 20 to 40 FPS (in 4K resolution), depending on whether I was near an airport. So my questions are this: Was the low GHz speed (with the "E" cores enabled) I wrote about in the 1st paragraph above an anomaly in Windows 10 because it isn't fully aware the design of the 12th Gen CPU's "P" and "E" cores? Does P3D need some sort of patch/update to ensure it runs its busiest single-core activities on a "P" core at the CPU's full speed (i.e. avoiding the lesser performing, lower-clocked "E" cores)? If so (or even if not), will P3Dv5 run better on Windows 11, which is supposed to have some sort of threading optimizations designed for this new (ridiculous for gaming purposes IMHO) P/E core architecture? What about Windows 10 21H2? Or is it best to just disable the "E" cores and call it a day (at least for now). On a side note I'm wondering how MSFS2020 is performing with these new Intel CPU's and their being optimized under Windows 11. Win-tel to the rescue? That, or just give me a 12th Gen Intel CPU with 10 or 12 "P" cores! Sheesh. -Tim

In my observations, parallel runways can have the same SID. In this case, runway assignment would not be determined until after taxi instructions are coordinated, which could be well after AI traffic is already departing and landing. I suppose AI traffic could be adjusted at that point (i.e. runway selection), but perhaps in VOX Settings the preferred RWY would need to be entered prior to loading the sim? I don't recall that RWY selection is part of the flight plan file (maybe I'm wrong?), and I always spawn at a gate (not a runway). EDIT: I see now that Little NavMap creates some sort of runway waypoint on departure. Not sure though about SimBrief, which is my preferred flight planner.

Could have just been a glitch with FB's KMSP because I just now departed KPHX on KEENS2 with a different (parallel) RWY than assigned (I requested RWY 07L instead of the assigned RWY 07R) and proper altitude assignments were given by VOX. I guess I'll report any further difficulties via the contact form. Thank you.

From the VoxATC "Help" manual... Flight Planning and SIDs and STARs To be assigned a SID or STAR, your flight plan must have some waypoints that correspond with waypoints in the SIDs at your departure airport and/or STARs at your destination. The assigned procedure may vary depending upon the runway in use. Apparently "intermediary waypoints do matter" is supposed to be true, as long as (according to the Help manual) the flight plan contains "some waypoints that correspond with waypoints in the SIDs". On a related note, I had another frustrating experience last night departing out of FB's KMSP. Initially I was assigned RWY 12L for SCHEP 9 SID. For what I think is more realism (see another post on this topic re parallel runways earlier today), I pressed 0 (I had to read back taxi instructions first) and switched to RWY 12R (the longer, closer departure RWY, which has the same SID waypoints as RWY 12L), which has the same SID waypoints. Now, Clearance Delivery gave me SCHEP 9 (per the waypoints in my .PLN) but after takeoff I was given "Proceed Direct" ATC instructions to each of the SID waypoints, and (even more frustratingly) I was never cleared to climb above the initial altitude of 6,000. (So there I was cruising along at 250 kts for about 50 miles at high speed not to far above the terrain before I closed my simulator). It's possibly relevant to the problem that SCHEP 9 begins with a vector to the initial waypoints? I dunno, I really want to use VOX, but these glitches are really killing my sense immersion. That, and I'm constantly having to repeat myself (and this is after numerous voice recognition training sessions). Sometimes screaming obscenities at VOX will get it out of a stuck loop and continue along to the next step, particularly with taxi instruction readbacks. Perhaps it's just FB's scenery causing these issues, but that's what I like to fly, i.e. highly detailed airports (and I've got a "monster" rig that will handle it)! -Tim

In VoxATC I've noticed on several occasions (particularly at FlightBeam's KDEN, KPHX, and KMSP) that when there are parallel runways of different lengths, VOX (for me) has assigned on departure shorter runways for takeoff, while AI aircraft are landing on the longer runways. According to what I know about RW aviation (from direct observation and also various sources -- apologies for not providing links) but RW aircraft generally need all the runway length they can get on takeoff (in case of engine failure or other problems before V1). Further, aircraft generally do not need as much runway on landing (except maybe heavy's). Also note that in the RW I've read that, for optimal traffic flow on the ground, departure runways are the closer (usually longer, in my observation) runway to the terminals. Again, in my observation, VOX does just the opposite (i.e. assigning shorter runways on takeoff and longer runways on landing), which is unfortunately diminishing my sense of immersion (assuming I'm correct in my assertions above)... Specific examples (with FlightBeam's airports) include VOX assigning to me a taxi to RWY 7R (the shorter runway) while AI aircraft are landing on 7L. Yesterday at FlightBeam's KMSP I was taxied to 12L (instead of the longer 12R). In both situations the shorter runways were farther from the terminals than the longer runways. Maybe this is an AFCAD problem with FB's airport scenery? If so, perhaps VOX can overcome that merely by analyzing runway lengths on its own? I mean, VOX controls the AI traffic, so it shouldn't really matter? Perhaps someone who is more authoritative on takeoff/landing procedures (at airports like the ones I mentioned above) can verify my assertations about RWY length and proximity to the terminals? Thank you for listening! -Tim

This feature suggestion concerns how VOX assigns the airliner ATC Callsign in the VoxATC Settings applet. First, I exclusively fly P3Dv5 PDG airliners, which include the livery info (Southwest, Frontier, American Airliners, etc.) in their aircraft descriptions (and/or maybe somewhere in the a/c definition file). Also, when selecting an aircraft to fly (when loading it in on startup in the flight simulator), there is an entry field for a flight number. Now, given that almost always forget to run the VoxATC Settings applet before loading the sim (to enter the ATC callsign), so... It would be awesome for me (and likely others) if the VoxATC settings applet would include some sort of checkboxes (in addition to the ATC Callsign entry field) to optionally "Use flight number entered into the simulator" and/or "Use livery for the aircraft selected in the simulator". I suspect the relevant info is available at runtime as shown in the SDK, but I am not a flight simulator developer, so I do not know for certain. Thanks for listening! -Tim

I guess I should add (for completeness) that the .PLN file I loaded (for CHUWY1) included SID waypoints for departure to the north (not east), i.e. the waypoints CAAZZ, then YOKES, then LNGWD, and then CHUWY before continuing on to KMSP via KD75A, SSWAN, etc. As stated above, the flight plan I used was generated by SimBrief. If I interpret VOX's documentation correctly, intermediary waypoints do not matter, only the waypoint at the end of the SID (i.e. in this case, CHUWY)?

I'm not finding VOX's log file showing ATIS info (just whatever is in %appdata%\Internal Workings\VoxATC P3D 5i), but perhaps the steps to reproduce the problem will be of use to you: 1) Logon to SimBrief and create a flight plan for KDEN to KMSP as follows: KDEN CHUWY1 CHUWY..KD75A..SSWAN TORGY3 KMSP 2) Use SimBrief to export the flight plan to P3Dv5 format (PLN); 3) Start P3Dv5 and load the flight plan, placing yourself at Gate C24 (any gate will likely do the trick, except VOX's taxiway instructions to RWY 07 will be different). Not all current RW gates may not all be available with stock scenery. Again, I'm using FlightBeam's KDEN; 3) Set weather (manually via P3D, if necessary) with winds out of the east; 5) Start VOX, listen to ATIS indicating RWY 07/08 are active for landing and departures, run thru the instructions, and then upon receiving taxi instructions, notice that, rather than being assigned RWY 08 (which is called for with a CHUWY1 SID), RWY 07 is assigned "via charlie sierra hotel alpha...". As originally stated, at least with AIRAC 2010 (EDIT: same situation with AIRAC 2012 rev 1), CHUWY is not an available departure for RWY 07. You can verify this by checking VOX's Procedure Pronunciation Editor showing RWY 07 is not an available runway for CHUWY1. If I can be of further assistance, please let me know! -Tim Btw, I do notice that at least I can press 0 and request a different RWY than the one assigned by VOX. That'll work for me in the meantime.

Thank you for the read, vadriver. 🙂 Looks like RWY 08 (not 07) is preferred for departures to the east while 25 to the west, given high winds. Light winds the four other RWYs are likely preferred (as I observed on FlightAware in the RW flight in my original post). I suspect KDEN may be a bit of a logic conundrum to work out for VOX. I still think the RWY closest to the terminal would be a better choice than all the logic required to handle ops at KDEN, which would require special programming for each individual airport, I would think. Btw, I ran MakeRwys 5.02 on FlightBeam's KDEN and both 07 and 08 appeared as available RWYs. Maybe I'll get around to checking the AFCAD before long. This is starting to feel like a detective/research project. Fun! Btw2, I live in Arizona and KPHX has a similar situation to KDEN. American Airlines' terminals are on the north side of the airport (closer to RWY 08/26) while Southwest's are closer to parallel RWYs 25L/07R and 25R/07L. Although I've occasionally witnessed A/C taxing across the taxiways (bridges, actually) that connect the north side of the airport to the south side, I suspect AAL lands and departs mostly from 08/26, while SWA uses the southside parallel runways. And speaking of parallel runways, here's a discussion about when (when there are parallel runways of different lengths) longer runways are used for departure and shorter runways are used for landing: https://www.airliners.net/forum/viewtopic.php?t=750531. VOX apparently does the opposite, at least it did at KPHX in the SWA livery I was flying last week. Maybe an AFCAD thing? Or maybe it just depends on whatever the situation (logic) dictates?

Thanks to all who are participating in this thread! So I checked LNV and I do not see any red X's for any of the RWY's at KDEN, or at least not with FlightBeam's KDEN. I have used LNV for flight planning before, but what I've been doing lately is tracking my PMDG NGXu a/c (I like to fly Southwest variants) in FlightAwaware in real time, then pick a flight where I own add-on scenery (at least on one end of the leg), and then set weather/time, etc. to match the flight, and then use SimBrief for fuel, payload, etc. (FlightAware goes so far as to give the planned route and altitude, which I confirm with the current AIRAC in SimBrief.) Personally, I find this to be very immersive. Interestingly, in the flight I mentioned in the OP, FlightAware graphically depicted a departure route (with dashed blue lines) that would have been RWY 08 (with the CHUWY SID). In the RW, presumably because the winds were light, the RW 737 in question actually departed RWY 34R (as shown by the ADS-B data collected at the time of departure) and then continued on with the CHUWY.SID. As a reminder, note that Navigraph's AIRAC 2010 loaded into PMDG's NGXu FMC/CDU displayed that RWY 08 was a valid RWY for the CHEWY SID, but not RWY 07, so it seems FlightAware knew enough not to depict a planned departure of RWY 07. I'm not sure how FlightAware goes about calculating their dashed blue lines for departures and arrivals, but they must have put some thought into the logic. Seems they do something similar with arrivals, i.e. arrival runways on planned routes seem to favor the side of the airport closest to the terminal where the a/c operator has gates. As far as me digging into the AFCAD's and analyzing a makerunways printout, I may leave that for another day. It certainly seems interesting, and perhaps well worth the effort to me considering that I am only flying (at least for the time being) select FlightBeam airports serviced by SWA. I continue to stand by, however, my original suggestion that departure runways (when they are far apart and of more-or-less equal length, such as RWY 08/26 & 07/25 at KDEN) be assigned by VOX to the threshold that is closest to the departure gate given favorable winds. On a related note, it'd be interesting to analyze RW usage of these two runways from "spotter" data. It would seem logical to me that when winds are out of the east, RWY 08 would be used for the northern terminals (where Southwest operates a hub), whereas RWY 07 might be used for departures for the southern terminal(s), if for nothing else, to cut down on taxi traffic congestion. Perhaps someone who has actually worked ATC at KDEN could chime in? 🙂

In answer to your question about which SID I was assigned... I wasn't assigned a SID at all. VoxATC merely gave me clearance direct to CHUWY. I presume this was become CHUWY1 isn't available for my assigned RWY 07 (when it is available for RWY 08). In the RW I suspect RWY 08 is used for departures (given favorable winds) because the threshold is *much* closer to the terminals (or at least it is with Terminal C and D, where SWA operates and the gate where I spawned) than the threshold of RWY 07. Also (given current winds), RWY 07 would be used for arrivals because the end of that RWY is closer to the terminals. The converse would be true if the current winds dictate it because the *threshold* of RWY 25 is closer to the terminals whereas the *end* of RWY 26 is closer to the terminals. EDIT: after further investigation, I can confirm that (given favorable winds) ATIS for FlightBeam's KDEN will assign both landing and departing notification for both RWY 08 and 07. For your quick reference, here's a link to the diagram of KDEN: https://flightaware.com/resources/airport/DEN/APD/AIRPORT+DIAGRAM/pdf In any event, thank you for your consideration of my suggestion! In answer to your question re whether 08 was a valid runway given the AFCAD and wind, I beleive ATIS indicated 08 as a landing and departing RWY (but I'm not 100% sure of that), I'll pay more attention next time. Any problems with the AFCAD would be on the part of FlightBeam, of course. To be honest with you, although I have been simming for a very long time, much of this is SID/AFCAD stuff is new to me.

As I write this I am using P3D v5.1 and VoxATC v7.43. Earlier today I was departing KDEN (I'm using FlightBeam's KDEN) in a PMDG 737NGu with Southwest Airlines colors. (Note that SWA operates primarily out of Terminal C, which is is *much* closer to the threshold of RWY 08 than that of RWY 07.) Anyway, the winds were light out of 110 and I was assigned RWY 07 by VoxATC. This was unfortunate because my flight plan called for an initial waypoint of CHUWY (which would normally have been reached by flying the CHEWY1 SID). Unfortunately, CHEWY1 is not available for RWY 07 (at least not with AIRAC 2010), but CHEWY *is* available with RWY 08, the threshold of which is, as I mentioned above, *MUCH* closer to Terminal C than the threshold of RWY 07 (something like 3 miles closer). Here's my suggestion... At larger airports like KDEN (with multiple large terminals and lots of runways, many of which are parallel) and also smaller commercial airports (like KMSP), it would be very nice if VoxATC would take into account (at least on departure) the gate at which I am parked, and if parallel runways are available, calculate the distance to the nearest one (given its threshold location) and assign a taxi route to the *closest* runway, not the one with the lowest number (as I suspect is the case), or whatever runway matches up with the wind *precisely* best (which could be a case of just a few degrees in the case of parallel runways). The runway assignment should (ideally) also take into account the availability of a SID (matching the initial waypoint in the active flight plan, of course) in the currently installed AIRAC. Doing that *alone* might help with RWY assignment when otherwise in doubt. Not sure if this feature already exists in VoxATC, but perhaps it would be nice if I am given a taxi assignment to a particular runway, that I could request (via pressing 0, or whatever) a *different* RWY? (Probably not realistic in the RW, but it could be useful. Just a thought...) Please forgive me if this feature request has already been requested by another user. I was just a little frustrated with this flight and thought I'd take the time to write up a product improvement request. Btw, I really like the VoxATC 7.43. It's much more stable than the last time I used it a couple years ago!

Thank you much, Michael, I appreciate the feedback. I tried lowering the sliders, LOD, mesh complexity, etc. and I'm still encountering difficulty with getting Prepar3Dv2.4 to load successfully, particularly in full-screen mode. Wish I could hit 4.7GHz with my Haswell-E CPU. Water cooling beckons.... Also, received my very first official OOM from Prepar3D on a planned 737-700 flight from Buffalo, NY (USA) to Green Bay, Wisconsin in the terrible cold-snap today (18-Nov-2014) with current weather downloaded by PILOT's FS Global Weather. The OOM occurred while flying by Lansing, Michigan while I was in external view waiting for the stock Lansing airport scenery to load. At that time all my sliders were set all the way to the right with a 2K texture setting. REX4 was configured with compression, i.e. not the 32-bit textures, btw. For those of you who have not followed this thread recently, my system is based on a hex-core Haswell-E CPU (15MB of L3 Cache RAM) with 16GB of system RAM and 4GB of video RAM (more details are contained in my post from earlier today). Obviously this rig has more than enough resources to handle whatever I throw at it (short of real-world weather modeling, real-time ray tracing, data mining, or terraforming - ha!) and I was indeed getting at least 15 fps in most situations (perfectly flyable in Prepar3Dv2). This, however, was the first time I had flown in snowy conditions.... It is a sad state of affairs that LM is still releasing a simulator based on a 32-bit engine, which limits addressable RAM to 2GB. Computer hardware is now capable of driving LOD "Max" and terrain mesh "Ultra/Max", but the 32-bit engine is apparently not up to the task. Hmmmm.... perhaps my NVidia GTX 970 needs to be replaced with the 8GB model when it arrives next month... Does anyone know of a utility I can use to monitor memory utilization of a 970/980? Here's hoping this 32-bit limitation gets "addressed" in Prepar3Dv3... or v4... or v5... (or before I'm too old and feeble to build/enjoy fs rigs)! -=Tim=-