Ideas for a new scenery design tool

[scruffyduck]

Jose

You have a point - maybe we are talking about two tools after all - somethings which the 'home towner's' can use which is simple and intuitive and which has the protection needed to stop them from messing about with things that can screw up Navigation and approach data and SDSX. I suspect that there would be a fair number of re-usable components in the two.

I to agree that part of AFCADs success is due to the simple interface. If there were two tools in the family then it might stop people asking for enhancements to the 'home town' tool which would take it into dangerous territory since that stuff would be in the 'professional' tool

Just a thought

 

[lmoelleb]

We can easily see if we need a more basic view/controls once we have a more complete GUI. As we have no idea how the GUI will work, or how advanced it will be at this stage, I would not spend any time guessing how it should be done. Let's do this agile instead of making yet another waterfall disaster project.

It would take a lot to convince me two tools where needed, but this might be due to the fact that I am more familier with the MVP approach, and simply see your "new tool" as another view - possible with a presenter change as well, but no data model change at all.

Anyway, a modern GUI should simply inform about consequences and tell people what they need to learn in order to do what they desire to do.

 

[jcboliveira]

Personally I believe that there are 2 questions that should be asked:

What is the target audience?
How many programmers do we think that we want to involve?

I believe that the numbers will decrease with complexity. That’s why I start to see two tools with re usable components.

José

 

[scruffyduck]

Personally I believe that there are 2 questions that should be asked:

What is the target audience?
How many programmers do we think that we want to involve?

I believe that the numbers will decrease with complexity. That’s why I start to see two tools with re usable components.

José

I think there may be several potential target audiences actually:

1. Casual Home Towner's who want to enhance their local airfields with more accurate parking etc
2. AI traffic guys who want to do the same thing but in a more complex way taking account of more things
3. Scenery Designers who are mostly concerned about enhancing the look of airports and so on

I think there is a split somewhere between 'home towners' and 'professionals' as well as between AI developers and Scenery Developers. Some I am sure will be into both AI and Scenery Design at the same time. My experience with SBuilder is that people use the bits they want to use but I know some are put off by the apparent range and complexity of the options on offer.

However we do it I really want to make sure we cater for the home Towner'sTowner's as well as the professionals

 

[lmoelleb]

Personally I believe that there are 2 questions that should be asked:

What is the target audience?

Scenery designers
There is a floating transision to the various parts, so only making the program for some people does not make sense. I have not seen a single argument that suggest two tools are needed. I have seen arguments suggestion we should have validations in place to check if people are destroying things they do not understand, and maybe arguments that we should be able to adjust the GUI to the level of the user.

How many programmers do we think that we want to involve?

Anyone who can actually contribute. This is a bit of a problem in the start, but once we are running creating 3D model transformations, new background renderer etc is a pretty easy task, so if someone can add a feature, let them. But we do have to wait "letting people loose" until there is a basic infrastructure for them to work from, which might have to be created by 2-3 people max. But things like Arno's MDL decompiler can obviously be done without the infrastructure is ready (that is one of the things Unit Testing can do) - similar with background renderers etc, so this can be done independently, then refactored into the infrastructure code.

I believe that the numbers will decrease with complexity.

I do not agree. If I was not aware how the Smart Client Factory worked I might have agreed

That’s why I start to see two tools with re usable components.

José

Why not just load different components into the same tool?

 

[rfields]

I'm not sure multiple tools would be the way to go, maybe multiple modules.

There is no way to stop people from experimenting and most of us learn more from mistakes than from doing things right the first time.

What I would like to see is a tool which would not allow some of the grossest errors to be created / compounded.

Things such as putting location specific items like buildings in the same file as an airport header with runways, taxiways and parking.

Jim knows more details than I do, but I can quickly see three or four catagories of files into which the BGLComp SDK elements should be saved.

In some cases, approaches for example - the file needs to be in a different folder (Generic\Scenery in FS2004 - Global\Scenery in FSX) than the parking data.

In some cases, excludes along with generic buildings and scenery objects, even though we mentally associate them with a specific airport - they do not belong under the airport header.

I also assume you are interested in modifying things like the airport background polygon, landclass around the airport, water class around the airport, mesh, etc. Those are going to involve different SDK's and certainly different files located in different folders.

 

[rfields]

Here is an example of a typical issue which will arise - literally the day FSX is released.

Airport - CYHZ
Default Runways - 6/24 - 8796 ft & 15/33 - 7697 ft

Issue - Runways have changed designators and are now Rwy 5/23 and Rwy 14/32

AFCAD Type Change:
1. Change Base End designator of Rwy 6 to Rwy 5
2. Change Base End designator of Rwy 15 to Rwy 14

Warnings which should occur when trying to save - or from a fault finder (would it be a good idea to force an error checking routine upon save?):
1. Start location numbers do not match runway numbers
2. Runway link line designation does not match runway designation
3. Taxiway signs do not match runway designations
4. Localizer for Rwy 15 & Rwy 24 to not match runway designation
5. Approaches do not match runway designations.

This will be a fairly simple one - it's even somewhat simple to do with NewBGL Analyze - as long as the indent codes for the localizers have not changed.

But two files are required - one which will be a traditional AFCAD and one which will include the newly renumbered approaches.

In FS2004 we were forced to put taxiway signs in the approach file - though they properly belong in the AFCAD file - because the AFCAD program decompile/recompile process would destroy the data.

(PS - I'm not at my computer with the FSX Beta - so I can't tell you if this airport has been redesignated or not - but I'm certain there will be some airports worldwide with this issue)

 

[arno]

This is an interesting discussion and I am not quite sure yet which direction I prefer. On one hand we want to make one tool for all our scenery design needs, so that we no longer have to use a dozen different tools. But on the other hand such a tool would be great for scenery designers, but might scare away the user who just wants to add one additional parking spot. So I think it is a very good point that we discuss our target audience. If we want not to scare those last group of users, the interface should be very easy to use and hide of lot of the technical details that a scenery designers wants to see.

For the BGL creation I think we have to accept that AFCAD will be used and therefore that we have to split things in different BGL files. If nobody would use AFCAD anymore in FsX we could use the technically perfect solution, but that is simply not possible. So we must use a structure here, that will not be destroyed when people try to use AFCAD on it.

 

[nickw]

How about a "lite" version... maybe the wrong word... but you get what I mean.

Essentially, a version that hides the advanced options.

Either that, or you are going to need two programs, but compiled from the same code in some way.

 

[lmoelleb]

How about a "lite" version... maybe the wrong word... but you get what I mean.

Essentially, a version that hides the advanced options.

As already mentioned the other times this was brought up, a "simple" command to move a gate might appear "advanced" for someone using the tool to draw a road. "simple" and "advanced" are only valid within the context of the task the user is trying to perform. Hence the program most likely would require to take this into account.

Let's refactor the GUI to be task oriented (or lite version, or whatever) once we have a tool that can perform at least one task , and we can get a feel on how it works. We have no idea how the GUI will end up looking, hence we can not design how it should be devided into tasks. I smell a bit too much waterfall sneaking in.

Either that, or you are going to need two programs, but compiled from the same code in some way.

If we go down this road we simply make different GUI modules. We might have two installer projects (each picking it's GUI module), but that would be the only difference if we deside to make too versions. The module beeing loaded is controlled by a simple XML file.

 

[tgibson]

Hi,

I fail to see why you need two tools. First, AFCAD cannot read FSX BGL files. So if you use that format for your output BGL's you do not have to worry about AFCAD.

Second, if you have extensive cross checking between elements (as Reggie above and Jim further above have elaborated), then a single tool will be fine for all users.

I would go even further in this checking, and if the user decides to change a runway designation, a box should pop up and ask "If you change this Runway Designation, you will need to change the relevant Approach data as well". Then have three buttons: 1: OK 2: Change the Approach Data to Match my Changes 3: Cancel

If this kind of thing is in there, I don't see the need for a "simple" tool.

Hope this helps,

Tom Gibson

 

[jcboliveira]

I'm convinced, there is no need for 2 tools. If we think that we shouldn't scare the casual user, there is allways the chance of restrict the tool to the essentials with an option.

José

 

[arno]

I think one tool should indeed be enough. As long as we keep the different kind of users that will use it in mind.

First, AFCAD cannot read FSX BGL files. So if you use that format for your output BGL's you do not have to worry about AFCAD.

We need to be really sure about that. I think I read somewhere that people copied the BGL files to Fs2004 and that it sort of worked then. Guess I need to check that.

I would go even further in this checking, and if the user decides to change a runway designation, a box should pop up and ask "If you change this Runway Designation, you will need to change the relevant Approach data as well". Then have three buttons: 1: OK 2: Change the Approach Data to Match my Changes 3: Cancel

Yes, such an interactive help system is a very good idea. It will also be nice as people don't read manuals that often . But please don't make it popup boxes that you have to click away, as they are annoying. I prefer some sort of task (todo) list that such items are added to.

 

[jcboliveira]

I prefer some sort of task (todo) list that such items are added to.

Maybe a wizard?

José

 

[bpahe]

Hi!

Just my 2 cents - one tool will suffice, as long as you have the proper documentation for it. I think the main reason to why people are reluctant to use SBuilder (I love it, though) is the somewhat non-linear process of its use, and the fact that the manual requires some basic knowledge from the various SDKs or prior work with scenery design.
Two interfaces (basic/advanced) is a good idea, but a good step-by-step tutorial will perhaps be even better (I just love the FS2002 instruction on how to build a house in the Gmax SDK. I learned all I needed to build my first airport from that).

I´d be happy to beta-test once you get that far. I have, however, no knowledge of programming.

/hans

 

[scruffyduck]

Thanks Guys

Well I think the consensus is for one tool, potentially with different user modes, but one tool


Hans I happen to think that documentation is very important and makes the difference between a good tool being used and not.

It is one of the things I find frustrating about many of the open source projects - documentation is poor.

For one, if the programming gets beyond my limited skills , I would be happy to do the documentation and tutorial videos.

 

[tgibson]

Hi,

AFCAD files will be read by FSX, and some of it will display (it was variable in the demos and betas, so will have to wait for the release version for the final determination). But as long as users can't edit either the default FSX files nor the SDSX files using AFCAD, then all should be OK. If they start adding FS2004 AFCAD files to FSX without knowing what they are doing, then they will have problems. But this is not a problem for SDSX - it's a problem for that user.

Take care,

 

[scruffyduck]

You make a good point Tom, at some point it is up to the user. We are not their keepers. I guess there is an issue if their work is published and made available to others and causes problems but again we need to go back to the old principle of 'caveat emptor'

 

[danchircop]

Hi everyone,
I think that Fs Architect meets most of the ideas mentioned here. I have been using Fs Architect for quite some time and I have always found it quite easy to use. Besides, it's updated quite often in order to meet the latest development introduced by Microsoft.
It has the ability to compile xml library objects. You can also create a line in order to apply a row of repetitve xml objects.
In the latest build, Doug (the developer) has also included the function to create LWM/VTP polygons.
It also has the abilty to accept plug-ins, one of them being to create mesh terrain. Momentarily I think the mesh terrain plug-in needs some updating but the thing is that something is there already.
The GUI is also excellent, and I think given the chance Fs Architect could be quite a powerful tool for scenery design.
I think guru's like Arno should try and contact Doug and see if something can be done and create the ultimate scenery design tool.

Regards
Daniel

 

[lmoelleb]

Hi everyone,
I think that Fs Architect meets most of the ideas mentioned here.

...

For me, payware is simply out of the question. I am trying to drag more people into scenery design (can't make the entire country on my own), and if people need payware to try to make a small model or airport, then I can as well give up on that. it is also difficult to do team development on a payware project (at least if you want people to be able to join later on), as it would end up with discussions on spltting up the money afterwards.