Hey Ron!I agree with you 110%. I want to make it clear that I am in NO WAY blaming Phil for much of the stuff that is going on behind the scenes over there at Redmond. I'm actually blaming the Redmond Machine and not Phil and Aces and to be sure I do make a distinction.Case in point: As a Microsoft Partner, my company speaks with MS on a daily basis for one reason or another. When our customers are complaining about one thing or another and I am relaying that to one of the MS reps I don't blame them, and we (the MS rep and I) oftentimes just sigh together and realize that the ultimate decision is out of our hands. All I can do is relay the concerns of my client to the rep, who will in turn relay his concerns back to Microsoft. At that point, the 'nebulous cloud' factor takes over and that's that.So, I may not have made it clear enough that it's a Microsoft problem and not a Phil Taylor problem. The man has done all he can possibly do. (Even though, I was gonna ask if Phil Taylor has brought free donuts and coffee to the teams to which he is making his request. In my experience much more is accomplished with free donuts and coffee, or maybe a nice pizza party..bribry man, BRIBRY is the key!!!) :-lolWarm regards,Mike T.

"Many developers had no knowledge of the changes in advance, and as such released so called 'port overs' unaware of the changes made."-----------------------------------------------------------------In addition to what you've said it's a bit confusing for the public when there is no definition of what constitutes true FSX.For example, Phil states that a model which operates under FSX/SP2 is an FSX model. We have a so called "portover" which is a reworked FS9 source file and reports as FS9 that runs beautifully in FSX/SP2. Other 3PDs are in the same situation and must market these products as FSX/SP2 Compliant.What should be noted is the above mentioned product is not yet DX10 Compliant so you can see where there is still some confusion out there:-)

Understood Mike, It wasn't as clear the first time around as the second and we doubted that you were intending to lay it all on Phil:-)

I think a taxonomy is more along these lines:1)FSX-nativeThis is anything which is made with the FSX SDK. There is a natural good, better, best hierarchy here wrt versions of the SDK, with a cherry on top.Using the FSX-SP2 SDK is obviously best, as it gets you DX10 features and is the most up to date release. And this should be the preferred approach.Using the FSX-SP1 SDK is obviously better, as it incorporates fixes to the tools since RTM like the fix for the double vertices in XtoMDL.Using the FSX-RTM SDK is good, but I would hope that 3PDs would prefer the better solution at least. I say that because the lifetime of the RTM SDK was on the order of 7 months and the SP1 SDK has been out 12 now.The cherry on top is using the Acceleration SDK to get the advanced Acceleration features ( carrier oriented, helo oriented, race oriented ) when running on Acceleration.2)FSX-compatibleThis is anything that works in SP2 that isnt authored with a flavor of the FSX SDK.3)FSX-incompatible This is anything that renders incorrectly in SP2.That really should not look that surprising.

>1)FSX-native. This is anything which is made with the FSX SDK. Phil, here is where the confusion starts..FS9 source rebuilt to RTM, SP1, SP2, SDK still works fine in FSX/SP1/SP2/Acceleration and only lacks DX10 support:-)>There is a natural good, better, best hierarchy here wrt versions of the SDK, with a cherry on top.>Using the FSX-SP2 SDK is obviously best, as it gets you DX10 features and is the most up to date release. And this should be the preferred approach.SP2 SDK is the path we and others are taking in order to meet the DX10 support goal. The question remains for some. If SP2 is met but DX10 feature is not included in the product does it qualify as true FSX? >Using the FSX-SP1 SDK is obviously better, as it incorporates fixes to the tools since RTM like the fix for the double vertices in XtoMDL.>Using the FSX-RTM SDK is good, but I would hope that 3PDs would prefer the better solution at least. I say that because the ?lifetime of the RTM SDK was on the order of 7 months and the SP1 SDK has been out 12 now.>The cherry on top is using the Acceleration SDK to get the advanced Acceleration features ( carrier oriented, helo oriented, race oriented ) when running on Acceleration.>2)FSX-compatible>This is anything that works in SP2 that isnt authored with a flavor of the FSX SDK.>3)FSX-incompatible >This is anything that renders incorrectly in SP2.>That really should not look that surprising.

> By standards I mean many of us expect FSX to be more>framerate friendly. All I am saying is, should'nt 3rd party>developers share some of that burden well? >Well they kind of are held to that standard by the marketplace, aren't they? I mean, if they release something that brings a fast computer to its knees, how many people are going to buy it? Word would get out quickly.RhettE8500, Arctic Cooling Freezer 7 Pro, ASUS P5E3 Premium, BFG 8800GTX 756 (nVidia 169 WHQL), 4gb DDR3 1600 Patriot Cas7 7-7-7-20 (2T), PC Power 750, WD 150gb 10000rpm Raptor, Seagate 500gb, Silverstone TJ09 case, Vista Ultimate 64

"Using the FSX-SP2 SDK is obviously best, as it gets you DX10 features and is the most up to date release. And this should be the preferred approach.........3)FSX-incompatible This is anything that renders incorrectly in SP2."Excuse my na

Lets remind everyone again that FSXs SDK isn't complete. It lacks features found in the FS2002 SDK. SP2 even breaks vital performance essential features like LODs which did work in FSX RTM. The reluctance of some to move over to the FSX SDK is all Microsofts fault. If even bearly adequate tools & documentation were provided, few would look back. Phil, I'm sure most the biggest screw ups were before your time at microsoft, so i'm not knocking you personally. Just please use your power within that studio to provide future tools we actually need.The current scenery tools are well below average. 95% of developers are still relying on fs2002-SDK for vital ground elements. & these ground elements will never render correctly in DX10, especially at night or dusk. Fortunately, few use FSX DX10.

>Phil, here is where the confusion starts..FS9 source rebuilt to RTM, SP1, SP2, SDK still works fine in FSX/SP1/SP2/Acceleration and only lacks DX10 support:-)If it isnt rebuilt using the FSX SDK it cannot be "native" and can only be "compatible".

>>Phil, here is where the confusion starts..FS9 source rebuilt>to RTM, SP1, SP2, SDK still works fine in>FSX/SP1/SP2/Acceleration and only lacks DX10 support:-)>>If it isnt rebuilt using the FSX SDK it cannot be "native" and>can only be "compatible".So you consider "FSX Compatible" as legitimate FSX Product? It seems we are getting closer to a working definition then:-)Where the question was what defines "true FSX"? Are you saying we can now subsitute "native FSX" even if the DX10 feature set is not included?

I'd have to know more details about what FSX Library objects, as this would be the first I have heard of that.Is it all library objects or a certain class of them? Like for instance the original trees from RTM that were replaced for SP1, those should no longer be used.And no, that would sound like a previously unreported bug.

I am not sure my say-so solely defines what is and isnt so, I am simply trying to develop a common taxonomy albeit one that makes logical sense. I do not speak for MS business development, legal, or marketing here as I am only a dev team member.With that said, labeling previous generation product that renders correctly as "FSX compatible" seems fair to me.If a product is built using the FSX-SDK it is "native" by definition. However it should be labeled as "supports DX9 only" if it does not support DX10.

Fair enough Phil. No one expects you to speak for legal but your definitions here do serve as a guidline for devs and consumers alike.:-)

>I'd have to know more details about what FSX Library objects,>as this would be the first I have heard of that.>>Is it all library objects or a certain class of them? Like for>instance the original trees from RTM that were replaced for>SP1, those should no longer be used.>>And no, that would sound like a previously unreported bug.Hi Phil, Specifically it's the object titled haz_roofdishcomplex01 that causes the issue and I have not witnessed the problem with any other object textures in the library. I believe there is a small class of those object types and those are affected as well. Here's a pic for ya. Notice the background clouds show through the solid dish object. I believe I had read that messing with the alpha channel on this texture would rectify the problem, dunno, not a show stopper and I was just wondering if my scenery would still be considered as FSX/DX10 compliant per the standards you stated, despite not totally rendering correctly while using the latest SDK.I guess that it would be with, as you say, a small bug included. Thanks for replying.http://forums.avsim.net/user_files/188400.jpgRegards, Kendall#1: [email protected]/Coolermaster HyperTX2 Gigabyte P35-DS3L 4GB Ballistix Tracers PC6400 EVGA 8800GT - 174.74 beta Seagate 250GB 7200.11 CH Yoke/Pedals/Saitek Throttle Dual Monitor: Dell 2405/1905 #2: Dell 8400 3.2 H.T. 3GB PC4200 - X800XT Diamond Xtreme/Logitech X-530's

Here's another screw up. With ground shadows enabled, look what happens to the poor dolphins. This is in DX10 but it happens in DX9 too.http://forums.avsim.net/user_files/188401.jpg