3rd party complications due to multiple FSX releases?

Multiple times a concern has come up that our release plan unduly complicates the 3^rd party developer’s lives and they now have support issues across multiple platforms. I have replied at least once, but instead of my posts getting buried out there in numerous threads, I will blog about this.

I don’t understand this concern.

All of this year's releases are essentially RTM in terms of features exposed in the SDK, at least so far.

So FSX is a single target unless the 3^rd party takes a dependency on a particular piece of content we authored.

Let’s remember that as we then walk thru the releases and their impact on 3^rd party development.

SP1 adds fixes. And is detectable by a 3rd parties setup. So while I can see a 3rd party wanting to test for the version number ( probably to guarantee the better performance of SP1 ) and popping a dialog to inform about lack of SP1 in the setup – how else does this release impact 3^rd parties? Maybe a little setup work, but I can’t see a content authoring issue due to this release except for one specific piece of content, see Note 1.

DX10 adds the new DX interface support. DX10 will require SP1, but that is our Setup authoring work. There is currently no DX10 specific content authoring in the SDK. As long as we keep it that way - how does this release impact 3^rd parties? Even if we did change the SDK then a 3rd party could decide to target DX9 only and not have to worry about this release at all, setup or content authoring. We do have an obligation to discuss on the beta forums any FSX SDK changes driven by DX10 features so we can front-end load the community’s knowledge base. And we won’t make a change or addition without there being a clear benefit.

XPack adds new content, true. It will also contain SP1 and DX10 which should actually make XPack better for 3^rd party developers. So unless a 3rd party targets the specific new content here - then does this release impact 3^rd parties? Especially if the 3rd party ships ahead of XPack - all things being equal and the add-on follows the rules then there should be no issue here. The XPack team are the ones to talk to their plans in more detail but I know they also take the relationship with the 3^rd party community seriously.

Now, true it is possible for a add-on to take a specific content dependency and to have to care. But that should be a conscious decision and is not something forced simply by our release schedule.

So the most likely scenario is the 3rd party has performance concerns and wants to detect SP1’s presence or absence and perform some UI interaction when there is no SP1. So there is likely a little more work for everyone at Setup time. But not a horrendous amount.

Or am I missing something here? A dialog is welcomed.

Note 1: One performance fix we are evaluating pertains to our authoring and rendering trees differently. This does affect vegetation.bgl, but is controllable by the .cfg file. We are working to make sure excellent add-ons like TreesX are not impacted but we have to go thru the test pass to make sure of this. The beta forums will be the proper place to discuss this issue in depth. Stay tuned late next week for more!