I'm sure I'll get some hate mail for this post but there you are. I clearly don't understand some things. If possible, I would like someone to explain:1. In flight plans - why are some developers mixing up the aircraft numbers within the same aircraft type. For example, you might have 20 Airbus A320's of the same type. All the aircraft numbers within this block have AC#1 as their designation. You look at the block and suddenly you see a single AC#2 (or some other number) and then you look above that and see an AC#3 - not even in sequence. I can assure you that if you have a bunch of aircraft registrations it is very easy to miss those exceptions. You have to separate them out any way - to match the aircraft.txt file, so why not give the user a list that has the numbers separated. It sure would be nice and save a lot of time for us.2. Some developers (I think to save time) put a large number of aircraft registrations in one large block. On the surface this saves a lot of time because you can use one repaint to represent all the aircraft in that one large block. However, in the name of expediency, some developers don't properly research the tail numbers. I find a lot of aircraft in these large blocks that are special livery schemes (not identified in the aircraft.txt file). I usually check the date of the FP to see if the paint was changed after the FP was published. More often than not, the dates of the photos are earlier than the date of the FP. So, the flight plan has a number of errors. I know, some people don't care about that. They just "stuff" FPs into their system. But there are users out there that like to have their FPs current. I don't understand.3. A long while ago, a couple of very bright guys came up with a methodology for developing flight plans. I don't remember their names but the FPs are still being developed under this methodology - MRAI. Now, part of that methodology contained the following:a. Use of "@" signs within the individual flightsb. All flights using the "Week" as the day-of-the-weekI don't remember the technical rationale for these techniques but I do now that the major FP developers use these. There are, unfortunately, an increasing number of FP developers that do not use the above. I don't understand. Has something changed? I have over 2,000 individual single *.bgl airline FPs in my AI system and all of them use the above. Can someone explain why some have gotten away from this?4. Traffic Tools (at least I think it does) requires three text files to successfully compile a flight plan. So why are many developers using a single file for FPs. That causes the user to have to divide the single file into three before compilation. I always thought a developer should save the user unnecessary time to get a product into a system. Am I wrong here?5. Regarding repaints - Increasingly, developers are including all sorts of file formats in their repaints. Why? Many painters are supplying three different formatted files in their uploaded packages. Most of these uploads have DXT3 Mipped and 32-bit *.bgl files. If you'll look at these large 32-bit textures you will see that they are nearly 4 times as large as the DXT3 files. I keep seeing people complaining about stuttering in FSX and slow load times and congestion at large airports. I can almost guarantee that if you use these 32-bit textures, it is the cause of your problems - especially in FSX. The reason to use DXT3 Mipped format is to reduce texture display anomalies. It works very well. So, why include all these other formats. I mean, this is flight simulation - not airport viewing simulation. Perhaps I'm wrong.6. Painters are increasingly leaving out the aircraft registration numbers in their config sections. That means the user has to use some kind of utility like TView to check to see what the number is. Now, I know you're thinking - why do I care what the number is. Well, when you prepare your FP and the developer has included something like OC or NC (old color or new color or some other special scheme), there is a chance that you don't have the proper repaint. However, if you have the registration number, you can check the FP to see where a particular repaint fits or if you're going to have to go back to the AVSIM library for a download. I know many developers paint the registration number of the tails, then why not just include it in the config file you supply the user. It would save a lot of time. NOTE: I also know that most developers provide a pic of the aircraft. However, on many pic files, you can't see what the number is - it is too small.7. Many developers are now painting complete fleets for airlines. This looks great but I can assure you if you put all those texture files into an FP, soon your FSX system will ground to a halt - especially with complex scenery added on. Personally I don't mind having different repaints if the paint scheme is different. But come on! 20 repaints of the very same aircraft - the only difference is the tail number. This takes a whole lot of work to get all those textures into your system when one aircraft can represent all the same textures. NOTE: I'm not completely "sin" free here. I used to paint entire fleets until I started using FSX. I stopped because of the performance penalty.8. I'm probably going to get a lot of grief here; but, is it really necessary to embed your texture files in unnecessary layers of folders. What is the purpose of doing that. I don't understand. All you really need is one folder and the config file and the pic (if included). You don't need all those individual folder layers.9. Why are painters still including the "thumbs.db" files in their uploads. This is a totally unnecessary file. Why not delete it before uploading. Let me explain the problem here. If you're going to do a mass copy or move of multiple folders and you want to start the process and go for a potty break or get some beverage and then come back to a completed task, this won't happen. The first time the OS encounters a "thumbs.db" file, the copy or move routine will come to a screeching halt. You'll have to monitor the entire procedure to tell the OS it is OK to copy or move this file. If you have a bunch of these in your AI environment - well have fun watching.I'm not trying to throw stones or start arguments here. I really just want to know why these things are happening and hopefully get some of these practices reduced or stopped. These things cause the user a lot of extra work. Please help.Frank

I'll mention only two points in this response.1. The thumbs.db file is autocreated by the OS. Yes, the diligent developer will take the special effort to delete these before zipping up his project, or running an installer compiler. But, should they "take another peek" in that folder with Windows Explorer, a fresh copy of thumbs.db will suddenly appear again... :( 2. Many folks simply don't understand how to properly set up and take advantage of the texture.cfg "fallback" system. The main ..\texture folder should have only "common textures" used by all variants. Each variant should have only those few textures that are unique to itself, and be kept in ..\texture.variant folders. Each ..\texture.variant folder should have a texture.cfg file with the first "fallback folder" set to ..\texture. Simple!

1. The thumbs.db file is autocreated by the OS. Yes, the diligent developer will take the special effort to delete these before zipping up his project, or running an installer compiler. But, should they "take another peek" in that folder with Windows Explorer, a fresh copy of thumbs.db will suddenly appear again... :(

The easiest way to take care of this problem is to Enable "Do not cache thumbnails" in Windows Explorer Tools/Folder Options.Regards, Mike Mann

2. Many folks simply don't understand how to properly set up and take advantage of the texture.cfg "fallback" system. The main ..\texture folder should have only "common textures" used by all variants. Each variant should have only those few textures that are unique to itself, and be kept in ..\texture.variant folders. Each ..\texture.variant folder should have a texture.cfg file with the first "fallback folder" set to ..\texture. Simple!

When I first encountered the "nested texture subfolder" I thought, "Gee, what's this about?" After thinking about it for a while I decided it wasn't a bad solution to dealing with multiple reg no paints (for example, all the SWA one-off paint schemes) for the same airline. Whether it really is necessary to have a unique paint for every single aircraft I guess is a problem for the user to decide.As far as texture formats, this seems to approach a "religion" issue. Might as well argue between iPhone and 'Droid.scott s..