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...