[28SEP15] Prepar3D v3 Approach Clearance!

[ahuimanu 50]

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?

[rsrandazzo 6,353]

Jeff-

 

Your question is a salient one, because there are currently no standards or expectations on the part of developers- a point that is causing great pain to the community.

 

Customer thirst for greater and greater detail is causing developers with competing needs to consume resources that eventually run out, and produce OOMs. Some developers are obsessively concerned about this trend, others are blissfully unaware of the impact their products have on the usefulness of the simulator.

 

I have stated a number of times that we work VERY hard to conserve resources- a practice we got into back when we were developing the PMDG 747-400 for FS9 eleven years ago. We found that we could easily consume so many resources that the sim would run slowly. This caused us to develop a number of techniques to constrain resource use- and as of right now, about 50% of the time spent by our modeling team on models and textures is spent optimizing in order to reduce memory use and draw calls.

 

A few months ago we began a project in house that was designed to evaluate how to respond to customer complaints that "The 777 always OOMs." After all, the 777 is a highly optimized product that consumes a largely static amount of memory. Our research was designed to give us a better sight-picture on the overall VAS use of the community so that we could better answer customer queries with information rather than "we don't think it is us."

 

The results of the research were rather surprising. I illuminated them here a few months back- with a very carefully worded primer to teach users how best to avoid OOM issues when using our products. The fact is that the 777 DOES use more memory than any previous PMDG product- but it is only consuming about 10% more than the NGX, and is consuming about the same amount as the 400X from ten years ago. Taken by itself, this product will not cause an OOM condition for a simmer.

 

Add in AI traffic running at 50-100%, custom sky and cloud textures, massive scenery areas with huge texture loads, complex airport scenery, advanced weather engines and all the other goodies- and combine it with the flawed memory management of FSX/ESP and you have a recipe for an OOM.

 

Lockheed Martin has just given us a reprieve from this problem by fixing the long standing issue within the ESP code base that became Prepar3D. But it is important to note that even with this fix, you can still OOM P3D v3 if you cram everything into the simulator all at once and expect to be able to run all the sliders to full.

 

My concern here as a developer is that there are many designers out there who are cramming scenery areas full of really beautiful scenery with little or no regard for how much memory they are consuming. It seems to be that some designers feel that everyone else should worry about constraining their resource use, but they won't need to. I am very carefully not identifying specific designers, specific products or specific features that we have seen included in scenery packages that add little in the way of quality while consuming massive amounts of resrouces.

 

You can similar research on your own by building a table in excel to record how much memory is used when you add a new scenery package to the sim as compared ot how much memory was used by the default scenery. We buy just about everything that gets produced- and many designers have done an impressive job keeping their footprint to a minimum- but some of them are breathtakingly blunt in their footprint. (A scenery package that takes up 2.1GB for a single airport is a bit over the top...)

 

Again though- Lockheed Martin has given us a reprieve. Human nature being what it is- I fear that some developers will just see this as an opportunity to jam more detail into already bloated sceneries. I personally think that x64 will raise the ceiling further, and give us greater resource availability- but as a community of developers we still need to find a way to work toward "lowest possible footprint" design theory.

 

At PMDG we certainly are. We deliberately leave certain features out of our products because we don't want the resource overhead...

 

I hope that gives you some kind of answer to your question!

[AndyUK 26]

.....and combine it with the flawed memory management of FSX/ESP and you have a recipe for an OOM.

 

Lockheed Martin has just given us a reprieve from this problem by fixing the long standing issue within the ESP code base that became Prepar3D.....

As someone who feels that they don't qualify for a P3D licence I'd be interested to know if the LM fix to the memory management is similar to that apparently implemented in FSX Steam Edition in a patch since initial release?  Or to put it another way would changing to FSX SE from FSX give a similar benefit in terms of reducing the likelyhood of OOMs as would going to P3D V3?

 

Andy L

[scandinavian13 5,192]

As someone who feels that they don't qualify for a P3D licence I'd be interested to know if the LM fix to the memory management is similar to that apparently implemented in FSX Steam Edition in a patch since initial release?  Or to put it another way would changing to FSX SE from FSX give a similar benefit in terms of reducing the likelyhood of OOMs as would going to P3D V3?

 

Andy L

 

Andy,

 

FSX:SE has gotten a few optimizations through its release and up to now. It will likely do a little better for you than the original boxed version of FSX, but not to the level that LM has just realized with P3D.

 

Full names are also required in the forum - first and last.

[rsrandazzo 6,353]

Andy-

 

Dovetail has not fixed the memory management problems that they inherited with FSX.

 

They have optimized a few things, but FSX:SE still retains everything in memory just as FSX did- and you will run out of space just as rapidly.

 

What Lockheed Martin has done is something else entirely.

 

I had hoped Dovetail would be able to accomplish the same with FSX:SE- but it is a slightly unfair expectation.  From a business standpoint they would be better served by shifting focus to their new FS-Next platform. 

[ahuimanu 50]

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.

[rsrandazzo 6,353]

Jeff,

 

I envision that we will eventually publish a set of recommendations based upon a controlled study of VAS use.

 

The goal of the guidance will be more-or-less what you suggest.  I envision a matrix that will tell you what you can anticipate from a range of widely used addons.

 

I am awaiting input from our legal counsel on how to go about this because what we publish and say could have a negative impact on some of our fellow developers- and we really don't want that. 

 

Ultimately- we would love for a developer to see that they are a standard deviation or two above the norm in terms of VAS use and take it upon themselves to correct the issue- but the circumstances aren't that simple either.  A scenery designer might legitimately say their offerings are not really targeted to airliner operations- and that is an important distinction to make- and it cannot be made by simply publishing a number.

 

So... as you can see...  Touchy and political.  We have to be very careful not to put information into the marketplace that might be perceived as an effort to bully the market to play according to our rules.  After all- in the marketplace all of us are equal and we have slightly different targets for our products...

 

In the mean time, I hope that the platform developers will solve the problem for us and obviate the effort altogether. 

[AndyUK 26]

......Full names are also required in the forum - first and last.

 

Doh!  I failed to check before I posted, must be going senile - sorry!

 

Dovetail has not fixed the memory management problems that they inherited with FSX.

 

They have optimized a few things, but FSX:SE still retains everything in memory just as FSX did- and you will run out of space just as rapidly.

 

Thanks Robert.  I could have sworn I'd seen figures quoted by users that seemed to show that it was unloading scenery that had been 'left behind' during a flight thereby saving memory but I can't find that source now.  I'll give it a try though because as Kyle said they have made some improvements and since I bought a copy for next to nothing when it came out but never got round to installing it I've got nothing to lose.

 

Andy Lawton

[hesynergy 67]

Upon finding the first quote from RSR, I was dismayed to read:

 

"IMPORTANT INSTALLATION CONSIDERATIONS: If you have your PMDG product already installed to P3D v2, and then you install P3D v3 and wish to use your PMDG product in v3, you will need to UNINSTALL the PMDG product before you will be allowed to install it to v3."

 

I was upset by the edict that flying the NGX AND T7 was an "either /Or" situation.

 

I have all my add-ones working well in P3dv2.5 and I want to continue flying with them until P3dv3 has installers for ALL the DLC I have purchased, while, at times, still flying and experimenting with P3dv3 on the same machine.

 

I quote myself here,

 

"Now, I must decide where to house the most advanced and important additions to my simulator...the almost, but not quite, the "raisins d'être" of my simming life. Mr. R has decreed that he will neither let the T7 nor the NGX live in both V2 and v3 worlds simultaneously."

 

I was variously castigated and vouchsafed regarding that comment, which was, at the time, not an opinion, but fact.

 

Today, I was apprised by another Avsim member of a quote which gave me hope; this, also attributed to Mr. R,

 

"To keep everything simple, you will not be able to install for BOTH v2.x and v3.x at the same time, unless you understand the file structure and feel comfortable doing a copy/paste operation on your own."

 

In other words, concurrent installation is not only possible, but implicitly OK'd in p3dv2.x AND P3dv3...exactly what I needed!...

 

So, while I cannot find the direct quote above, I must ask Mr. Randazzo, if he actually said that, and if so, which comment overrides the other?

 

I am perfectly fine with creating what ever batch files, redirects or symbolic links I need to accomplish that goal.

 

I have no intention of running them at the same time, rather spending development/learning time in each...at separate times, but WITH the NGX &T7 available to both.

 

Eventually I will be moving to P3dv3 permanently, as soon as all my purchased DLC is sanctioned, available and functional in that version of P3d.

 

So, with my intentions thusly spoken, do I need to open up a "ticket", or just receive a "how-to" install both PMDG products for use in p3dv2.5 AND P3dv3 concurrently?

 

 

Regards,

...And thanks for the best flying experience extant,

Chas Reed

[Richard McDonald Woods 168]

Robert,

 

I understand the delicacies of discussing other vendors' development techniques in public.

 

Surely the best way forward would be to establish a professional simulator developers' exchange where discussions could cover all aspects of the development processes without 'washing dirty linen in public'.

 

Just a thought.

[scandinavian13 5,192]

"Now, I must decide where to house the most advanced and important additions to my simulator...the almost, but not quite, the "raisins d'être" of my simming life. Mr. R has decreed that he will neither let the T7 nor the NGX live in both V2 and v3 worlds simultaneously."

 

[...]

 

"To keep everything simple, you will not be able to install for BOTH v2.x and v3.x at the same time, unless you understand the file structure and feel comfortable doing a copy/paste operation on your own."

 

[...]

 

So, while I cannot find the direct quote above, I must ask Mr. Randazzo, if he actually said that, and if so, which comment overrides the other?

 

A little bit of over-analysis here. As mentioned several times since we released the P3D products, your P3D license from us is a P3D license, and not tied to a specific platform at this time.

 

Nothing was "decreed" in the way you've written, above. The commentary about one versus the other was very clearly explained as how the installer would look for, and preferentially install into, the sims, given the various setups people would have. See here. This is the same situation that came from FSX and FSX:SE installations. Basically, if the installer found a version already installed, it would offer to repair it (as is typical with any full-product installer). In order to take advantage of the new installer's ability to look for a newer version of the sim, you need to uninstall the existing aircraft to ensure that the installer doesn't think it's simply repairing the existing install.

 

The source for the second quote is here.

[moish 0]

Dear Team,

Long time no see... My shop orders show the 777 and 737 are "for FSX".

I want to start flying again, this time with the new Prepar3D.

I guess I need to re-download the products with the installer for P3D v3 now.

How can I do it?

Appreciate your support,

Moshe

[scandinavian13 5,192]

How can I do it?

 

You will need to purchase the P3D version. These are separate products, for different simulators.

 

EDIT: See here.

[moish 0]

You will need to purchase the P3D version. These are separate products, for different simulators.

 

EDIT: See here.

Thanks.