Martin,I've tried everything I can think of - and I cannot make the A and D piers disappear at KCLT.I've tried a couple very poor 'afcad' files, tried moving the tower, etc. Can't make it happen.

The sort of future I envision is one where the tool vendors could play too, if they wanted.All that has to happen there is for us to add a section to the SDK to enable tool vendors to take tools and update them to output "true" version specific content and mark the content as such. Then the certification and signing process we would administer would not "know" what tool generated the content.That does take work and investment on the tool vendors part, but as long as they do that, we all win. That is where I see such a system having to go, otherwise we loose flexibility just as you say.I think I have my perspective screwed on right here :-).

>Martin,>>I've tried everything I can think of - and I cannot make the A>and D piers disappear at KCLT.>>I've tried a couple very poor 'afcad' files, tried moving the>tower, etc. Can't make it happen.my question is I bought acceleration and I was having issues with it; Will Sp2 addess those issuesthanks

For the record, I've seen scenery objects at Nellis, AFB in Las Vegas display this behavior of disappearing when viewed at certain angles while slewing.It only happens during design time, however, never when flying, and I always chalked it up to my nVidia driver.I think the average simmer would never encounter this issue while flying in the sim, and it certainly hasn't prevented me from designing missions departing Nellis.

No.SP2 will fail to install on top of Acceleration; because the same code is contained within Acceleration - think of SP2 as Acceleration minus the new 'for pay' features.

Lets think long and hard about Certification of any kind, consult with the oldest ACES' team members, long-time 3PD etc.I can see how this idea fits perfectly into the the current situation, but by the time such a system is implemented & in the long-run, it may be completely unnecessary, even counter-productive.IMO the only reason we have this situation now is because FSX was made with the good intention to be more backwards-compat then it turned out to be. Result = undocumented partial-backwards-compat confusing 3PD and users alike.If the plan is to cut pre FSX-SDK compatibility out of FSXI by design, the problem solves itself, no certification needed.Martin

Not sure that solves the problem. Depends on how you define it. Take the following scenario:1) User installs FS11.2) User buys aircraft model from 3PD for $90 USD (which is what it will be then) that isn't built to FS11 SDK standards, but will run on FS11 because of undocumented non-SDK "tweaking."3) But then, FS11 SP1 comes out, and suddenly, the aircraft won't function. Developer, who sees updating the product as a profit-draining exercise, tells the user the airplane runs just fine if the user will just uninstall that crappy FS11 Service Pack 1 that broke his fine aircraft.4) User blames ACES, because FS11 SP1 "broke" his third-party aircraft.That's pretty much what's occurring now seems to me. And it's avoided by having FS11 just never load up that non-SDK aircraft in the first place. I think that's the box some folks have put ACES inside of. And I think Microsoft's probably getting pretty tired of it.Just my view.

>No.>>SP2 will fail to install on top of Acceleration; because the>same code is contained within Acceleration - think of SP2 as>Acceleration minus the new 'for pay' features.The problem I see is a dev, even if not using the new features, is going to have to test against both versions, or risk having a problem.scott s..

I see your point fsxmissionguy.The question to me is can or should 3PD & their Addons ever rely purely on a SDK as tight as the FSX one (& FS9, FS8).Lets forget about the current state of affairs regarding Addons in FSX for a second, think FS historically. From what I have come to know complex Addons have never been possible without doing a certain amount of digging outside the SDK box. I believe this includes nuggets such as FSUIC, complex Aircraft, Ultimate Terrain, AES & many others. In essence lots of highly popular content may only exist today because smart 3PD went beyond the SDK. "Outside the SDK" does not always mean legacy code & old junk. I agree that right now with FSX Addons it seems to be that way, but I definitely see this as a temporary problem.Before decisions regarding Certification are made, it would be wise to analyze all factors responsible for the current situation. What do you think would happen to the next Windows if they announced it only runs executables programmed in DotNet4 .

>I see your point fsxmissionguy.> "Outside the SDK" does not always> mean legacy code & old junk.But it does imply: Possibly not compatible with future versions. And for that matter using the FS9 SDK to build FSX planes can be considered "Outside the SDK" and using FS7 tricks to create high res scenery certainly is.>situation. What do you think would happen to the next Windows>if they announced it only runs executables programmed in>DotNet4 .If the performance gain equals that of running a true 'FSX Only' AI Traffic add-on in FSX over a converted FS9 or older one... some people might not go completely crazy ;)Daniel

I have seen the disappearing buildings, in many airports, not only when slewing, and with plain vanilla install of accel (no tweaks, no nothing: fresh install). I guess it is a driver issue (8800 ultra, 169.25 driver). When seen at some angles, while panning, some buildings disappear, but only when autogen is off (go figure...). Anything from sparse up cures it.So Martin did not make it up. And it only happened after SP2/Accel. I've tested on two different systems (old P4 3.2/XP and new quad 2.4/Vista, both with 169.25 nvidia driver), same results. Maybe the next driver will cure it.Cheers,S

"What do you think would happen to the next Windows if they announced it only runs executables programmed in DotNet4 ."That is a way overhyped version of what I am suggesting; which is more along the lines of "quit loading those MS-DOS 16-bit executables that are causing compat issues".Requiring content versioned and marked a specific way does not mean 3PDs cannot 'dig outside the SDK box' at all. What it does mean is they can only do so for version n. Tightening things this way means 3DPs cannot do "out of the box stuff" for version n and then sell the exact same content as "version n+1 compatible" when it isnt and then blame Aces. Which is exactly where we are today.By structuring the platform so such hacks, even if useful, are automatically limited to a single version and thus guaranteed to not work in the next version means both 3DPs and customers are getting a clear signal of what works, what doesn't and why, and whose responsibility things are.That clarity will be good for everyone.

>"What do you think would happen to the next Windows if they>announced it only runs executables programmed in DotNet4 .">>That is a way overhyped version of what I am suggesting; which>is more along the lines of "quit loading those MS-DOS 16-bit>executables that are causing compat issues".Probably just a matter of semantics :)Isn't the goal of not loading legacy content already achieved when FSXI ships with no backwards-compat beyond the FSXI and perhaps FSX SDKs? I'm not sure I understand why an active or passive certification process needs to be added on top of non-existing backwards-compat.

No, I think it is more than semantics.The proposal you mentioned limited the universe to a specific flavor of Win32 executable. That is cutting off current content.The proposal I mentioned limited the universe by not executing 16-bit MS DOS executables, clearly restricting only the "old universe" and not touching the "current universe".The two proposals are different in kind, and that is a very important distinction.Perhaps modifying load to change the back-compat story will be enough. If it isn't clear, btw, let me be clear in that what we are discussing is only a possibility for the future beyond FS11 and not a "baked" plan. So I hope we can have these sorts of "future" discussions without panic and with thoughtful remarks.

I see what you mean now Phil, thanks for clearing it up :)