My previous comments refer to spending hours making lists of code when it is the testing that is important. This kind of organisation requires no lists, just a decompiler and drag and drop in the right order.
The main concern is the load order testing of this material and the selection of the proper parts. - For example, more current material is likely to be in later SFS files and should overwrite earlier material in that order. Providing it all works with no issues then this looks to be greatly sorted out.
Another factor to consider is the fact that there are 4 Flight Modules, all of which reference Module One, the maps. These interact in such a way that all read from the same map directory but reference different vehicle sets.
The main benefits would be a small reduction in disc space and easier reference for the material. It may also maginally improve load times and performance. However, there is a lot of material to test. When you change the load order of the 3do material this can potentially effect meshes and functions such as loadouts and bombsights.
With the new structure already handling the classfiles so well this SFS structure would appear to be very much easier to reference and update. The core team at SAS discussed this very subject a number of times last year and recently too.
I would suggest, once we have Asheshouse and Benitomuso's new Ships.INI and content tested and installed, that we begin to re-organise along these lines. We may also be able to improve compression and reduce the number of individual SFS files.
For CUP Flyers this would be WAW.II. - A simple set of downloads to replace current content in SFS_WAW...
Thank you again for some excellent looking work.
Author
Topic: C.U.P. "CAN DO!" (Read 2012 times)
