Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?- what FlightGear version do you use?- what graphics card do you have?- does the problem occur with any aircraft, at any airport?- is there any output printed to the console (black window)?- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

If you can compile FlightGear from source, grab the latest version - the fix was backported to the release/3.4.0 branch - and compile the program again.

If not, you can use the old FlightGear 3.2, get a (potentially unstable!) nightly build from the build server or wait for the next release - there was some talk on the development mailing list about publishing a 3.4.1 bugfix package to address this problem, but, as I'm not heavily involved in core development, I can not guarantee it will be released.

jsb wrote in Wed Feb 25, 2015 11:08 pm:I believe the community would highly appreciate an official bugfix release for this important feature - preferrably far far below the 1GB size of a normal release.

It was caused by a last minute decision to add a memory-saving patch to the release which broke the lights, followed by an oversight in which the patch to fix this went to next only. In essence, an attempt to do something good...

I understand there is a bugfix release in the making, fixing the light as well as unusual memory usage of the route manager.

In general, my impression is that there's a trend in the community not to use the release candidates to test and report in the expectation that the release will then by (magically?) bug free, so once the release comes out effectively many bugs which should have been caught by release candidate testing are reported, which prompts the need for a minor version release. The light bug mentioned above is rather exceptional in that respect.

It's true, as a user community we don't seem to do a very good job of testing release candidates. I know the scale is different but if you look at something like Ubuntu, there's a whole army of end users testing the next release and the subforum created for that purpose is highly active. What's impressive about what they have done over there is that people are testing for testing's sake -- as in trying to break the new features rather than just have the latest and possibly greatest version.

I do suspect that more end users run the latest Git version than install release candidates for testing.

I think it would help the limited number of testers if we were given more hints about what's actively changing. It does happen -- you show off your new stuff on the forum and so does Torsten -- but these things get a bit lost in newsletters, buried in forum threads, on the mailing list and wiki. What do you think of the idea of having a subforum in Release Candidates for "Next" with a locked, sticky thread where developers list out areas that need some testing focus? Effectively a living set of release notes that builds from one feature freeze to the next. When the feature freeze happens, "Next" becomes 3.6 RC and the basis of the release notes for 3.6 RC are sitting there at the top of the subforum. Users can test and when we come to a reasonable conclusion that we have a bug, post it on the devel mailing list.

What do you think of the idea of having a subforum in Release Candidates for "Next" with a locked, sticky thread where developers list out areas that need some testing focus?

If it helps, I'd certainly be willing to do that.

Not sure whether I would know what requires testing focus though... Many bugs are actually not in new features which get a lot of testing before they are committed, but caused by 'innocent' maintenance things (so the missing light - wasn't broken by maintenance on lights - that would have been tested before committing - but by restructuring terrain info storage).

So such a list would only be useful if it's finite - once I list every subsystem I touched with a commit, it ceases to be helpful. But to keep it finite might be problematic.

I think what is important to realize is that most developers probably have rather different use and test profiles of FG. I do 90% of my testing with AW and ALS on (simply because that's what I develop), shader quality at highest and check breakage of other rendering frameworks only comparatively briefly in the remaining time. Usually I just do a few minutes with the ufo at some benchmark locations (Caribbean, French Alps, South Africa, US Southwest) - I do 30+ minute flights in aircraft except the ufo very rarely and never any hour long airliner flights.

Obviously, testers which have a different use profile are more valuable then.

In general, I think I have the advantage that rendering tends to produce very visual bugs, so I tend to get notice soon. Though the disadvantage that they're highly architecture dependent, so knowing about a bug might still not help much.

I think also this kind of bug should have been detected by the developpers by doing a kind of "checklist", in order to be sure that some basic features are still Ok ( lights during night flight, VASI/PAPI, sound, shaders, weather for example ),

another way :

- writting unit tests for each modules of flightgear, the developer by launching these automatic tests will be sure that there is no regression/bug ( at least in a module, a function, a class )