Can MAIW package design principles be improved?

[kungfuman]

Hi folks,

Today I have decided to offer some uninvited criticism!

I think it best if I first of all enlighten you to my angle: I am, and have always been, very impressed with what MAIW has contributed to my "FS World". As a fan, I see that the potential to meet the very highest standards in AI package design exists right here, and I am therefore very keen to see that this potential is met. It is what gives MAIW its credibility IMHO. But I am also fully aware that all the hard work is done by dedicated and passionate individuals in their own free time, at their own pleasure, and often as respite from the stresses and demands of their "real world" lives. They owe me nothing (we are all indebted to them), and by offering my criticism I simply hope to make sure their future efforts continue to be received with the highest acclaim.

MAIW packages represent some of the very best that the FS world has to offer. Great AI models and paints, well researched squadron knowledge and understanding of what constitutes realistic flightplanning (within the limits of FS), and top-notch airfield scenery where offered. Further to that, where no scenery is included, MAIW fans have been gifted with detailed AF2 files created to the highest of standards.

Now, within the MAIW philosophy of what makes a good package is the important principle that they must design for the default FS9 set-up. Everyone modifies things in their own unique way, so this apparently makes a lot of sense. However, what many fail to realise is this: The true value of the MAIW packages is not only do they adopt the aforementioned principle, but also the structure of the packages is very easy to modify to suit one's own set-up. And this is equally important, because although the packages are designed for the default FS9 set-up, barely any of the package users actually have such a set-up.

Now for the criticism:

Most packages install AFCAD produced AF2 files in conjunction with seperate scenery related files. But because some designers would rather use AFX to create airfields, they grossly devalue the resultant quality of their packages. AFX files are notorious for causing scenery related issues, but most importantly there is currently no freely available method for editing such files. Therefore, two problems arise immediately:

1. Only the very few amongst us that actually run a default FS can hope to be satisfied by such a package (ok, that's a bit extreme, but generally speaking my point still stands).

2. Inevitably, designers will make short cuts, miss things, have lower standards etc. as this is after all just a hobby. Using AFX means that such problems cannot easily be rectified by the end user, if at all.

The LFBM AFX bgl file in the French Mirage F1 package is a case in point, but not the only one. A new fan recently posted in the "Tech forum" about how to modify that file to include a working ATC. Like many, he used AFCAD to sort the problem. Who knows what he will have destroyed in the process? Most users would not know, let alone know about the existence of such an issue.

Now, such oversight on the part of the designer does not necessarily detract much from the overall quality of the package. Designers are not infallible. All it requires is that the error is easily corrected by the user, as this is a much more pragmatic solution compared to, say, waiting for a comprehensive re-release of the package in three years time. Very few packages are entirely error free, or fully compatible with my set-up. But as long as it is easy to get everything working, I still rate the package highly. It is only where it is just not possible to even correct the usual issues that the package loses its prestige.

In summa:

MAIW, please recognise that your greatness is not only due to the fantastic content within your packages. It is equally due to the ease with which we, the fans and users, can adapt your packages to suit our unique system set-ups and their associated needs.

I do not have to use your packages, but I would sincerely love to. You may not care about my criticism, but I imagine you care about being the very best.

Thanks for everything

(edited into English, as I omitted a couple of necessary words)

[BadPvtDan]

That's a well thought out post; thank you.
AFX is the tool of choice of some designers. It certainly has it's limitations but so does FSDS and FS9, FSX, etc. AFX, IMO, is much easier to use than afcad. As such, you will continue to see it being used.

If you want to one day pay for MAIW then we would certainly cater more to your tastes. Until that time, designers will probably continue to create anduse the tools that they like.

[Jumpshot724]

For the few AFCADs I have done for MAIW, I use both AFX and AFCAD. AFX for the groundwork, and then I pretty them up in AFCAD as I think the AFCAD looks 100x better than AFX in-sim.

[PaulH2]

It seems to me that your criticism is specifically related to the use of AFX, rather than design principles, per se.

I think the real problem is, what choice is there? Wonderful as AFCAD was in its day, it's an extremely basic tool that hasn't been updated in 5.5 years. It does waht it does very well, but it is limited, and frankly it is obsolete.

I agree, that AFX being a payware tool does cause issues, but today, there are no freeware alternatives. In time, this will change (I personally use ADE extensively for FSX and when the FS9 version is released, that may be the answer) but AFX is used in order to add functionality that just can't be done in AFCAD (alone).

I won't go into details, but recently we beta tested a package in which there were some scenery issues. This was very quickly fixed by converting the AFCAD to AFX, the problems were solved and the airport in question looks great. It wasn't a question of preference, but of quality.

My suggestion would be, if there are things that you consistently think could be done better with the airport designs, bring those up and I'm sure the designers will listen and take them into consideration if possible, but remember that it just isn't possible to accomodate everybody all the time (and yes, I know AFX complicates that, but sometimes AFCAD just doesn't get the job done any more). If there is an issue such as the one you mentioned at LFBM, this is the sort of thing that could be addressed in an update, but (in my opinion) it really isn't realistic to expect MAIW (or anybody else for that matter) to support user modifications.

I do see where you are coming from but I think the quality of the packages as released is of utmost importance and if using AFCAD instead of AFX would compromise that quality (and I know for a fact that would have been the case on at least two recent packages) then I for one don't think that is acceptable.

Just my (personal) thoughts...

Paul

[Firebird]

Well firstly I should thank you for a well detailed and well thought posting rather than just a rant.

OK now on to your points.
1. You are absolutely right about the fact that few people operate the de facto standard default FS9. For example I would go as far as saying that none of the staff actually operate it that way.
However we have to choose a datum, and the vanilla system is the only valid option.

2. You are right that things are missed, screwed or just plain forgotten with packages. We try to avoid this but we are all human. However, our objective is to produce packages that will enrich FS9 for a user with little or no knowledge of the FS9 AI system. We do not produce packages for experts. There are always improvements and modifications that individuals may want to do and we encourage this.
The best example of this is that I have never used the installer for an MAIW package as I have my own little system and way of doing things, but as I said earlier its not about doing it my way, or imposing my system on others. When I beta test, I test for the default system and the default user. It has to be that way.

Now on the specific example of AFX, I would agree with everything you say about the fact that its payware and that if you want to change something you have to splash the cash. We do not promote this, but we do warn people about making changes to AFX afcads and the consequences.
No as somebody that does like to tinker with stuff himself, I consider myself similar to yourself in that way. I too didn't understand why afcads were made using AFX. However I now appreciate the features of the application. I had to make a choice leave the AFX alone or buy AFX. I chose to buy.
I am not advocating that everybody do that but I do see why people use it for afcads and scenery.

Now when the FS9 version of ADE becomes available it may well be that this will be used it fulfills all our requirements.

The bottom line is that we have to serve the majority, the minority ( this includes me ) have to make decisions around this fact.

[campbeme]

I must say when AFX files first appeared I hated them, all because I did not have AFX so could not test properly. But I have to agree with Paul, sometimes Afcad just cannot produce the quality we all now expect. This weekends testing proved that, AFX solved a issue in one attempt, where the normal method of AFCAD and Excludes just could not produce the goods after countless tries. Just think how many MAIW excludes and taxiway sign bgls could be removed from our systems if only AFX was used. For this reason alone it's well worth the money. For me the reduction of files in a package is a step forward in package design.

Just my opinion

Mark

[Greg]

I think we're all waiting for the FS9 version of ADE to come out. When that happens I'll gladly convert all my old MAIW AFX files if necessary, but for now you'll have to live with it I'm afraid as AFCAD's no longer an option.

The background image function alone saves me a lot of work to get the same result.

Greg

[djnocturnal]

A bit off topic here, but where does AFX save the excludes info? is it in the afcad file itself?

[VulcanDriver]

Yes AFX saves the exclude data within the AFCAD code.

I use AFX for many reasons, mainly as you can use a background image for designing; taxiway signs are a breeze with it; excludes are easily created. And finally AF2 has not been updated for years and is no longer supported by its designer.

I'd like to see AFX upgraded to become more of an airport design tool.

I will not be going back to AF2 for one.

[MIKE JG]

Long live AFCAD and SBuilder, who needs AFX......

/ducks for cover......

[kungfuman]

Thanks everyone for your sincere responses.

I fully accept that designers will only design in a manner that pleases them best. The compromises they choose will have nothing to do with my remote "user" preferences. However, to maintain MAIW's standing as number 1, being aware of the sort of problems that making such choices will result in is probably quite important when it comes to keeping the maximum percentage of fans 100% happy (if that be your aim).

PaulH2,
Indeed, my criticism is about use of AFX, but such criticism is only valid against the backdrop of what design philosophy is adopted by MAIW. I contend that it is the flexibility of the packages to be installed as the user sees fit that gives MAIW such great value amongst its supporters. And as this is a fairly subtle point, I believe that it has been overlooked by MAIW fans and staff alike, resulting in use of design programs that do not embrace this particular need. End result: packages with more instances of problems, because users cannot easily iron out the usual teething troubles in the way that they used to. I am not saying that this makes MAIW packages bad. Far from it! I am just lamenting what seems to be a small step backward in compatibility, in that this more subtle principle that was imho partly responsible for the broad appeal of MAIW packages has been unwittingly abandoned. Therefore my post is also about what principles should be followed, and whether this particular principle is valuable enough to be adhered to (my claim is that it is).

As you say, AFCAD does what it does very well. I would add that it also does this without the problems that use of AFX introduces, and is therefore superior to AFX albeit in this respect alone. Frankly, AFCAD will only be obsolete on the emergence of a new freeware utility that does the same thing, but better (or with more additional functionality). Are there not other utilities that will do the additional things, that can be used alongside AFCAD in the meantime? John Stinstrom seems to be capable of great scenery without resorting to AFX.

Great sceneries and AFD files were possible before AFX was used. Now that AFX is here, I fully appreciate it provides some design "short cuts", making the process much easier. But questions remain about the integrity of its output: AFX files (see fsdeveloper website, and others). While it may be easy to use, this has little to do with the more important question of the utility (flexibility) of the files it produces. AFX files cannot generally be adapted to suit a users needs, whereas AF2 files can, using the "obsolete" AFCAD program. It is this important quality that is missing. Personally, I'd rather have seperate standalone files for everything, making it possible to disable or replace shoddy or unwanted elements wherever they occur. And surely the designers themselves would rather not be subject to endless requests for corrections to their releases? Surely it's easier for the end-user to make a quick fix?

Given that the vast majority of users each have their own unique system set-up, MAIW are absolutely doing the right thing by designing packages for the default, as this represents the closest thing to a common ground. It is the users responsibility to make sure their various FS modifications remain able to support packages released for the default set-up, should they ever hope to be able to use such packages.

Equally, it would be an intelligent move for designers to accept that most users will end up needing to make the occasional modification to packages for reasons of compatibility with the user's own set-up. Why? Because that is just a real fact about the world. Thus, ignore it at your peril. That's not to say MAIW should provide extensive support for this, but designers will broaden the appeal of their products by allowing for a certain amount of flexibility/versatility.

Cheers,

Dan

[nickblack423]

I must admit Dan, that I read your post with great interest. Here is my own personal response.

We at MAIW strive to make the out-of-the-box Flight Simulator a better place for Military AI. However when testing we do often come across problems with certain personal setups, such as terrain mesh and VFR scenery. We endeavour to try and correct problems when using our packages with these other third party packages, but as you will know, we can never hope to cover all eventualities.

You cannot tell me that if you were a package creator at MAIW, that you would create the package with the end result hoping to be "I'll make this easy for someone to change all the hard work, research and time I've put into it." That never even comes into our thinking. Our end result is always. " I'm going to make this the best possible package, researched properly and accurate as hell, and ready to roll out the box, so that the user will not have to do anything to it to change it." The first approach here is pointless and against our principles. We will always strive to have our packages be as accurate as possible, and we will always respond to constructive criticism or ammendments from people who know better once a package is released as we always do, and update the package accordingly.

Now to say that we should use AFCAD to create a standard file that can be ammended by the user is a bit narrow sighted. I myself do not want the user to ammend my AFCADs or they may lose the standard of the work I put into them. I myself went to AFX because at one base for the Finnish Hornets package I had to create 25 exclude files to hide some trees that were overlapping from the default scenery. With AFX they are done in 1 file. And I see no reason why a user would want to change that AFX file, I can see that they may want to look at the AFX but that is why we have disclaimers on the readme's now stating that you will lose some details from the AFX if you open it with AFCAD.

I guess what I am trying to say here is that we have discovered that AFX is an invaluable tool. It helps us to make our packages for you the user more streamlined, and has also helped us to make them more realistic with the advances of being able to add taxiway signs as well.

Nick

[BadPvtDan]

Thanks everyone for your sincere responses.

However, to maintain MAIW's standing as number 1, being aware of the sort of problems that making such choices will result in is probably quite important when it comes to keeping the maximum percentage of fans 100% happy (if that be your aim).

Here is where you are wrong and what I meant in my original post. We create packages to make us happy. That is why we do not take requests or have deadlines. Every package was dreamed up by a package manager because he wanted to see it in his sim. You, the lucky user, just get the benefit of that work.

Now, if we charged you for our work...that's a different story. Then we are making packages meant to keep as many happy as possible.

Do you see the difference?

[KevinJarvis]

We create packages to make us happy.

This is out of the norm for most flightsim add-on groups. But I like it.


I used to work for a large AI group who's purpose was to develop packages that the end user wanted. By doing this, it left the door open to constant criticism as to why the packages didn't work for everyone.

Truth is, not everyone has the same set up.

This hobby has lost many a talented designer simply b/c the end user, who didn't pay a dime for the product, complained so often and so adamantly that it drove said designers away.

If MAIW continues to produce packages that make them happy, I for one, am more than grateful that they allow me to get in on the fun.

[MIKE JG]

Dan, you will be happy to know that I still use AFCAD exclusively and have had no interest in going to AFX. But let me explain why.

Being a scenery designer, (John S. isn't the only scenery designer we have, LOL) I have learned to make use of a powerful design program called SBuilder in addition to modeling the scenery with FSDS. FSDS obviously creates the models and SBuilder is invaluable for completely revamping an airport and the environment around it. With that one program I can remove the original airport background file and create a new one. I can also create my own custom ground textures and apply them in any shape I want. You will see some of my work using these tools very soon. I can also create new shorelines, roads, rivers, etc as well as place objects, alter land class and create flatten files. So with that one program, I can design an airbase scenery completely from scratch if I wanted to.

Now why am I telling you this?? I mention this because while SBuilder is an incredibly powerful program, it is not user friendly IMO and takes a good bit of time before you get the hang of using it and can make it do what you want. I had the program on my computer for over a year before I finally got all the pieces connected to make it work.

So for most of our scenery creators, SBuilder is not really an option to learn to use because of its steep learning curve. One of the most useful features of SBuilder is the ability to alter the airport background as well as create just one single exclude file to cover everything that needs to be excluded. For nearly EVERY single AFCAD file that we create, we have to create excludes and a new background to fit with the look of the new AFCAD file.

Up until the release of AFX, there wasn't any other program to my knowledge that would let you alter the background poly AND create excludes all in one with the exception of SBuilder. So any time one of our package creators wanted to create an AFCAD file that needed a new background or a bunch of excludes, they had to ask myself or John Stinstrom to create these things using SBuilder for their package. While John and myself are more than happy to do this, this adds yet another step in the design process of that package and the package manager has to put the package on hold until we can make the required files.

Most of us here are pretty independent and don't like having to wait on files from someone else before we can continue building the package. That can be incredibly frustrating.

So AFX comes along and voila, it can do these magical things that before only SBuilder could do. It may not be perfect but for our package creators, they suddenly have control of their packages again and no longer have to request and wait on these files to be made for them by someone else.

When the French Mirage package was being tested, we realized that AFX will not play politely with AFCAD. As I recall we did have some discussion if we wanted to go forward with AFX files and the possible effects that mixing AFX and AF2 files would have on our packages. With all the benefits that AFX offered our package creators, it was really a "no brainer" to decide to stick with AFX and the files it produces. The benefits that it offers FAR outweigh any negative effects that it has.

With AFX our package creators have found an entire new sense of freedom and creative control over their work. They can now do entire packages on their own with no intervention from anyone else. The workload for everyone goes down and the number of packages we can create goes up. These are all good things.

While I understand that it is frustrating not to have the ability to alter the AFX based files without losing some of their features, the benefit of this program to what we do around here is means that it will continue to be a part of future MAIW packages until something better comes along.

John Stinstrom and I will probably continue to do things the hard way, like adding taxiway signs, using SBuilder which is an incredibly time consuming process. The smart guys around here will get a copy of AFX and do it themselves in about a tenth the time that it takes John S. or myself to do the same thing with SBuilder. That goes for altering the background, making excludes and accurately placing parking spots in relation to the scenery around them.

If I was just starting out in scenery design, no way in he!! would I try to learn SBuilder, AFX does nearly the same things in far less time. When it comes right down to it, it really is all about time. The more we can do in a less amount of time, the better and more likely that we are to continue doing it. Being a volunteer organization, if our contributors don't have the time to make the packages, they will not make them, plain and simple.

Having said all that, SBuilder works for me and I will continue using it in combination with AFCAD. But I am a dieing breed, of that I am sure.

I for one am grateful that AFX has come along. It has improved the overall quality of our packages and increased our package production by leaps and bounds.

Dan thanks for keeping this civil, I hope I have given you an idea of where we are coming from on this issue. And as always, thank you for your continued support even if we are not always doing things in a way that works best for you.

[fishlips]

Wow, what a debut.
As a scenery designer for Australia I use both afcad and AFX where required. It really depends on the task at hand as to how much work needs to go into the terrain, etc with excludes, flattens and taxiway signs and so on. A small country airport may not require anything other than a few models being placed where as a military base can be full-on work containing dozens of custom models, photo-real ground right down to realignment of runways, ILS, waypoints, GPS info, etc.

AFX is by far the easist tool to use when your trying to reduce your work load and have the scenery out the door so that the next project can be undertaken.

I think that Dan and Nick are essientally well in tune with this subject. With the money that most people save on recieving freeware packages, what's the big deal in splurging a few bucks on AFX payware if you are really that unhappy with your freeware scenery that you feel that you need to make changes to it. Usually if somebody points out an issue with my scenery I try to fix it. If they provide photo's to show the real thing, I am delighted.
If I have left out there favourite corner store, well, you know the answer to that.
In the end, we are not talking sheep stations here and most people spend more on hiring a months worth of movies.
Mark

[kungfuman]

Perhaps it may surprise you that I pretty much agree with the sentiment of all posters here, particularly in terms of where they are "coming from" with respect to their own individual approach to design, including the use of AFX. This is not something that I can fault in itself.

I think maybe one or two of you have had a suspicion that I could be playing the "wolf" in sheep's clothing. I can assure you that in fact I am more like a sheep, but in wolf's clothing. In other words, my original post may seem to suggest that I am hiding an underlying dissatisfaction with MAIW packages, but in fact it is merely an attempt to "plumb the depths" on what values the MAIW designers actually do hold, and in what sort of hierarchy - including with respect to the organisation as a whole. To this end, the explanations offered have been fascinating to me. Of particular note is MikeJG's last post. Thank you Mike!

And as a sheep, I am more than happy to continue following the flock!

Yes, I might have preferences. But my preferences may not be well informed. I remain flexible in my expectations. I also remain grateful to the designers whose work I deem worthy of critical analysis (flawed as my analysis may be).

BadpvtDan, I certainly do see the difference you refer to. My angle admittedly makes the assumption that making everyone happy is what makes you, the designer, happy. This assumption is flawed. In truth there must be a wide variety of different designer motives that need not coincide with maximising the prospective satisfaction of the end-user. This is all part of the nature of freeware, and I support it!

One final clarification: For me, this is not about money, it is simply about principles. Further, it is not for me to judge others on the principles they choose to adopt. All I intend is that whatever those principles are, they continue to serve the best interests of MAIW. By having this debate, I am reassured that this is the case.

Personally, I have no need for AFX, as I have "mad skillz" that suffice! My reference to AFX files is due to the problems that other users are unwittingly creating when they attempt to solve faults that the original designer has overlooked.

Thank you everyone

ps. I don't mean to sign off here. Keep your views coming....

[Greg]

I myself went to AFX because at one base for the Finnish Hornets package I had to create 25 exclude files to hide some trees that were overlapping from the default scenery. With AFX they are done in 1 file.

Ehm actually there is a way to combine all 25 excludes you made with Exclude Builder in one exclude file...

Here's how you combine the xml code, all you need is notepad:

Exclude 1:

Code: Select all

<?xml version="1.0"?>
<FSData
   version = "9.0"
   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xsi:noNamespaceSchemaLocation="bglcomp.xsd" >
   <ExclusionRectangle
        latitudeMinimum = "N55* 51.7810'"
        latitudeMaximum = "N55* 51.9632'"
        longitudeMinimum = "W4* 26.4711'"
        longitudeMaximum = "W4* 26.2230'"
       excludeAllObjects = "TRUE" />
</FSData>

Exclude 2:

Code: Select all

<?xml version="1.0"?>
<FSData
   version = "9.0"
   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xsi:noNamespaceSchemaLocation="bglcomp.xsd" >
   <ExclusionRectangle
        latitudeMinimum = "N55* 51.8550'"
        latitudeMaximum = "N55* 52.0598'"
        longitudeMinimum = "W4* 26.2115'"
        longitudeMaximum = "W4* 25.5875'"
       excludeAllObjects = "TRUE" />
</FSData>

Together:

Code: Select all

<?xml version="1.0"?>
<FSData
   version = "9.0"
   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xsi:noNamespaceSchemaLocation="bglcomp.xsd" >
   <ExclusionRectangle
        latitudeMinimum = "N55* 51.7810'"
        latitudeMaximum = "N55* 51.9632'"
        longitudeMinimum = "W4* 26.4711'"
        longitudeMaximum = "W4* 26.2230'"
       excludeAllObjects = "TRUE" />
   <ExclusionRectangle
        latitudeMinimum = "N55* 51.8550'"
        latitudeMaximum = "N55* 52.0598'"
        longitudeMinimum = "W4* 26.2115'"
        longitudeMaximum = "W4* 25.5875'"
       excludeAllObjects = "TRUE" />
</FSData>

So you only need to copy and paste the "ExclusionRectangle" part. Run the file through bglcomp and done, only one file!

Greg

[MIKE JG]

Which is exactly the way SBuilder handles those. Takes a bit of work to do it manually but it is easy enough.

[kungfuman]

That's exactly how I do it Greg. And XML code (in conjunction with bglcomp) makes pretty light work of taxiway signs, too.

Looking forward to ADE for FS9 though...