ahuimanu

Disastrous news. Aivlasoft is peerless with no equivalent.

Sorry to chime in on a very old thread, but you'll also get this if you have a disco that is inhibiting a complete path to the airport/runway entered in the FMC.

Thanks, I'll try that on my next flight.

Sorry to reply to a thread this old, but I am unable to put "ICAO" into the step size field.

Flavio, This document says the order does matter: http://www.prepar3d.com/Prepar3D_Download_and_Install_Instructions_v3.pdf When updating, install client first, then content and scenery.

Same issue here. Was not asked to re-enter licence/key information (I did uninstall the 2.5 version). I can't click on many of the VC buttons, etc. EDIT: A reboot (after the SimConnect installs) seemed to improve things (most clickspots work). Windows 10.

Robert, Thank you for the reply. It sounds like a community-based benchmarking project is warranted. If we simmers (which includes all of us) had a client to run in the background, and then loaded up scenarios with specific aircract (777X for instance) and specific combinations of OS, 3rd party, etc. then a database of common values would allow an average to be known. Althought this requires "guinea pigs" many (including myself) tend to buy things right away (airports, quality aircraft, etc.). I know that the wider PC gaming community does this sort of benchmarking. I think SimConnect or FSUIPC would both allow for some of this to be collected. It is possible to use other tools as well. My point is: I don't believe a standard will ever emerge, but for those of us who wish to simulate airliner-type operations (for instance, aircraft: 777, dep: KJFK, arr: EGLL), we could 'see' what combination of add-ons/OS/system produce in terms of VAS usage. With that, with enough participants, a picture would emerge and the outlier add-ons would be exposed. Now, some may want the 2.1 GB scenery and fly in a low-demand airplane and enjoy that. That is great and the platform allows that. However, knowing the load of settings in the sim, the load of addons, and the load of other co-proeses (the DLLs and EXEs that can work with FSX.EXE and/or P3D.EXE) could give a picture. I know it is easy to suggest such a project and much harder to do. But the customer support component that you have described, coupled with what other 3rd party developers must also experience, would suggest that a community of folks at FSDeveloper and those concerned among the developer community might facilitate this? You describe taking good time from your own development cycle to conduct your own independent test, so the results were/are of interest. I agree that I personally can start a spreadsheet, and do my own test. But, like many, I would want to fly with that time. However, if a client were capturing this in the background (recognizing that we'd have to control for the client's effects) and that was being collected by many simmers, we'd perhaps have an emergent database that would start to tell a true picture. Thus, when PMDG uses 50% of its time for optimizaiton, that time can pay off where observations across many users will prove that some add-ons are crafted with care to provide a positive/reasonable experience. In other cases, the resource hog could be a good add-on, but the data would show that it is good for flying around in an ultralight, but not with anything approaching a high-fidelity add-on aircraft. What you are not coming out and saying directly (out of decorum) is that there is a wide variety of actors in the 3rd party marketplace and there is little control (aside from reviews) to determine what is being sold. As a result, we have all seen charlatans and "snake oil" salespeople in the market. We do a better job at describing optimal settings than we do about vetting the impacts of the 3rd party market. This ins't about the subjective value of a product (one' man's treasure, another's trash), but about the serious (and objective) impact of 32-bit software and the limited space to have it all. I appreciate the role PMDG has played for nealry 2 decades, and I would love to see the results of your test, but I suspect you can't share them. However, if an ecosystem/tool as I described existed, we'd all be working towards a common goal: information such that we are better informed as we attempt to adjust the simulator to suit our needs. Kind regards.

Hi, I have a question for PMDG. One use case for MSFS/LHMFS (FSX/P3D) is brought to the foreground with PMDG's flagship products (i.e. NGX, 777, 747, etc) and it is alluded to in the original post: heavy iron at major airports. The SDK tools have greatly enhanced this software series in that advanced aircraft and scenery can mix. The question is of balance and is alluded to in the post. Presently,we get into tweaks, turning scenery off and all manner of other things related to lowering VAS. Here is the Q: If most flights in PMDG products involve a departure airport, some amount of distance covered in cruise, and an arrival airport, then what is a reasonable VAS budget for DEP, TRANSIT, ARR? Further, what is left over for weather/sky texture packages and general packages? AI? We've lived in this ecosystem long enough where I suspect some guidelines could emerge. With respect to the VAS issue, we obviously want improved airports to fly in and out of and the high-fidelity aircraft like PMDG's. However, most of us have learned that compromise is in order if we'd actually like to complete a flight. If some rule-of-thumb numbers were possible, it would be a great discussion. I would suspect, within reason, that more budget should go to the aircraft, another portion to ARR/DEP, and then what is left over can be adjusted. Guidelines would let the consumer know what they are getting into with a purchase. I think of the way food is sold... If I buy something packaged at the market, the item give some indication of nutrition information, calories, etc. Of course, download size is some indication, but it would be nice if some means of VAS usage was reported. I suspect developers that hit a sweep spot in VAS usage may use that as a point of strategy in their position in the marketplace. Vendors like PMDG share the same platform ecosystem as other developers and I would think that there is a symbiotic relationship between the aircraft and add-on airports. Put another way, when I am in possession of a great aircraft, my appetite (read: wallet drainage) is increased when there are new destinations. It would seem we have enough evidence in the last decade to better understand these issues. Clearly PMDG can't control others, but you are all operating on the same grounds and this is a tiny community. As we wait for the fabled 64-bit it is obvious we need strategies for this. Thoughts?

Doh! I used to search for his work under "FSX AFCAD," it seems he stopped using that nomenclature. Thanks.

Haven't seen a new Ray Smith AFCAD in 2 years, where's Ray?

I think STARS and SIDS are there to maintain traffic flow given: 1) the direction from which you are arriving/departing, and the active runways/patterns at the arrival airport. The seem to exist to deconflict arrivals, departures and enroute traffic. Often, the transitions in a STAR and points along an airway (upper or lower level) that would allow a transition from the airway "highway" and serve as an "offramp" (or "onramp" for a SID) to leave or join the approach/departure traffic. A good program (although not perfect) to get a sense of all of this is PFPX (aerosoft). It seems to use some of the same logic that you can see if you study flightaware - connect in a transition (from/STAR, to/SID) your airport. Additionally, each airport has its preferred runway policies/preferences and the SIDS/STARS are designed for these. I grew up near PHNL and 8L is for laning and 8R is for takeoffs for the heavier jets, so policies like this affect SID/STAR selection. In any case, regardless of what you (or the dispatcher) request, ATC is going to tell you which SID and STAR to use. As to the "which runway" question: ilu33366swho's answer is good. I would only add that local conditions might favor a runway even it it isn't entirely aligned with the predominant wind. If the wind speed isn't that high, cross-winds (and even tailwinds) might be possible, depending on local conditions. Take Lukla (VNLK) or Saint Barthélemy Airport (TFFJ), for instance (which don't have SIDS/STARs or the like), terrain and local conditions dictate runway selection no matter what the wind is doing.

I have splashed out for most versions of My Traffic X and, despite UT2 being an abandoned product, I always return to UT2. I like what the My Traffic X author has tried to do over the years and I support him by trying out his latest (the current promotional price is hard to beat). However, I've not yet installed this latest version, but Ray's feedback is calibrating my expectations. My Traffic X nearly always falls short of UT2. However, since My Traffic X is supporting both FSX;SE (which is obviously what I'd move to on my next rebuild or build, AND supports P3D (which I've concluded is too pricey in the end), it would seem like Burkhard (sp?) is worth my continued support. I'll install it this weekend, but likely uninstall it after invariably encountering what Ray mentions above. I've gone through that cycle so many times. Conversely, the nit-picking of getting custom schedules into UT2 can be cumbersome, but the tools are more professional. Also, having UT2 follow flight plans is always preferable. Thanks for this report Ray.

The only thing that allowed me to return to sanity was DX10 (and Steve's DX10 Fixer). Everything else was a no-go. I've been happy in long haul ever since.

Amendment: I'll probably have to turn sceneries on and off still. WIII (BDO payware) to OTHH (Taxi2Gate payware) and I have 600MB left as I began descent into OTHH. I suspect FlyTampa Dubai sucked the life out of VAS by flying near it. So, I save, I select my LH Cargo B777F, reload (still get the visual model anomalies I have described in another post), reload the plane, and coast on down with 2Gig of VAS available! I end up with 1.3 Gig of VAS available as I touch down at OTHH. So, "FIX" is still DX10 and Steve's DX10 fixer, but most of the advice from PMDG in the pages I refer to in my signature still apply. So, DX10 Fixer is not quite a silver bullet, but I get WAY more VAS overhead/legroom than with DX9.

Since I am the OP, I thought I'd check in and share my solution: Steve's DX10 fixer. Plain, simple, definitively. Nothing but confidence now. AND, I am able to leave all sceneries checked without issue. Hope that helps. Thanks for all the input and discussion, I appreciate it. Happy flying!