How dangerous is Rembrandt in general?

[Jabberwocky]

Very very simple

fgfs --aircraft=747-8vvip --airport=(forgot where it was some remote place in Oregon, I think)
for the non-rembrandt

and obviously
fgfs --aircraft=KC-10A --airport=(forgot where it was some remote place in Oregon, I think) --enable-rembrandt
for the KC-10A and --aircraft=777-200LR for the test with the 777-200LR ...

random trees and buildings are swiotched off via rendering options in preferences.

[hvengel]

...I would bet that almost none of them know or care that their models cripple some users' computers. (I've been told repeatedly to get a better video card, but that's not an option for my iMac.) ..

I don't think this is really true. Most aircraft authors want their stuff to work for most everyone at least above a certain minimal hardware threshold and your Mac is above what I would consider an acceptable level for the hardware. I also think during the period when work is underway on a high detail model that the author may not be aware how much it impacts lower end hardware since they likely don't have any way to test it on a lower end machine.

In addition someone may work on such a model for many months before it is even far enough along that it can be integrated into the sim for testing. As an example I started work on the new P-51D exterior model almost a year ago and did my first flight with it only a few months ago. It had a minimal impact on frame rates compared to the old external model on my high end hardware (perhaps a 5% reduction) but users with lower end hardware are reporting frame rate hits in the 60% range but I didn't get these reports until the new models had been in git for several months. Because of those performance issues my next "project" is to optimize the 3D models and related stuff to try to get frame rates on these lower end system up to an acceptable level. I think with a lot of optimizing that I can get frame rates higher than before the new external models because the cockpit has lots of room for optimization in addition to the external models.

I also don't think that "As models get more numerous and more complex, this issue is not going away". As time goes by FG will get more efficient in how it renders things and it will handle these complex models better. In addition as time goes by hardware will get more capable. In 5 years mid range hardware will be comparable to current high end hardware and low end hardware will be as capable as current mid range hardware. Also I have only started looking into 3D optimization and I now know a lot more about how things should be done and I am sure that I will learn a lot more as I go through this process. The really complex models are a relatively new phenomenon in FG and many of these are much more complex than the P-51D and I am sure that the authors of the other complex models are also going through the same learning process and these models will gradually improve over time. The P-51D appears to run OK on current mid range hardware but it appears to overwhelm lower end/older hardware so an optimized version should be OK on fairly low end hardware. On the other hand there are some new aircraft out there that will only run on very high end hardware and I am sure that the authors are working to improve this.

It may seem uncaring that "I've been told repeatedly to get a better video card..." but I suspect that what you have been told is something more like "If you want to run aircraft xxxx then you need a more powerful GPU until such time that the resource issues on aircraft xxxx can be fixed" the answer then is to either get better hardware (I know not possible in your case because you are running a closed hardware platform that can't be upgraded - perhaps there is a lesson there as well) or don't run the aircraft in question.

On my hardware I see very few MP related performance issues and what I do see is very minor stuttering and this stuttering is just barely noticeable. Of course this is on really high end hardware (i7, GTX 770, 16 GB RAM and a 10,000 RPM disk) so with enough hardware the problems are minimal and in a few years this hardware will be considered mid range and a few years beyond that this will be considered old lower end hardware. I guess at that point it will be my turn to complain that things run like crap on my hardware. My point is that my last machine (before the i7 machine) was slower and less capable than your current hardware and now my machine is way more powerful than yours. It is a natural ongoing cycle and as time move forward all of us over time will get better hardware and we can't expect thing to stand still.

[Hooray]

I guess at that point it will be my turn to complain that things run like crap on my hardware. My point is that my last machine (before the i7 machine) was slower and less capable than your current hardware and now my machine is way more powerful than yours. It is a natural ongoing cycle and as time move forward all of us over time will get better hardware and we can't expect thing to stand still.

The other factor involved here is that FlightGear itself is improving - as could be recently seen on the devel list, FlightGear does have some fairly significant bugs and inefficiencies in various places - one of these bugs has now been tracked down by TorstenD, but other issues have been identified by others - over time, those issues will disappear and future versions will make better use of your CPU/GPU, even of your current hardware. The only problem is obviously that increasingly complex aircraft/scenery resources are added, so that these gains may not necessarily show up for all users.

But over all, FlightGear is supposed to become more efficient over time - all the threading/HLA work is exactly about improving frame rates and frame latencies, and identifying bottlenecks in general is a major part of this, no matter if it's CPU, RAM, VRAM or GPU utilization - we need to be able to track down problematic features and subsystems, but also problematic data resources, i.e. aircraft/scenery.

As long as we don't provide any means that enable non-developers to quantify their work against some sane baseline (even if that is just another aircraft), it is not fair to challenge aircraft developers to make better use of optimizations. FlightGear is very much evolving, and improvements in the rendering/main loop department are likely to have a fairly significant impact on performance as long as new futures are kept 100% optional at all times.

We've seen many users who reported that FG wouldn't make good use of their systems in terms of CPU/RAM and GPU/VRAM - but things are improving steadily, and while it may take a few more release cycles (read: years), FlightGear is getting better with each release. It is unfortunate that major bugs like the one that is currently being worked on by TorstenD went unnoticed for years, but the main problem here is lack of unit/regression testing, or at least some kind of "benchmarking" - i.e. via scripted/replay/route-manager flights, while keeping track of CPU/GPU and RAM/VRAM utilization in the process.

We know how to do this (and could even run such tests in some "headless" mode on the build server), it just isn't done for the time being.
Currently, we have a tendency to fix individual bugs (once they're identified that is) - but like ThorstenB's performance monitor and the built-in profiler have shown: the only thing that's required to allow non-developers to look behind the scenes is some kind of infrastructure that exposes certain internals and lets contributors compare performance with different startup/run-time profiles. Obviously, that is usually still a manual, and pretty tedious, process - once such things are automated FlightGear is likely to improve much more in terms of CPU/GPU utilization because non-developers can draw conclusions, and make better informed reports, without necessarily having to be core developers or proficient in C++, gdb/valgrind or AddressSanitizer.

This is one reason why all the work related to a providing an optional FGCanvas standalone "startup" mode is an important step: it will help establish and formalize subsystem/property-tree level dependencies among different features and better separate optional features, so that the main loop can be cleaned up over time. Equally, having a "headless" mode like the one that Zakalawe has been working towards, will allow people to do scripted regression tests without necessarily requiring a dedicated GPU or even a screen - i.e. invoked as a cron job.

FlightGear is only as good as the feedback that people provide via dedicated channels like the issue tracker - given the "degree" of feedback from end-users, it is not surprising that there are many bugs that cause inefficiencies (lack, stutter, segfaults,crashes) - so unless more people step forward to help with regression/RC testing, we need to automate the whole process so that we can quantify the performance impact of individual features (or even commits).

[KL-666]

I have heard about a year or maybe two about HLA. But i have no clue what it is and most of all, what is the status. Is it in 3.2 or not? If not for which version is it actually planned?

Kind regards, Vincent

[Jabberwocky]

Gijs, somewhere are two posts, one I wrote at the same moment as Hooray, the other one at the same moment when KL-66 wrote his ... I hope, they appear, because for now, they seem to be lost.

[Hooray]

I have heard about a year or maybe two about HLA. But i have no clue what it is and most of all, what is the status. Is it in 3.2 or not? If not for which version is it actually planned?

Ever heard about how the firefox/google chrome browsers are hoping to better leverage multicore systems by using a separate process for each website (tab) ?
That's basically in line with how FlightGear is going to work once HLA materializes a little more.

The main problem here is that most "legacy" software (like FlightGear) was originally written for a computer with a single processor (CPU).

These days however, it is common for a computer to have multiple processors, with each having multiple cores. Nowadays, it is hard to come across new computers that have <= 4 cores. Which basically means that there are 4 CPUs that can handle operations independently. Imagine it like having a car (or airplane!) with 4 engines, while the "driver" (you) only knows how to operate a single engine.

However, old software was written for a single processor, typically using a single main loop that assumes there's a single FAST processor. Which is why people would see better frame rates whenever they upgraded their CPU. This basically means that FlightGear would typically be CPU-bound (limited by the speed of the CPU, that is supposed to hand over jobs to the GPU).

Given the multicore revolution, what people have been doing typically is to use separate threads for certain, well-defined, tasks - such as running a dedicated thread for sound or for loading AI models.
In addition, OSG itself does have fairly extensive multithreading support as long as its coding patterns and protocols are used, so that OSG can internally decide which part of the job it can render asynchronously, on another core.

But otherwise, FlightGear's main loop still is built around the "single-CPU" concept, which is why there is a ton of stuff done in the main loop that could be done separately at some point, which would free up resources for better frame rates/latencies. The other issue with conventional threading is that threading is fairly low-level, it is very easy to write code that works ~80% of the time and crashes ~20% of the time (or vice versa). Processes are easier to understand than threads, and it is far more difficult to crash the main process - simply because a process doesn't typically have access to internal data structures. That is however also a problem because each FlightGear process needs a way to talk to the main process and invoke commands, get data etc - that is why some kind of inter-process communication is needed (IPC).

HLA is a fancy message-bus framework where each component (=called a "federate") can talk with other components across a bus called a REAL-TIME INFRASTRUCTURE (RTI) using an IPC framework that works across sockets and/or shared memory.

It's all explained at: http://wiki.flightgear.org/FlightGear_h ... re_support

In non-coding terms this means that FlightGear currently works such that FlightGear is a "single person" doing a well-defined job (which is HUGE, it's basically a list of 10000 things each frame) - for some tasks, there are "helpers" (=other people) that can help with certain tasks, such as doing sound processing for example - but usually, there's a single entity responsible for processing the main loop.

The "problem" is that modern computers provide a "team" of people and Flightgear in its current form doesn't really know how to leverage this "team" (of processors/cores) efficiently, so depending on your hardware, 60-70% of your CPU resources may be sitting "idle" - waiting for work that FlightGear doesn't know how to assign.

While there are some ways to add more team members to the existing FG "group", the next issue is that work needs to be coordinated, or the whole thing will "explode" sooner or later due to sheer chaos, because someone (on your team) is doing something that the other one is unaware of, which is a violation - and which triggers a segfault/crash, i.e. your operating system is watching your "team" of FG people/CPUs and once it sees that the "flightgear team" is doing something crazy, it simply kills the whole team because it didn't behave properly

Equally, the OS may decide to kill FG because it doesn't manage memory properly

So what core developers are working towards is looking at the existing FlightGear main loop, to come up with a list of things/tasks that can be done asynchronously, i.e. in parallel with other tasks - once that list is complete, people are looking at what each "team member" needs in terms of "data" and "functionality" - e.g. some team members may only need to access the sound systems, others need to access the property tree, the AI system, the FDM and so on.

The next thing is that core developers need to come up with a bunch of interfaces (so called APIs) that can be provided/used by each "team member" (task/federate). At that point, it's mainly a matter of wiring up each team member and letting them form a so called "federation" of workers. All of a sudden the main loop would become fairly lightweight and all the non-rendering tasks would be handled by "coworkers".

The added advanatge here is that there's a per-process memory limit, and there will be left more RAM for people on 32 bit OS because each process will have its own address space - equally, debugging/profiling and troubleshooting FlightGear will become easier because individual components can be tested, without having to fire up the whole thing.
Also, FlightGear is currently written primarily in C++ - once HLA/RTI is in place, future components could be developed using other languages, such as Python, Java or Ada for example.

(HLA is partially supported (as a multiplayer protocol substitute) already. But the way core developers are hoping to use HLA is to split up the simulator into a bunch of processes (think programs) that communicate with each other, to allow the main loop to be rendering only. That way, all the non-rendering tasks will be running on separate cores (threads/processes), while the main loop will only be doing rendering stuff, blazingly fast.)

[Buckaroo]

Jabberwocky,

It's hard to tell, but the screenshots kinda-sorta suggest artifacts from the objects used by "Rembrandt" to project point or cone light effects on the environment.

Using the DC-10 from the FG 3.0 download page with no "Rembrandt" enabled and all DC-10 lights on, I couldn't reproduce this effect in any environmental lighting condition, but that means nothing, given differences in graphics, hardware, FG version, etc.

I was under the impression that objects associated with "Rembrandt" point/cone light types don't render when "Rembrandt" is disabled. But if the artifacts you're seeing are the result of these lighting objects, then it suggests you are right: in some conditions "Rembrandt" techniques can introduce visual artifacts in non-"Rembrandt" situations. But I'm just guessing based on what I'm seeing, and am probably wildly wrong on this one.

Hopefully someone who actually knows something about "Rembrandt" (which ain't me) can shed some, um, light on the situation.

-Buck

[Jabberwocky]

Basically, what I suggested in the lost posts was something like

<condition>
Rembrandt
<lights>
use Rembrandt lights
</lights>
</condition>
<condition>
No Rembrandt
<lights>
Use very normal old lights
</lights>
</condition>

As you see, it needs some work, it is not mellowed yet. And someone who knows the parser/interpreter for the xml, may can tell how much work it would be to implement something like this. But, and especailly if we can expand this condition mechanism forther into all kinds of animations and model file loading, we have a solution for the multi-model planes and for Rembrandt and the plane developers can control what they do if there is Rembrandt or not, if there are multpile models ... or not ... seems to me the most elegant way.

[someguy]

It may seem uncaring that "I've been told repeatedly to get a better video card..." but I suspect that what you have been told is something more like "If you want to run aircraft xxxx then you need a more powerful GPU until such time that the resource issues on aircraft xxxx can be fixed"

Here's what I was told most recently: "For FG to run at higher frame rates you need a video card with at least 1G of VRAM for most aircraft and some need even more to not have issues. On the GPU end a mid range nvidia (IE. GT 730 - around $70 on-line - or GT 740 - around $90 on-line) should give good frames rates (30 FPS or better) with some adjustments to the rendering options on all but the most resource hungry aircraft without braking the bank."

Wanna guess who wrote that, Hal?

[Johan G]

...the screenshots kinda-sorta suggest artifacts from the objects used by "Rembrandt" to project point or cone light effects on the environment.

Some Rembrandt aircraft have "airbag" landing lights etc visible when Rembrandt is not running. In particular with pre-Rembrandt versions of FlightGear they would be very annoying and more or less make some aircraft unusable. Seeing the screenshots it does not at all seem impossible that some of these objects (light volumes?) are somehow the cause of the problems. I am very much not read in on Rembrandt though.


@Hooray: That was a pretty good writeup about HLA, but in particular this one single sentence sums up what took me days to figure out* (and I am still not sure I got it):

HLA is a fancy message-bus framework where each component (=called a "federate") can talk with other components across a bus called a REAL-TIME INFRASTRUCTURE (RTI) using an IPC framework that works across sockets and/or shared memory.

* At the other hand I was trying to wrap my head around the basic concepts of HLA reading the specs alone and possibly a couple of PDF:ed slide shows. No way to play around with it either. This must have been back in the mid or late 1990:s during secondary school ("gymnasium" here in Sweden). Lets just say it was waaay over my head.

[hvengel]

With the current scenery a 1G video card is close to the minimum to run at higher frame rates with any aircraft even very low poly aircraft. So this is NOT an aircraft issue but a general issue with the resource requirements of recent versions of FG scenery. 1G video cards have been available for nearly a decade and are very common and just about the minimum for any after market video card other than very low end cards. Many of the newer mid and high end cards have 4G of VRAM.

Depending on your imac age/configuration you could have a GPU up to a 4G nvidia GTX 780 or you could have a GPU that is much less capable like a Radeon HD 2600XT 256MB. The high end GPU should run FG nicely with any aircraft (although is may slow down with some aircraft) but the HD 2600XT will be in over it's head no matter what aircraft you select. I didn't select your imac configuration so I have no idea what GPU it has. But if it has an HD 2600XT it is way less capable than a $70 GT 730 card.

I found a thread about imac video card upgrades (the OP wanted to upgrade from a GTX 680 to a GTX 780) and the thread had comments on running X-Plane 10.0 that claimed that if you were running any add ins that you needed at least a 4G video card and that the best option was an imac with the 4G GTX 780 GPU. The posts in that thread also said that even with no add ins that you needs 2G of VRAM to run x-pane 10.0. So FG VRAM requirements are not out of line with other flight sims.

From my reading it appears that there is no way to upgrade your video card without buying a new machine. Bummer. Perhaps you should be taking this up with your hardware vendor rather than the FG devs or aircraft authors?

For those with fairly recent open hardware platforms (IE. PC class hardware less than 5 years old) a $70 to $110 video card upgrade will have FG running very nicely with all but the most resource heavy aircraft. I have a coworker/friend who was running FG on a mac pro who was also running into issues with it's lower end graphics card even running fairly basic aircraft. He wanted to upgrade the card with a new mid range NVidia card. Even though the mac pro uses standard slots it's PCIE 16X slot was a 1.0 slot and video cards are generally not available for this old standard for reasonable prices. The current PCIE standard is 3.0 and most newer video cards are only available for PCIE 2.0 or 3.0 buses. Since he wanted a higher end graphics card he ended up deciding that he could buy a complete standard commodity PC and slap in a higher end graphics card for less that getting a comparable video card for the Mac Pro. Seems to be a common theme regarding Mac video card upgradability and the new Mac Pro is even worse in this regard than the older mac pro being more like the imac in that you are stuck with what ever video GPU you purchase with the machine.

These are issues with how this hardware is manufactured and marketed and not with FlightGear. I am sorry that you bought expensive hardware that is not upgradable but that is not my fault or the fault of the FG developers. I also don't think it is your fault either since at the time you purchased the hardware you probably had no idea that this issue existed. As such I think that Apple is at least partly to blame since they don't make it clear to their customers that the hardware has limited upgradability and many Mac purchasers are not well enough informed to know about this issue or to understand it's implications at the time they make the purchase. Unfortunately you are the one that has to live with the consequences.

[Jabberwocky]

Lets translate this hvengel: Since the cards are available and you have it, we do nothing about the problem even it appears to be relative easy solvable? The problem is, since FG is free and less resource hungry than other sims, it has become somewhat home also for those who have no budget special for a game machine or who live in countries where you don't get a 730 for $90 but rather $300 only. Try to buy graphic cards on other continents and you will wonder ...
But well, as other posters explained to me, users are anyway not wanted since they don't contribute ... so maybe, this is just a new form of Open Source Darwinism and as such political correct?
But now seriously, FG exists in this niche with the poor, the borke and those who live without access to excellent internet connections and cheap hardware. Which means, FG better gets adapted to this or it may falls one day victim to above mentioned Open Source Darwinism and I can't imagine this is what anyone wants.

[Johan G]

@Jabberwocky: Relax a bit, a few post up he wrote:

...I started work on the new P-51D exterior model almost a year ago and did my first flight with it only a few months ago. It had a minimal impact on frame rates compared to the old external model on my high end hardware (perhaps a 5% reduction) but users with lower end hardware are reporting frame rate hits in the 60% range but I didn't get these reports until the new models had been in git for several months. Because of those performance issues my next "project" is to optimize the 3D models and related stuff to try to get frame rates on these lower end system up to an acceptable level. I think with a lot of optimizing that I can get frame rates higher than before the new external models because the cockpit has lots of room for optimization in addition to the external models.

[hvengel]

No one said the problem is easy to solve (where did you get that?) and I don't understand why you would think this is the case. Hooray just wrote a long post about the work that is underway on HLA, this work started several years ago - IE. complex not simple, although this may not help much with very old (single CPU) hardware. I also posted that I was actively working on optimizing my own work on the P-51D to make it run better on lower end hardware and that I thought that this was probably true for others working on high resource aircraft. Again I pointed out that the current round of work on my aircraft was started almost a year ago (I averaged close to 20 hours per week since that time) and that lots remained to be done - again complex not simple. All of this is complex and multifaceted and requires a lot of effort by a wide range of contributors. In the end no matter how optimized all of this gets there will be some minimal hardware requirements. What ever those requirements are I don't have control over what the needed hardware will cost in other locations (or any location for that matter).

This type of retort (nobody cares about users...) is becoming all too common here and is without any factual basis. In addition, it only causes those who actively contribute to reconsider why they are doing this work. Basing your posts on incorrect assumptions and as a result of these assumptions casting aspersions on others is never a good thing.

We are dealing with complex systems and users who have a wide range of requirements that are conflicting. Some users insist that everything should work on 10 year old low end hardware and other users want a high fidelity simulation that leverages their new high end hardware and then there's everyone in between. There is no way to make everyone totally happy. So we end up with a compromise of sorts. Those with high end hardware get a few aircraft that actually take advantage of their hardware and those with lower end hardware can turn down the eye candy (to what ever level their hardware will support) and use the lower poly less feature heavy aircraft. There are a few aircraft that require high end hardware and lots of them that don't. So things are currently weighted toward lower end systems. In addition, older versions of FG and FG aircraft are available that will run nicely on fairly old low capability hardware if you can't afford to get hardware that is at least minimally capable of running current FG versions. Why is that so hard to understand?

Now I get it that for some people upgrades are expensive. The imac person for example has this issue no matter where he is located. I'm not sure why a GT 730 would cost $300 in some locations other than heavy taxation. If that is the case then this is a political issue that you need to take up with your government(s) but this is not a political forum so that is all I will say about that.

Also the more you contribute the more influence you have over the direction of the project. This is basic "Open Source 101". That is how it is on every open source project I have worked on and it is no different here. If you are not contributing you have virtually no influence and if you don't contribute and make lots of demands you will have even less influence. People who are "just users" are basically free riders. Those who are doing the work don't mind the free riders but you shouldn't expect contributors to bend to the wishes of free riders. Free riders are not unwelcome but they are dead weight and the less constructive their comments the heaver they are. Again just the way it is. So as just end users being constructive and pleasant matter. The old saying "You catch more flies with honey than with vinegar" definitely applies here.

[Hooray]

@JW: I'd suggest to calm down a bit - according to your profile you registered roughly 6 months ago, meawhile you have made about 900 postings here - i.e. you average about 150 postings per month, which is more than most of us ... so you could, and should, certainly consider yourself a "contributor" meanwhile - especially given the nature of the majority of your postings in the support forum.

You cannot try to change politics that aren't there - the very instant someone gives you commit/wiki/forum access, you'd be considered "a part of the project" by others, even though nothing would have changed for you, would it ? Still, people would be yelling at ya, just because your nick name is suddenly shown in green and your workload is increasing each day due to having to help with the wiki, moderate the forum or review merge requests.

Like hvengel just said: there's no concentrated effort to lock out anybody at all - but obviously those who do something are motivated by their own goals and ideas - and it takes a of time and energy to convince those people to adjust their plans.

For example, yesterday you said that you were interested in exploring creating a Canvas-based GUI menubar - your priorities seem to be learning more about Nasal, Canvas:
Subject: Just a little thing in the menu - ruler

Ready to do this, but only in a week because real life is atm a bit busy.

Let's assume you can work through the pointers we've posted, and maybe even understand the code that we added to the wiki - and that you're making good progress with your menubar, it's already much better than the original menubar, and you're pretty satisfied with the result, recognizing that Nasal/Canvas isn't even very difficult

So, just imagine for a second that a number of users would show up and tell ya that your future menubar is locking out certain users because it requires technology that is unavailable in 1990s-era hardware (aka FBOs) - or imagine people who would tell ya to stop working on "supporting rulers", and instead focus on making the whole menubar 100% style-able using custom themes, colors and symbols sets.
While another 30+ users would show up and point out that the existing menubar doesn't support localization at all, and that your new menubar should definitely support translations natively and may need to be redesigned accordingly.

Some of the "Nasal experts" around here could then show up and dissect your "Nasal rookie" code and turn the whole thing into an unreadable piece of code that you no longer understand, which is something happening pretty often around here once someone shows up with a piece of code that isn't quite production-ready yet.

And then Canvas experts, like TheTom, might suggest that the code should be completely rewritten from scratch because it doesn't make proper use of the new widget/styling framework.

At the end of the day, your decisions don't depend on who's right or who's wrong, they don't even depend on who's "nice" - they depend on who's going to support you, or who has got a track record fo finishing something. While you may realize that you're disappointing a number of users, you also realize that -for the project to finish- you need more people involved, and you need to be willing to adjust your own priorities according to theirs - especially "power contributors" who bring skills to the table that you don't possess (yet.

This is one of the key conclusions that people fail to draw all the time - but in order to run, you need to be able to work, and even something imperfect is better than nothing at all, even "perfect ideas"
Some of our contributors have brought massive features to FG, and those tend to attract all kinds of people - but ultimately, people who roll up their own sleeves matter more than those who don't - and I challenge you that you will be working exactly the same way once you have your own stakes involved - i.e. spare time, skills etc

Nobody wants to exclude anybody - obviously, any users is a potential contributor - however, it does make a huge difference if a contributor sees his time wasted, or put to good use, i.e. by "mentoring" someone who's then able to apply some skills independently, and maybe even spread knowledge through tutorials or wiki articles.

FlightGear doesn't need users, but users need an active community that supports them - thus, having people -like you- involved in the forum helping others is a good thing, because it allows others to focus on "more interesting" aspects (like coding). However, the degree of end-user support that end-users tend to provide typically also doesn't scale too well usually - simply because it's 1:1 support, i.e "hit or fail" - once a certain key contributor/supporter disappears for a while, this becomes more and more obvious - which is why identifying problems and creating wiki articles scales much better - the few people who do that, recognize that no matter their degree of involvement (or lack thereof), such wiki articles will remain being "useful" for much longer than any specific postings made on the forum.

But please stop drawing the line between contributors and users - you are obviously contributing, and you're hoping to contribute to other areas, so there's no need to make that distinction.
As you will see over time, concrete skills and features are much more valuable than any lengthy discussions.

And please keep in mind that the majority of people discussing such things on the forum are really preaching to the choir: you all "want to be heard" - especially by people who can "bring" your suggested changes to FlightGear - without realizing that only a tiny fraction of core developers is actually involved in the forum regularly. Thus, what people are really doing is preaching to others who've been in the exact same position before, who just appear to be more "senior" due to a certain track record (or number of postings).

But no matter how good your ideas may be, you are unlikely to see them implemented by discussing them on the forum - I am not saying that I like this fact, but it's a fact - and you should be aware of it, or you are wasting people's time.

PS: the 10 minutes it took to write all this could have been just as well spent supporting Jabberwocky's menubar effort and adding more code snippets to the wiki: http://wiki.flightgear.org/Howto:Making ... as_Menubar

Ultimately, we gotta decide how to best spend our spare time - and we really like the idea of our time being "multiplied" by helping others who can apply knowledge, i.e. other contributors - which is why people like Thorsten tend to get pretty good 1:1 support, while a few others don't get much support at all - despite their ideas not being any worse at all.