Phil, do you think FSX will gain in popularity

[DougMatthews 0]

>Would it be too much to ask for the installer to have a>readme that details the files that are modified by SP1?Not sure. I'll pass the request on and see what happens.-Doug

[virtualstuff 758]

>If you've applied some of the various tweaks to the default>files, you've got to un-tweak (or re-install FSX). This is>unfortunate, but the way our current patch technology works>requires that the files be in their original state. For those>who are concerned about the activation limit, worst case>should be you might need to activate by phone.>>-DougFirst of all thank you for your hard work and the upcoming SP1 but...Doug that is one of the most unlogical checks you could have build in seriously a lot of other options for protecting your software...I have to say that is customer unfriendly in a tweaking community and due to nature of FS software and add-ons...Andr

[Guest stew286]

hi phil, FSX seems to me to be likened to the old ATP that we did in the mid 80's.The progamme was good but the harware did'nt exist till a year later with the dx2 chip.Do you think FSX will go the same way As ATP it was the ammount of scenery with the roads and rivers and the airport also the night lighting.The programme was advanced for the time but know one could see the potential of the forward thinking scenery.It was and still is FPS,thats the way people thought a flightsim should be.I think FSX is the way forward, it is the next big step you and the aces team have bravely taken.I UNDERSTAND the problems with multicore threading but with Vista on the horizon at the time of Fsx's conception multicore chips becoming the norm a little forward thinking could have been more appropriate.People like eye candy but they won't use it at the expense of the dreaded FPS.When Fsx was first released there was a buzz of excitement,anticipation but that has turned to dissapointment in a lot of cases.Hardware will catch up,addons will come but the industry are holding there breath to see if FSX will work.Sp1 will have to address a few things before people put there faith in it.I hope it works i personally love it i can see the work from people who like simming in the way it is graphically potrayed.All the beststu

[Guest stew286]

andre,here, here i totally agree.stu

[greggerm 312]

>Doug that is one of the most unlogical checks you could have>build in seriously a lot of other options for protecting your>software...It's not a software protection issue. It's a patching issue.Patch software has advanced from simply sending out new versions of files to using in-place updating. Patch creation software will look at the original file, then look at the NEW file, and perform a "delta" analysis so that it only includes what is needed to change the old file to the new file. This keeps patch sizes WAY down. If you have somehow changed or replaced the original file on your computer, the patch cannot do its job because the original information it needs to build the new file doesn't exist anymore. By all means this isn't a validation or piracy protection issue - it is purely a technological one. This typically applies to binary files and other program related items. It could also apply to texture files, depending on what ACES is repairing. I doubt that the FSX.CFG file will need to be in it's original state, only because that is meant to have changes in it. But if somehow you've tweaked any DLLs, EXEs, or other core files, I would expect problems. EXAMPLE:Lets say the patch adjusts the cloud textures. It uses the original files from RTM FSX and a delta algorithm to create a new file. Microsoft has the choice of sending out the updated cloud library as a whole (40MB), or the delta-change files (say, 5MB). Which is more efficient? Use this method to adjust lots of files (ground textures), and you can see how this is the most efficient method of distributing a patch. Customer unfriendly would be issuing a 500MB patch that brute-force replaces files when it could have been accomplished in a fraction of that size using delta methods. Either way, any paatch-targeted files you tweaked would get overwritten - eliminating the tweak in the end. It's bad enough there are millions of hardware combinations existing in the world today - imagine the number of varitions that we as AVSIM users have in our tweaked FSX installs. Without a baseline to build a patch from, it would be a near biblical task to sucessfully patch all the needed files while at the same time being knowledgable of all the potential tweaks and accounting for them. -Greg

[virtualstuff 758]

I don't agree and that's my professional opinion ;-) You can write a routine to check also the different files and just overwrite that easy hehehe...A new reinstall or revert to your original base install is customer friendly :-lol which maybe included to call for reactivation of the product... (uninstall of all addons too in that case)Nope it can be done far smarter when you choose so ;-) 500 mb download with nowadays bandwidth (downloading Gb is more the case today) isn't that huge anymore lol we will see a bandwidth increase in the near future lol maybe via ASP.At least let the customer choose... to save bandwidth and server load is more the advantage of the selling party.From a customer perspective I find it the most unfriendly manner to distribute the patch ;-) and from a technological point of view not a example of the "K I S" principal...That's why everybody has to revert to the original installation because many things can go wrong...Just replace the core files + patching ones think of a SP installation not DX routine...Andr

[n4gix 4,947]

>I don't agree and that's my professional opinion ;-) >You can write a routine to check also the different files and>just overwrite that easy hehehe...Andr

[PhilTaylor 45]

1000m or more.

[virtualstuff 758]

>Similarly, if any specific "patch update" for an existing file>only involves replacing 50KB of a 5MB original file, it would>make no sense whatever to replace the entire file!Bill thanks for the explanation appreciated I understood the points mentioned by Gregg but I don't agree...In ideal world I would agree but let's compare it to an operating system or servers or mainframe software...There are many parameters involved here and there can go so many things wrong not to speak about error handling not done and to get a general error message...Only a check on original file date and size etc won't do it...Tell your customers to revert there servers back to the original state I don't think so... Beside the registry and program adjustments, try it with a software program with 4000 different user parameters lolI can tell you stories... after the update the adjustments in most case has to be restored or redone what is logical :-) from a technical point of view.Just replace the core files is the most logical step to do (besides a backup lol)As an IT guy I know what can go wrong in software land ;-) I'm not talking about just a simple patch of one software program...Bill my point is that to ask your customers to revert to the original state of the initial installation isn't customer friendly (imagine a lot of add on software installed) with what ever software...If they choose to check on original files etc... then write a routine that will replace the file when not original etc... The same as with a windows 2003 sp. for exampleSo I agree to save bandwidth but to ask customers to revert your installation back to it's initial state isn't friendly at all.This proves we have still a long way to go with software development and programming languages it's still to much an approach from technical point of view...So in my opinion when you choose this method then only warn the customer that his tweaks will be lost and just install the necessary files.. that's in my view customer friendly ;-)Believe me in some case it make sense to replace an entire file ;-) Andr

[scott967 62]

>Bill thanks for the explanation appreciated I understood the>points mentioned by Gregg but I don't agree...>In ideal world I would agree but let's compare it to an>operating system or servers or mainframe software...What I found interesting is that the first patch was 8.3mb for FSX_patchsetup.exe, and all it did was replace the 700kb terrain.dll. Maybe the patch overhead does not grow as fast as the payload, at least I hope not!scott s..

[n4gix 4,947]

>Tell your customers to revert there servers back to the>original state I don't think so... Beside the registry and>program adjustments, try it with a software program with 4000>different user parameters lol>I can tell you stories... after the update the adjustments in>most case has to be restored or redone what is logical :-)>from a technical point of view.No one is talking about "addons" here. In fact, I installed the SP1 beta without having to do a bloody thing to my FSX installation, and I've got a ton of "addons" installed!What ACES is talking about are only the specific core files that FSX installed to begin with.Only folks who've modified the core files in any way, shape or form will encounter problems...Quite frankly, this is making an entire mountain out of a molehill, since there are likely not more than a relative handful of folks who've hexedited any .bgl files, resized textures, or performed other arcane and possibly obscene acts on their core files... *:-*

[virtualstuff 758]

>Quite frankly, this is making an entire mountain out of a>molehill, since there are likely not more than a relative>handful of folks who've hexedited any .bgl files, resized>textures, or performed other arcane and possibly obscene acts>on their core files... *:-* Bill we will see...Glad you have a positive experience with the beta. (Do you beta test software in your daily job too just curious? and which methods do you use then?) (but be careful to say I don't have the problem so the whole world will also *:-* )Add-ons will be the case to reinstall when you have to reinstall your FSX installation... I agree that most bgl files will be in there original state...But resized textures is a total different story a lot of people did just that because of performance reasons :-rollTime we will tell but I still don't find it smart approach.I don't make the issue bigger as is I state only my opinion that I find it customer unfriendly.Cheers,Andr

[n4gix 4,947]

>Glad you have a positive experience with the beta. (Do you>beta test software in your daily job too just curious? and>which methods do you use then?)Er, this is my "daily job." I work full time developing content for FS9 and FSX... ;)>Add-ons will be the case to reinstall when you have to>reinstall your FSX installation...That will always be the case if someone does a full reinstall of any software. >I agree that most bgl files will be in there original>state...>But resized textures is a total different story a lot of>people did just that because of performance reasons :-rollIn any case, no "reinstall" should be necessary. That's why there's a "Repair" option on DVD#1. Running the "Repair" option will revert FSX to it's original core content without disturbing any addon product that's "followed the SDK" with regards to it's installation.

[Mike T 208]

John:I don't think that there is a "lack of community support" per se. This release of FSX has posed some very intersting challenges and spawned a very unique dynamic.Support for, and use of, FS9 remains extremely strong compared to previous releases of a new MSFS version. FS9 still remains a very viable alternative to FSX right now and the market for FS9 addons remains strong.Secondly, out of the gate, FSX does not have the FPS bandwidth to support hyper complex add-ons such as PMDG 747-400 that, on average, demands 10-15 FPS as the price of admission. If one were to take a run of the mill FSX system averaging 25 FPS, a hit of even 10 FPS could mean FPS penalties that would render the sim totally unusable. (No 5 FPS is not smooth).Aces is diligently working on SP1 and, while I am sure that most major 3rd party developers have been made aware of the changes that will be required post SP1, for their upcoming FSX releases, I have no doubt that changes will be necessary that would further cause complex FSX add-on delays.Additionally, many would like a true gauge of the improvement that is gleaned with SP1 when viewed across the board, vis a v, just a handful of beta testers. Surely, if everyone is screaming around FSX at an average of 45 FPS post patch there is a lot that add-ons can bring to the table. On the other hand, if the improvement is only 10% on a system averaging 15 FPS that only amounts to a 1.5 FPS increase. In such a case strategies would have to be reassessed.The ultimate timeline for migation to FSX from FS9 is still an answered question. Will SP1 and the DX10 patch be enough to cause a mass exodus to FSX? If the answer is yes then I am sure you will see a flood of FSX products on the not-to-distant horizon. If the answer is no, and development must be split between FS9 and FSX for the developers to turn a decent profit, then things will be slow in coming due to the need to develop one product twice.At the end of the day, there are very complex dynamics at play and even now, many developers who had moved to an FSX only paradigm have had to backtrack and continue development for FS9. Most are not willing to take a "devil my care" attitude and go full bore with FSX until they see where FSX is going. After all, there are businesses to run and paychecks to be covered. Even if 65% of all users who purchase FS addons have thrown FS9 into the garbage bin in favor of FSX, that means that 35% have not. That translates into a 35% reduction in profits for 3rd party developers. Most developers are not so cash rich to absorb a multilateral 35% hit to their bottom line.So, the best thing is to wait and see. Even the release of SP1 is not the final say in regard to FSX performance because Aces has the DX10 and Dual-core patches on the horizon. I believe that new products for FSX may be much slower in coming down the pipe than any other MSFS release. FSX will take patience in more ways than one and the final guage of its success (or failure) is no where in site. If you would excuse the analogy, but, if FSX were a flight, it would be only on its initial climb out phase. We've not even settled into our long cruise yet (even though many of us are starving and want the flight attendents in the isles serving a nice hot meal as soon as possible).So, we'll have to simply be patient, wait and see what comes out of the galley and hope that the flight attendants shave their legs before coming out into the isle!

[greggerm 312]

Jeepers Mike - You'd think you actually put some thought into that!VERY well said. Mike "wins the thread". :)