RC 3.4

[Pakistan-1]

When will the FG 3.4 release candidate be coming out ?

[elgaton]

FG 3.4 RC1 is already available from the build server (the code for 3.4 was declared "frozen" at the beginning of January, that is, no new features will be added, just bug fixes).

[Vladimir Akimov]

I can't change the weather :/ and more bugs... I will stay with the 3.2 for now. Will wait for the official release...

[Thorsten]

I can't change the weather :/ and more bugs... I will stay with the 3.2 for now. Will wait for the official release...

Um... I can change weather. So it's not a widespread bug, it's peculiar for your system. Which means if you don't report it in detail and help us tracing it by running tests with rc3.4 and instead wait for the release, the release will contain just the same things which don't work. Because we can't fix what runs okay on our systems.

[Vladimir Akimov]

Ok ok ok... I didn't say nothing bad... Just advicing... Because I have the Windows 8.1 and many people have it. So...

[Hooray]

issues with a highly FG specific subsystem like the weather system are unlikely to be affected by your OS - so you really need to follow Thorsten's advice and come up with a simple test case for reproducing the issue, so that we can troubleshoot/understand what is going on. Personally, I am 99% certain that it is either specific to your system or that it is even due some misunderstanding involving the way things are supposed to work vs. "expected to work".

The underlying GUI itself is extremely crude - so not being able to change any values there should also show up in other dialogs.
Equally, there are tons of other factors involved here that make it complicated to get to the real problem unless you provide a detailed bug report - ideally, assuming that we're all 5-year olds without having a clue - so that you really post all the steps involved, including what you see/expect - if in doubt, I'd suggest to post screen shots

[Vladimir Akimov]

Ok ok ok ok...
but I also didn't find the new cam :/

[niels]

hi there i'm using a macbook pro unibody 2008 and i really want to play flightgear but its not yosemite compatible and the RC version doesn't work either what can I do every time I try to open the RC version it says that the program is damaged or incomplete

[Thorsten]

hi there i'm using a macbook pro unibody 2008 and i really want to play flightgear but its not yosemite compatible

Yes it is - you just have to start it from the commandline like us linux folks do or use the temporary Yosmite launcher (search the forum for that one).

[niels]

thanks a lot Thorsten now i can go further im appreciate it

[curt]

Here is a quick v3.4 release candidate update.

James continues to work on an OSX code signing issue that is affecting some OSX versions. His efforts include setting up a new build server from scratch so it is taking some time and his efforts are ongoing.

Hopefully the release is in pretty good shape for Linux and Windows (with 32 bit and low memory issues discussed in other threads.)

There is some other not happy news from one of the core FlightGear developers. It's not my news to share, so without saying specifics I ask that we are collectively sensitive to this, and not treat it with the usual forum conspiracy theories and not assume the worst possible motivations. The reason I bring this up is that it may affect the timing of our release at least a little bit. All I ask is that we be sensitive to this and extend a bit of grace if we see a delay in the release that does not appear to be technical in nature. I assure you that good people are doing their best, trust me on that.

We are up to RC2 now, and I hope that in the next few days, James can get another successful OSX build. At that point we'll bump up to RC3.

Thanks to everyone who has taken the time to try one of the release candidates and shared your experiences!

Curt.

[clrCoda]

VA pilots really really want to help.

I happen to belong to FlightGear's longest living virtual airline. One of the things that is great about the VA's is that we happen to stress-test some of the most well defined aircraft over much of the entire world scenery. Day in and day out. And, often, for more than half a day at a time. Every system.

In order to have error free, faultless flights, we require a very stable release.

But that doesn't always have to be the case. Or the only case, that is. We could be using our most talented, experience sim pilots to produce more of the necessary tests during release candidates rather than after release.

There has to be a way to have a stable release AND a testing suite of the release candidate that co-exist in order to be the helpers we would like to be.

We should be able to have installed side by side the files and folders necessary to maintain a previous, mostly excellent previous installation, say 3.2, and right along side that the current release candidate, with out fouling files and folders.

A flight in a release candidate should be ultimately restartable in the previous version if a segfault occur at the location that the segfault occured.


Fix that problem, and you've made a ton of testing pilots that have the know how and knowledge to be the testers Flightgear requires, with the propensity to stress every system and scenery fully. And also the confidence to use a release candidate. As it is, my fellow VA pilots tend to hold back, one, two, even three versions because they are confident in those previous versions.

2centsWorth. Thanks for reading

Ray

[Thorsten]

We should be able to have installed side by side the files and folders necessary to maintain a previous, mostly excellent previous installation, say 3.2, and right along side that the current release candidate, with out fouling files and folders.

What's keeping you from that? I thought you can have multiple FG installations on one computer?

A flight in a release candidate should be ultimately restartable in the previous version if a segfault occur at the location that the segfault occured.

You can easily convince yourself that this can't work in general even conceptually. Simple example: 3.4 introduced a new airplane, the Nova. You fly with the Nova, FG writes a log file. There's no way 3.2 can read that log file and resume the last written state, because it doesn't even have the Nova. JSBSim and YaSim change between versions, so the set of properties which represents the state of a plane in 3.4 JSBSim isn't the set that of properties that characterizes it in 3.2. And so on.

You can possibly make something like that work for several narrowly defined use cases, but the effort to do that is in no reasonable relationship to the possible gain.

You have to be realistic and look at what can be rather than what should be

As it is, my fellow VA pilots tend to hold back, one, two, even three versions because they are confident in those previous versions.

Yes, everyone wants to do that and wait for someone else to test and fix. Unfortunately, what happens then is that bugs are gone for the people who test and report sufficient details (my FG experience is practically untroubled by bugs and I have all the latest goodies, because whatever I find I either fix or diagnose and report, so it's usually gone a few days later), whereas (config, architecture and use-case specific) bugs will persist for all people who don't report and just wait. So you're just shooting yourself into the foot.

You're not version testing for us - the development community makes sure we don't see bugs ourselves - you're doing this for yourself.

[Hooray]

I happen to agree with Thorsten - however, the "continue flight in previous FG version" use-case can be consciously supported by users and contributors - e.g. by using the flight recorder/replay system to write an fgtape - the flight recorder system hasn't changed in years as far as I can tell. And all the properties are aircraft specific. So resuming flights would be possible absent the very exceptions that Thorsten mentioned (e.g. an aircraft in FG 5.xx using features unsupported in 2.12) - this could for example apply to changes to the Canvas system, so that some instruments wouldn't work as expected.
However, generally you should be able to replay flights in an older FG version, especially "standard" properties, i.e. position, altitude and velocities.

Fix that problem, and you've made a ton of testing pilots that have the know how and knowledge to be the testers Flightgear requires, with the propensity to stress every system and scenery fully. And also the confidence to use a release candidate.

I don't think that's going to happen at all - just look at the 777, it is exceptionally well maintained and does have a custom flight recorder configuration - yet, people aren't using FG to make bug reports using those means.

It wouldn't be difficult to sample/store a flight done with the ufo/ogel and replay that in an older FG version - complex stuff (think avoinics) will need extra work though.
And the instant the new aircraft is doing stuff that isn't supported by the old binary, you are in uncharted waters - imagine handing a USB memory disk to your grandfather, when he was a teenager ...

"forward compatibility", you know ?

[clrCoda]

What's keeping you from that? I thought you can have multiple FG installations on one computer?

And I do. 1.9.1, 2.0, 2.2, 2.4, 2.6, 2.8, ( missed 2.10 being offline ), 2.12, ( missed 3.0 being offline ) and 3.2.
I do this because I have pilots that I help diagnose trouble with their installations. Had to load 2.4 just yesterday to help a VA pilot.

It's not a problem for me. It was more a statement of getting VA pilots to possibly trust release candidates.

I also created the RALPH system to help restart at a last know position by logging the necessary information by the minute and providing the convenience of making those init-pos entries for a pilot.

While I completely agree with Thorsten, and what Hooray has said about the recorder, I merely made an observation that since planes tend to lag version development, these things are not completely impossible to achieve. Especially across adjacent versions.

Regarding planes, I would certainly have planes installed that go with the version installed. So i'm not sure that particular issue is a point. Maybe it is and I've not thought it through or missed something.

I'm not afraid to be told I'm wrong, gentlemen . I am afraid to be told that i'm doing something selfish when the obvious point was to open testing for some of the most prolific and constant users we tend to attract that might not be nearly as sophisticated users as you or I. To get them in the right column as helpers before the fact, and change the current tendency to complain after the fact.

It wouldn't be difficult to sample/store a flight done with the ufo/ogel and replay that in an older FG version - complex stuff (think avoinics) will need extra work though.

Hooray you had also mentioned the 777 as well. I'd have a 777 in my 3.2 and a 777 in a release candidate 3.4, and while the recorder might not be the answer to a re-init-position across version, something like RALPH could because it sets up the proper version of the plane in the proper version of the sim. This is in no way an endorsement for the hack ware that is RALPH

... and the flight continues.

I don't think this is completely an idea with-out merit.
I'm honored that you both thought well enough to post points that help sus this out.

Thanks again. -- Ray