Board index Other Hangar talk

Help needed - market research for FG

Talk about (almost) anything, as long as it is no serious FlightGear talk and does not fit in the other subforums.
Forum rules
Please refrain from discussing politics.

Re: Help needed - market research for FG

Postby Hooray » Wed Nov 14, 2012 4:51 pm

Thorsten thanks for taking the time to write all this. I don't really disagree with your numbers (I would never dare to ;-) ). However, unlike Stuart, I was never thinking along the lines of having "commercial addons" (I really don't think that would work for us, for the reasons you mentioned) - rather having a partially funded development focus, without the developed features/products (aircraft/scenery) being necessarily sold at the end of the day.

Crowd-funding via kickstarter.com, sponsorships like GSoC or OSS funding via nlnet.nl provide significant funding to OSS projects without them turning into "commercial" mode at all. And it's not necessarily a continuous thing. So we could give it a try definitely.
I still agree with your earlier comments, I am also not easily motivated to work on something that I am not interested in myself, and that certainly wouldn't change for 500-1000 USD per month. I'd rather spend by spare time doing things that I enjoy and find interesting.

I do agree that we have some extremely talented teams of aircraft developers, with French and Russian contributors being the obvious example here.
Looking at the artwork the T4T guys create, I'd also imagine that they could be potential candidates for this.

I really don't see us going commercial, and I wouldn't want us to become commercial. But that doesn't mean that certain part of our development could be sponsored through external means. Ideally, based on polls among developers, contributors and end-users.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Help needed - market research for FG

Postby Bjoern » Fri Nov 16, 2012 2:39 pm

stuart wrote in Wed Nov 07, 2012 12:26 am:I'm currently looking at how we can market FG better, and in particular how we can "sell" it to FS-X users


Make it more user-friendly for a start.

Keep the wiki up-to-date and accessible (throw out old, irrelevant articles), drop support for anything but the current official release (GIT is an entirely different thing), use one single way to offer text-file based simulator configuration (much like FSX's fsx.cfg), ship an official, easy to understand, fully documented, UI for all OSs used (e.g. a combination of FGRun and TerraMaster), ditch broken/irrelevant old content from the sim, maybe offer an official repository with non-GPL add-ons to eliminate tedious file hunts, unify information to a single place, offer wiki-based tutorials, and I bet there's more that can be done.
Also, be honest about what you're selling.
If FG runs badly on, say my old ATI chip in a Linux environment or, the infamous Intel graphics chip, this should be put in red flashing text into the introductory article to avoid disappointment.

By easing transition, you might just get enough people to take an earnest look and maybe even get hold of some not only there for looking, but for making.



Regarding add-ons and money, the FG market is way too small to be able to support this.
And since MSFS, FG and X-Plane are basically three entirely dimensions, cross-developing add-ons will not work under any commercially feasible circumstance.
Offering (community-financed) bounties for kickstarting development of a new feature or aircraft or airport, however, just might work as long as an official guideline can be set for, e.g. detemrining if an add-on has been completed in a widely satisfactory way.


I might just post some more personal experiences later on.
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: Help needed - market research for FG

Postby Hooray » Fri Nov 16, 2012 4:44 pm

Thanks for posting that, it was definitely insightful!
I do disagree with your suggestion to only support the latest version. I think we can do far better by using wiki tagging for each release. This works for wikipedia, too - and we're using the same software. So why not use the same method? They also have "stable" versions of articles, and articles that still need to be reviewed. Like others mentioned previously, that shouldn't be hard to start. However, file uploading would need to be specifically dealt with - so that uploaded files can be version-specific, i.e. also "tagged". I'm not sure how WP deals with that.

Regarding the GUI, that will probably happen "automatically" during the next 2-3 releases, i.e. in the next 18 months - because of the consensus to adopt the Canvas system to replace FlightGear's GUI. That will mean, that we'll get a much more flexible GUI in FG, so that totally new and custom widgets can be used that are currently unsupported by PUI. In combination with the recent work on better subsystem initialization, we'll probably get an increasingly runtime-configurable simulator with a fairly modern GUI toolkit. So that external launchers like fgrun etc won't be needed most of the time.

Regarding preferences.xml vs. fsx.cfg I actually find our way more flexible and more powerful - we could still provide GUI tools to edit such things.
On the other hand, you are right that preferences.xml has become huge and bloated. So making changes isn't as easy as it should be.
A while ago I talked to Stuart about an idea to simplify this by splitting preferences.xml and moving each section into a separate file that would then be included from $FG_ROOT/Preferences:


Subject: Aircraft Rating System
Hooray wrote:As another example, have you recently had a look into $FG_ROOT/preferences.xml ?
That's another excellent example for a huge XML file that could be EASILY split into a number of separate XML files that could be simply referenced from the top level preferences.xml via an include directive, so that the defaults could be stored separately - i.e. in $FG_ROOT/Preferences or $FG_ROOT/Defaults

You would end up with separate XML files for all important setting:
  • $FG_ROOT/Preferences/startup.xml
  • $FG_ROOT/Preferences/rendering.xml
  • $FG_ROOT/Preferences/sound.xml
  • $FG_ROOT/Preferences/systems.xml
  • $FG_ROOT/Preferences/views.xml
  • $FG_ROOT/Preferences/multiplay.xml
  • $FG_ROOT/Preferences/terrasync.xml
  • $FG_ROOT/Preferences/controls.xml
  • $FG_ROOT/Preferences/instrumentation.xml
  • $FG_ROOT/Preferences/logging.xml
    and so on


It's not that the current technique would be bad, it's just that it isn't as intuitive and self-documenting as possible.

I don't know if you agree or disagree, but I can assure you that if you do disagree, then it's because you are also a long-time FlightGear user and developer with plenty of experience ;-)


I'm still convinced that this would go a long way to make customizations easier - and maintenance also, and Stuart actually seemed to agree:
Stuart wrote:(OT: I very much like your idea of providing a "template" aircraft, and also splitting up preferences.xml)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Help needed - market research for FG

Postby Bjoern » Fri Nov 16, 2012 6:24 pm

Hooray wrote in Fri Nov 16, 2012 4:44 pm:I do disagree with your suggestion to only support the latest version. I think we can do far better by using wiki tagging for each release. This works for wikipedia, too - and we're using the same software. So why not use the same method? They also have "stable" versions of articles, and articles that still need to be reviewed. Like others mentioned previously, that shouldn't be hard to start. However, file uploading would need to be specifically dealt with - so that uploaded files can be version-specific, i.e. also "tagged". I'm not sure how WP deals with that.


If you can do version specific articles, and more importantly, keep them updated, I wouldn't mind. Or have a subject-specific article and divide it into subsections dealing with different versions of FG.
In any case, however, having comprehensive articles dealing with the current version is quite important so that new users won't get lost.

Regarding the GUI, that will probably happen "automatically" during the next 2-3 releases, i.e. in the next 18 months - because of the consensus to adopt the Canvas system to replace FlightGear's GUI. That will mean, that we'll get a much more flexible GUI in FG, so that totally new and custom widgets can be used that are currently unsupported by PUI. In combination with the recent work on better subsystem initialization, we'll probably get an increasingly runtime-configurable simulator with a fairly modern GUI toolkit. So that external launchers like fgrun etc won't be needed most of the time.


That sounds good.
The dependancy on external launchers, and the variety of thereof (ech with its own strengths and weaknesses to boot) made getting into FG just that more complicated.

A while ago I talked to Stuart about an idea to simplify this by splitting preferences.xml and moving each section into a separate file that would then be included from $FG_ROOT/Preferences: [...][/quote]

That sounds quite good, my gripe with XML (not only in FG, MSFS also uses XML extensively for model animations, gauges and more), however, is readability.
The various tags clutter up the screen quite well, whereas in the fsx.cfg, all you have is lines like "aircraft_shadows = 1" which makes browsing the file much easier.

Then again, XML can be probably read out by Canvas much more easily.

I'm still convinced that this would go a long way to make customizations easier


Provided you also purge the command line arguments for the FG binary or at least make them concur with EVERYTHING in the XML, it will make things easier indeed.

There's a bit of confusion if you, e.g. want to enable Rembrandt and user A suggests editing the preferences.xml while user B posts commandline arguments.



//------------------------------------------------------------------------------------------------------------------------------------------------


So, now for the "personal experience" thing I've threatened to post before:

I'm a long-time MSFS user. I started with FS98, went away for a few years and came back in the later days of FS8 (2002) before upgrading to FS9 in 2003. In 2006, I've switched to FSX a month after release or so (courtesy of a new, then up-to-date PC).
Since FSX was quite temperamental in its RTM state, I've spent quite some time getting to know the inner workings, tweaking and generally trying to get the best performance out of it.
Fortunately, the two service packs, excellent tweaking guides and better hardware improved things so that the average user doesn't need to spend half his computer time trying to fix up FSX.

Around 2007, I got into actively developing stuff for FSX. While only scenery models at first, I soon turned to developing aircraft.
Considering the time required to pump out an elaborate aircraft model for FSX and the fact that I always try to spice them up with the odd special feature seldomly seen before, I haven't achieved much in five years.

One of the reasons for the general unproductivity of MSFS add-on developers (especially aircraft makers) is an inherent degree of openness in MSFS's architecture. While textures, scenery files (terrain data, object placement data), gauges (if they're in XML format), flight dynamics and sounds can be edited with the right public tools and without hassle, anything distributed in MSFS's .mdl format (scenery objects, aircraft) is basically off-limits to modification. There are tools that can read .mdl files, but can't export them without losing smoothing, materials and animations.
So any model in the libraries and on the market is there and if you, e.g. find a bug in it, you can't do anything about it. Unless, of course, the developer in posession of the source files releases an update.

This brings me to another deficit of the MSFS community: Inherent lack of a certain degree of openness. While this spirit is certainly great to establish a market for commercial add-ons, it kind of hinders advancement in a practical sense.
For improving upon a (freeware) aircraft or scenery model, you need to ask the original author for the GMax/3DS Max source file. Provided he/she supplied a still valid e-mail address and responds and fulfills your wish...
Otherwise, you're left to your own devices, meaning that you'll have to start all over again.
While this is certainly good for your modeling skills and has the odd chance that the new rendition of the aircraft in question is way better than the previous one, it's quite off-putting, considering that a good model takes a few hundred hours to be completed (if not more). Hence, I've started to at least make my model source files available on request or put the source files up along the real release.

In comes FG.
I really like the idea of an open source flight simulator. It basically has a "have a few hours to spare, do this or that, pusblish it, permit someone else build upon your work" spirit, which, in my eyes, greatly enhances productivity (if organized correctly).
I had been actively watching FG's development since version 1.9 or so, but it took storing my main PC and hence FSX (don't ask) to actually give it a try.
To be fair, I was a bit disappointed by the usability and performance aspects hinted at in my first post, but I really liked the idea of having a bleeding edge flight simulator with fancy new features being implemented every odd month. This also prompted me to make the GIT script for Linux.
In the end, however, the limitations made me drop FG for now.
I don't blame FG, considering the state of the Linux ATI drivers for my X1300, a small HDD and the fairly inflexible GIT system for the FGData part of the repo, but the impression that actual performance optimizations don't have a high priority for the core dev team was one other major point (no offense intended; this is FOSS after all and anyone can do whatever they want with it).
Stopping montoring FG's development entirely wasn't an option though, as I still feel that I can provide some input here and there (like right now). For now, I'm back on FS9 though as it is almost entirely CPU-dependant and thus runs quite well on laptops.

When life might just treat me right for a change and I can get back to my PC (and hence, way more powerful hardware than in my laptop), I might just spend more time with FG, if just for providing CPU time to generate chunks of terrain with a new (hopefully then official) compiler*.

Another thing I'd really love to do is providing ways of sharing resources between FG and MSFS, mostly for the AI system. MSFS has quite an abundance of add-ons for the AI department, even going as far as providing nearly convincing AI environments for every decade. I, for example, am turning my FS9 installation into a 1980s environment, in which you can fly your TWA or Pan Am or Eastern aircraft without feeling oddly out of place.

Now, if I model an AI aircraft using the texture layout of its MSFS equivalent, it would basically enable me to eliminate time spent on paining this model up in its various operators' colors. Other people would then just hunt down the repaints on the major MSFS download sites, install them, convert them and have them in FG. Nice and easy.
Another thing would be converting the flight plans for AI airlines (there's a script to do this already, right?) into FG's format to enable users to use the billions of MSFS flightplans out there.

And this is just one of the things I have in mind.

Another would be helping Durk with getting a working, thorough ATC system (voices et al; better than in MSFS) up and running.

AI has always been important to me and, although I keep my MSFS strictly civil, I like the concept of "Bombable" as it brings people willing to blow stuff up (and eventually developing the module further) into the fray.
The idea of an empty, static sim-world just doesn't turn me on.


Long story short; I'm willing to hop on board on a more intense basis, but just not now.


For kicks, the commercialist, "HD here, HD there", "I want 32983298329823 poly aircraft models with every system modeled" attitude becoming ever more prevalent in FSX has been disgusting me for quite a long time.
While developers publishing the n-th rendition of a P-51 with 4096²px textures and an actual modeled engine system and selling it for $50, I'm hard pressed to even get a "nice work" or third party repaint for my models. It just feels demotivating.
With FG, I get the impression that most of the time everyone just tinkers along in their favourite area, mass excitement is quite rare and, apart from lengthy discussions about new features, some slightly heated, some not, the whole community just seems more relaxed. Which is good.


* Speaking of, what about putting together an official SDK, containing (links to) export scripts, airport layout editors, terrain editors, etc...?
It would improve usability...
Last edited by Bjoern on Fri Nov 16, 2012 7:40 pm, edited 3 times in total.
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: Help needed - market research for FG

Postby Hooray » Fri Nov 16, 2012 6:29 pm

Bjoern wrote in Fri Nov 16, 2012 6:24 pm:There's a bit of confusion if you, e.g. want to enable Rembrandt and user A suggests editing the preferences.xml while user B posts commandline arguments.


Yes, that's another good point which is related to usability I guess.
There are several ways to accomplish something and sometimes they may be conflicting or invalidate each other.
For example, we still have a number of startup options that are not compatible with each other, or that may even crash the simulator during startup.
And some properties can only be affected at startup/boot time, while others can be changed at runtime.
For users this is a difficult concept - so that such things can be real roablocks obviously.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Help needed - market research for FG

Postby Bjoern » Fri Nov 16, 2012 7:41 pm

This was probably the longest post I have ever written apart from that AAR from IL-2. I need something to eat.



Hooray wrote in Fri Nov 16, 2012 6:29 pm:For users this is a difficult concept - so that such things can be real roablocks obviously.


Yes.

Before anything major is done, a "Ways to configure and start up FG" article at least mentioning everything you can do would be helpful to new users.
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: Help needed - market research for FG

Postby Hooray » Fri Nov 16, 2012 8:59 pm

Actually, I think "configuration & startup" are covered in the PDF manual?
Maybe we should try to find a way to integrate some of the more fundamental documentation directly in the simulator?
Just recently we have added a "documentation browser" which shows the README* files in $FG_ROOT/Docs
It would be fairly straightforward to add additional files or to use the same Nasal/XML code to show an introduction for users who are completely new to flight simulators
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Help needed - market research for FG

Postby Bjoern » Sat Nov 17, 2012 6:29 pm

Hooray wrote in Fri Nov 16, 2012 8:59 pm:Actually, I think "configuration & startup" are covered in the PDF manual?
Maybe we should try to find a way to integrate some of the more fundamental documentation directly in the simulator?
Just recently we have added a "documentation browser" which shows the README* files in $FG_ROOT/Docs
It would be fairly straightforward to add additional files or to use the same Nasal/XML code to show an introduction for users who are completely new to flight simulators


Well, once a canvas-based GUI is a reality, one could put in a step-by-step "set up a flight" menu, e.g.

1. Choose aircraft (model, fuel and pax load)
2. Choose airport (with dynamic search and listing options and options like "on runway", "parked", etc...)
3. Choose environment (weather, date and time)
4. Other options (input method, resulution, etc...)

And a checkbox for a "tutorial mode" right above or below the "Start Flight" button.

And then have simple pop-up boxes in-sim to walk users through start-up and a lap around the airport, both for a Cessna 172 and a jet for beginners.

The GUI would need to have the possibility for advanced configuration and informative tooltips for each option though.


MSFS does it the same way (and offering extensive "learn to fly" tutorials to boot, but I don't think they're very necessary in-sim).



Also, having never bothered to read the README*.txt files: What do they cover, how much info do the contain for the beginner in how many words (attention span!), are they really necessary for beginners?
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: Help needed - market research for FG

Postby Hooray » Sat Nov 17, 2012 6:54 pm

You are making some good points, but it's getting increasingly difficult to "filter" the thread to find the true gems ... maybe we should add a summary to the wiki? I don't know how exactly Stuart intended to deal with the feedback here, or if he already keeps notes somewhere? Otherwise, I'd suggest that we collect all ideas and move things to the wiki - or maybe even have a forum poll here to come up with a list of popular ideas first?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Help needed - market research for FG

Postby Bjoern » Sun Nov 18, 2012 8:48 pm

Hooray wrote in Sat Nov 17, 2012 6:54 pm:You are making some good points, but it's getting increasingly difficult to "filter" the thread to find the true gems ... maybe we should add a summary to the wiki? I don't know how exactly Stuart intended to deal with the feedback here, or if he already keeps notes somewhere? Otherwise, I'd suggest that we collect all ideas and move things to the wiki - or maybe even have a forum poll here to come up with a list of popular ideas first?


I think the wiki is a pretty good and open place for collecting everything that was said in this thread, but I would refrain from having a poll on it to determine popularity.

If someone really wants to set one or more of the points in motion, personal preference should be more important than popular opinion, i.e. no one should be forced to do something he/she can't or doesn't really want to do by peer pressure.
(I know this defies the very principle of community-based development, but in the end, we're all egoists, aren't we?)
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: Help needed - market research for FG

Postby Hooray » Sun Nov 18, 2012 9:21 pm

not disagreeing, but like Stuart and Thorsten mentioned earlier: those of us who are experienced FG users/contributors and especially developers, are in a bad position to come up with priorities as to what's important to make FG more appealing to end users, who don't have any FG experience ...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Help needed - market research for FG

Postby stuart » Mon Nov 19, 2012 2:20 pm

Hi Bjoern ,

Thanks very much for the feedback and your perspectivs. To summarize what I think you see as the main advantages of FG: fast release cycles with new function, open collaborative aircraft development. Correct?

Your first post raised some particular issues you see with FG. They aren't all what I was expecting, so I'd like to discuss them further:

1) "Keep the wiki up-to-date and accessible (throw out old, irrelevant articles)". Do you have any particular examples of articles that should be deprecated?

2) "drop support for anything but the current official release (GIT is an entirely different thing), " Not sure how we can drop support. Do you mean not mention in the wiki?

3) "use one single way to offer text-file based simulator configuration (much like FSX's fsx.cfg), " Hooray has already addressed this. It should be the case that most configuration can be set through preferences.xml. There are a couple of items that can't.

4) "ship an official, easy to understand, fully documented, UI for all OSs used (e.g. a combination of FGRun and TerraMaster)," FGRun is documented in the FG Manual. I don't think we ship any scenery management tool - perhaps that's something we should look into further.

5) "ditch broken/irrelevant old content from the sim, " Anything in particular? At the very least we can disable things in the GUI.

6) "maybe offer an official repository with non-GPL add-ons to eliminate tedious file hunts, unify information to a single place, " Excellent idea, and probably worth asking Curt about hosting on flightgear.org

7)"offer wiki-based tutorials," We have a series of tutorials in the FG Manual on flying aircraft. Or are you thinking about how to use particular features?

8) "Also, be honest about what you're selling. " That's a very good point. I'll need to think about how to phrase that sensibly in the release note.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Help needed - market research for FG

Postby Bjoern » Mon Nov 19, 2012 3:46 pm

stuart wrote in Mon Nov 19, 2012 2:20 pm:Thanks very much for the feedback and your perspectivs. To summarize what I think you see as the main advantages of FG: fast release cycles with new function, open collaborative aircraft development. Correct?


Basically yes, but it's not just limited to aircraft. If you know your way around the core stuff, you can participate in sim engine development as well. Or, as Thorsten does, improving shaders or the likes.


1) "Keep the wiki up-to-date and accessible (throw out old, irrelevant articles)". Do you have any particular examples of articles that should be deprecated?


A few months ago, e.g. the article on AI traffic was pretty useless, but it has been updated and clarified since.
Looking at it now, I think you guys cleaned up the wiki over the course of summer, right?

2) "drop support for anything but the current official release (GIT is an entirely different thing), " Not sure how we can drop support. Do you mean not mention in the wiki?


Yeah, and not focusing on active user support in the forums anymore. Or put them into a subforum specific to each major release (e.g. "2.6 support", "2.4 support", "<2.0 support").
Most users will upgrade to the newest version anyway, right?

Also, regarding GIT, back when I was still running FG, I noticed that the GIT contains the odd very old file which is most likely not needed anymore.
What about cleaning up the GIT after every major release to remove some unused files?

3) "use one single way to offer text-file based simulator configuration (much like FSX's fsx.cfg), " Hooray has already addressed this. It should be the case that most configuration can be set through preferences.xml. There are a couple of items that can't.


Well, it might be woth pointing out these items and noting them either in the preferences.xml, e.g. by including a "Set option x in file y/command line argument y" comment.
The best case, however, would be having EVERYTHING settable in .xml files.

4) "ship an official, easy to understand, fully documented, UI for all OSs used (e.g. a combination of FGRun and TerraMaster)," FGRun is documented in the FG Manual. I don't think we ship any scenery management tool - perhaps that's something we should look into further.


MSFS uses quite a different system, but the UI includes a "scenery library" which stores paths to add-on sceneries and lets you activate/deactivate every single one at will.

For FG, having something like TerraMasterin the "Scenery" tab for manual preloading of tiles would be very helpful, as TerraSync rarely, if ever woked for me.

5) "ditch broken/irrelevant old content from the sim, " Anything in particular? At the very least we can disable things in the GUI.


Well, the very old files I've seen in the GIT version (mentioned above) would be a prime example.

Also, you're only shipping fully compatible aircraft with the releases, right?

6) "maybe offer an official repository with non-GPL add-ons to eliminate tedious file hunts, unify information to a single place, " Excellent idea, and probably worth asking Curt about hosting on flightgear.org


Make sure to include a disclaimer about the licensing status of the repository content with a "LICENSE.txt" in the root folder of his add-on.
This could also settle a few licensing disputes I've seen here in the past.

7)"offer wiki-based tutorials," We have a series of tutorials in the FG Manual on flying aircraft. Or are you thinking about how to use particular features?


Move the tutorials from the .pdf to the wiki.
This would enable quick adaption to possible new features by the community and it would get rid of having a PDF reader open for reading up.
While certainly great for other uses, I find any PDF reader tedious to use for large, text based files. A wiki with its clear division into articles, cross-linking and a usable "search" function is much more usable.

8) "Also, be honest about what you're selling. " That's a very good point. I'll need to think about how to phrase that sensibly in the release note.


"We're not FSX, we're not X-Plane. We're FlightGear."

Or maybe someone will get this one:
"The only winning move is not to play."
;)
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: Help needed - market research for FG

Postby dbelcham » Mon Nov 19, 2012 10:45 pm

As someone relatively new to the community here are some of the things that I've seen as detrimental. Instead of focusing on the main simulator I'm going to talk about the rest of the community (add-on, scenery, aircraft, etc development). I think it's important to remember that while the main "user" does not look for these tools, they are the basis for what makes FG much more vibrant. Without the tools or the users you wouldn't have the France/LOWI/Italy/ect scenery. There would be no enhanced airports at Gatwick/Frankfurt Main/ect. There wouldn't be any beautiful sunrises or stunning planes to fly. Without the tooling none of these things would exist. But having tooling isn't enough, that tooling also needs to be readily accessible.

1) Where do you go to download the tooling you desire? 95% of the time you get one of two answers: get it from the Jenkins server, or compile from source. This is a massive difference from something like X-plane where they have a dedicated download page and nicely formed installations (either installers or easy to extract compressed files). The infrastructure seems to be available to do more. Jenkins is perfectly capable of creating release packages but the current crop of developers on those tools think that the tools themselves are more important than accessibility to them.

2) The core of FG seems to be developed in a methodical and thoughtful way. Development is conducted in isolation and then merged into the git trunk when it has been reviewed and approved. This means that the nightly builds are quite stable and rarely, if ever, end up in a non-functioning state. The developer tooling is not even remotely close to this. Take, for instance, the terragear stack that is currently under development. If you get the Jenkins build it probably won't work since all active development is being conducted in the trunk. The result (when combined with #1) is that there is no place to download a working version of the terragear stack. Now when one of those pesky FG users wants to build some custom scenery they can't get tools that work and this will likely turn them off pursuing what they were going to do. How often do you see this type of problem manifest itself with WED? Just because FG is open source development doesn't mean that it shouldn't have some oversight to protect the product and it's community from actions as crippling as this.

3) The barrier for entry into the addon/scenery/plane development area is excruciatingly high. Part of the problem is stale or lacking documentation. I'm a full-time professional developer. I hate documenting like everyone else, but I know that my OSS projects need it. I can't support those projects via phone, training, pair programming. Nobody here can support FG those ways either. It doesn't scale. At some point documentation is needed and at the current level of complexity in the development tooling area, that point has come and gone. I know that as part of a large OSS community project anyone can document, but who can efficiently document a newly created feature that they had no part in developing? Not too many people that I know. Those developing the tooling need to lead the documentation charge and others will join. But the current (all too common practice) of creating these (necessarily) complex tools and then blindly throwing them at the community is proving to be a barrier that is far too high for many people...especially those that aren't inclined to be programmers.

Overall I think the product (FG) is a good one. It has a high barrier to entry which is probably heavily influenced by a developer-centered mentality when creating features. While people's intentions are well meaning the actions and decisions that are taken can be crippling to the community. Technology won't solve many of these problems. Serious thought needs to be put into development practices as well as user experience. Simply changing fgrun to use Canvas isn't going to solve anything unless the UI created is built for newb's instead of programmers.

That all said, I think that a thread like this can help to identify and focus the user experience for the better. And, after all, the effort needs to start someplace.

--Edit--
I just wanted to state that this shouldn't be taken as complaints solely against the people working on the terragear stack. It just happens to be the most recent barrier I encountered and thus is the one I find easiest to remember and discuss.
dbelcham
 
Posts: 58
Joined: Thu Jun 07, 2012 4:55 pm

Re: Help needed - market research for FG

Postby Thorsten » Tue Nov 20, 2012 8:50 am

The barrier for entry into the addon/scenery/plane development area is excruciatingly high.


Given the rate at which new planes appear on the server, I don't think this is true for planes, although I have never done one myself.

As for addons, it depends what you mean, but Advanced Weather was initially developed as an addon - this could be done without ever touching the FG core, or any additional tool or indeed without compiling anything. So I would argue from my own experience that there is a vast range of addons that can be created at the simple expense of learning the scripting language and a few facts about the property tree - which in fact are documented.

As for scenery, without any prior knowledge of the particle system, I managed to create and place a waterfall into the scene in about two hours just based on the wiki documentation. There is no barrier I can think of in creating and submitting a 3d model - you use your favourite editor and submit it via the webform, end of story.

So, I don't think most of what you say here is true. There is one thing that is true, which is that the barrier for working on the terrain mesh is really high. As discussed elsewhere, there's a good reason for this, because even 1000 users working on terrain by hand would hardly be able to make a dent in the overall world scenery. The tools are developed to automatically convert geodata into scenery without much micro-management by a human operator, and that is what is needed. The custim France scenery is not an object lovingly created and edited by a group of users, neither is Italy - both are large-scale number-crunching applied to CORINE data. If you do it by hand, you get the size scale of the LOWI scenery - which is a nice piece of work, but pretty small as compared to France. So editing scenery by hand is something that is fairly irrelevant in the overall scheme of things, and hence not well supported.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Hangar talk

Who is online

Users browsing this forum: No registered users and 2 guests