FlightGear-1.99.5-RC2

[Durk Talsma]

Ladies and Gentlemen,

Please find FlightGear 1.99.5-RC2 ready for download. In order to relieve my
humble server, John Wojnaroski has kindly provided some space on his server to
host the source and base package. Please find the relevant files here:

http://www.lfstech.com/pub/flightgear/

In addition, a prebuild windows release, kindly provided by Frederic Bouvier
is available here:

ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgsetup-1.99.5-rc2.exe

I expect the mac perelease to follow shortly.

This prerelease is based on last wednessday's source code. This means that the
latest cloud patches didn't make it in yet.

If all goes well, I would like to prepare the final release version next
Friday. Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)

Cheers,
Durk

[gerard robin]

Post by Durk Talsma
Ladies and Gentlemen,
Please find FlightGear 1.99.5-RC2 ready for download. In order to relieve
my humble server, John Wojnaroski has kindly provided some space on his
server to host the source and base package. Please find the relevant files
http://www.lfstech.com/pub/flightgear/
In addition, a prebuild windows release, kindly provided by Frederic
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgsetup-1.99.5-rc2.exe
I expect the mac perelease to follow shortly.
This prerelease is based on last wednessday's source code. This means that
the latest cloud patches didn't make it in yet.
If all goes well, I would like to prepare the final release version next
Friday. Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)
Cheers,
Durk

Only to get more precision about it:
which version of OSG will be used, since we are not certain that the next
stable 2.8 will be available in time ?
May be, have it under your hat :)
And, what about Boost library which one will be used ?

Thanks

[Timothy Moore]

Post by gerard robin

Post by Durk Talsma
Ladies and Gentlemen,
Please find FlightGear 1.99.5-RC2 ready for download. In order to relieve
my humble server, John Wojnaroski has kindly provided some space on his
server to host the source and base package. Please find the relevant files
http://www.lfstech.com/pub/flightgear/
In addition, a prebuild windows release, kindly provided by Frederic
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgsetup-1.99.5-rc2.exe
I expect the mac perelease to follow shortly.
This prerelease is based on last wednessday's source code. This means that
the latest cloud patches didn't make it in yet.
If all goes well, I would like to prepare the final release version next
Friday. Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)
Cheers,
Durk

which version of OSG will be used, since we are not certain that the next
stable 2.8 will be available in time ?

Robert plans to release 2.8 "before Christmas." I think it's worthwhile waiting
to release FG after 2.8 comes out, unless there's some big delay in OSG 2.8.

Post by gerard robin
May be, have it under your hat :)
And, what about Boost library which one will be used ?

1.34 is the latest that is needed.
Tim

[Frederic Bouvier]

Post by Timothy Moore

Post by gerard robin

Post by Durk Talsma
If all goes well, I would like to prepare the final release version next
Friday. Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)
Cheers,
Durk

which version of OSG will be used, since we are not certain that the next
stable 2.8 will be available in time ?

Robert plans to release 2.8 "before Christmas." I think it's worthwhile waiting
to release FG after 2.8 comes out, unless there's some big delay in OSG 2.8.
Hi FlightGear-er's,
On Fri, Dec 12, 2008 at 6:46 PM, Robert Osfield

Post by gerard robin

Post by Durk Talsma
What time frame are you working to?

No answer, but it's important for me to have an idea. If you are
pushing out a release this weekend then there is no way we can get 2.8
in time, if it's next two weeks there is chance, in the next month
then we'll certainly be able to get 2.8.
I would like to get 2.8 in time for your release, as it makes sense
for both communities to have stable releases coinciding.
Robert.

I replied that the target is next Friday. After that I may have
difficulties to build a binary from where I will be.

-Fred

[Durk Talsma]

Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may have
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I have a
Christmas dinner this Friday, so I won't be able assemble the final release by
then. Saturday will be fine for me, so I hope to roll up the release then.

Cheers,
Durk

[gerard robin]

Post by Durk Talsma
Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may have
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I have a
Christmas dinner this Friday, so I won't be able assemble the final release
by then. Saturday will be fine for me, so I hope to roll up the release
then.
Cheers,
Durk

Hello, Durk

How do you schedule the period test with OSG 2.8 before rolling up the
release ?
OR do you avoid any test with it ?

Cheers

[Durk Talsma]

Hi Gerard,

Post by gerard robin
Hello, Durk
How do you schedule the period test with OSG 2.8 before rolling up the
release ?
OR do you avoid any test with it ?
Cheers

As Fred mentioned, I'm routinely building and testing FlightGear against
OSG/SVN. I haven't noticed any problems. I have the impression that most
developers are doing that, but I could be wrong.

Are there any issues that would make it undesirable to build FlightGear
against the last stable release of OSG? I have seen some discussion regarding
that point, but haven't watched it that closely.

Cheers,
Durk

[John Denker]

Post by Durk Talsma
Please find FlightGear 1.99.5-RC2 ready for download. In order to relieve my
humble server, John Wojnaroski has kindly provided some space on his server to
http://www.lfstech.com/pub/flightgear/

Wow, that's a very significant increase in speed and convenience.
Thanks.

Post by Durk Talsma
If all goes well, I would like to prepare the final release version next
Friday. Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)

There are two possible approaches:
a) Make a list of things that need to be checked, or
b) Set a date.

Given that nobody is being paid to get everything checked by
any particular date, it is likely that these two approaches
will produce very different results.
a) If you want a quality release, stick to the checklist.
b) If you want a release soon, stick to the date.

Your choice.

===========================

Here's a bug report. I have two machines that exhibit the same
behavior, namely invisible aircraft. No error messages, no warnings,
just no aircraft. I've checked this with several different aircraft.
Most aircraft are entirely invisible in all views (pilot view,
chase view, etc.) but 'some' sub-components of the 777 are visible
in 'some' views.

One machine is a Pentium with an ATI graphics processor and Radeon
driver.

The other machine is a dual-core Pentium @ 3 GHz apiece, with an
Intel graphics processor and the xorg driver.

Both are using OSG 2.6.1 and the rc2 package.

One odd observation: Not only is the aircraft invisible, but some
of the terrain is invisible also. This becomes obvious because
you can see the underside of some scenery. In particular, users
will discover that some seemingly short buildings are really tall
buildings with most of the building hiding underground.

This problem is partly new and partly not. RC1 and several of the
cvs versions since August would get a SEGV before doing anything
useful. But I havent' done a systematic study of that and I'm not
interested in debugging old versions. I'm just mentioning it by
way of context, just for completeness. In some sense it is good
progress that rc2 gets far enough to exhibit the invisible aircraft.

=======================

And another bug report: Several of the aircraft in the rc2 package
make highly inappropriate noises during startup. This bug has
been present for years.

=======================

I know of lots more bugs. Let me know if you want me to report
them.

[Erik Hofman]

Post by John Denker
Here's a bug report. I have two machines that exhibit the same
behavior, namely invisible aircraft. No error messages, no warnings,
just no aircraft.

..

Post by John Denker
Both are using OSG 2.6.1 and the rc2 package.
One odd observation: Not only is the aircraft invisible, but some
of the terrain is invisible also.

I believe this is fixed by using the latest version of OSG

Erik

[Frederic Bouvier]

Post by John Denker
Intel graphics processor and the xorg driver.
Both are using OSG 2.6.1 and the rc2 package.

This has already been discussed. You need at least OSG 2.7.3

-Fred

[John Denker]

Post by Frederic Bouvier
You need at least OSG 2.7.3

OK.

And the OSG site seems to be back up.

Meanwhile, back at the ranch, in RC2 we have the following
README.OSG file;

Post by Frederic Bouvier

[This file is mirrored in both the FlightGear and SimGear packages.]
You *must* have OpenSceneGraph (OSG) installed to build this version of
FlightGear.
http://www.openscenegraph.org/
Unzip the file OpenSceneGraph-2.0.zip and install using the following
unzip OpenSceneGraph-2.0
cd OpenSceneGraph
ccmake .
[ While running ccmake: press 'c' to configure, press 'c' once more, and
then press 'g' to generate and exit ]
make
sudo make install

It might be good to fix that before the release goes out.

[gerard robin]

Post by John Denker

Post by Durk Talsma
Please find FlightGear 1.99.5-RC2 ready for download. In order to relieve
my humble server, John Wojnaroski has kindly provided some space on his
server to host the source and base package. Please find the relevant
http://www.lfstech.com/pub/flightgear/

Wow, that's a very significant increase in speed and convenience.
Thanks.

Post by Durk Talsma
If all goes well, I would like to prepare the final release version next
Friday. Until that time please hold back on committing anything risky,
and give these prereleases a decent workout. Let's try to make this the
best FlightGear release yet. :-)

a) Make a list of things that need to be checked, or
b) Set a date.
Given that nobody is being paid to get everything checked by
any particular date, it is likely that these two approaches
will produce very different results.
a) If you want a quality release, stick to the checklist.

Yes, which is the coming up question.
We may hope, and pray, that everything would be right, NOW.
(though, we know that there is a 3DClouds difficulty)

OR, wait for that coming stable 2.8 OSG version, and ask to any users, with
any configuration to test fully that FG version.
I can be alone to think that there is a lot of users who are still working
with the last stable OSG version ( i have friends in that case).
If yes, these users have not been able, along the past weeks, to test the
last FG updates ( like i was not, until, recently, i could get a free
computer to build a specific FG configuration).
In addition to it, the boost library being now necessary, they could have some
difficulties (the first time) to build FG.
That could lead to a necessary delay before getting some useful feedback, and
the coming period is not the best, holiday period, people could be far from
any computer, and giving the priority to the family life.

Post by John Denker
b) If you want a release soon, stick to the date.
Your choice.

SNIP

Regards

[John Denker]

Post by Durk Talsma
If all goes well, I would like to prepare the final release version next
Friday.

Wow.

Post by Durk Talsma
Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)

I haven't had time to do a decent workout ... just a pre-flight
walkaround and a re-check of some longstanding bugs.

Here is a list of a few dozen opportunities for improvement.


1:: c172p: As of rc2, the model makes weird, unrealistic noises that
are presumably supposed to be engine noise, but do not vary in pitch
or amplitude in the appropriate way. Real pilots are very sensitive
to engine noise.

2:: c172p: As of rc2, there does not appear to be any interior area
lighting or any "post" lighting for the instruments. The light
sources are not present, and the knob that would control them is not
present. Lighting is ordinarily needed for night flight. It would be
nice to portray the lighting-control knob, but even nicer to have
additional control via the keyboard and/or via a drop-down menu,
since the knob would be hard to find at night, creating a
chicken-and-egg problem.

3:: c172p: As of rc2, the aircraft's landing and taxi lights are
not effective at illuminating the runway or other surfaces. This
is an issue for night operations.

4:: c172p: As of rc2, on the 3D cockpit nav heads, under some
conditions when GS would be flagged, the GS needle just disappears,
which is unrealistic, since it is a side-pivot needle. In real life
it is physically impossible for this type of needle to disappear.
Also as of rc2 there is some sort of barber pole showing near the
bottom of the display under all conditions. The legend on this
barber pole is illegible.

The NAV2 head in the Seneca is much better behaved.

5:: c172p: As of rc2, there is no Kollsman window visible on the
altimeter. Note that the Kollsman window is rather important in real
flying situations.

6:: c172p: As of rc2, the rudder pedals are oddly positioned; mostly
out of sight of the pilot. Structurally, they appear to come up from
the bottom on stalks, instead of down from above as they should.
And as of rc2, the rudder pedals don't move when rudder movement is
commanded. (The rudder moves, just not the pedals.) This stands in
contrast to other aircraft in the fgfs fleet, including the c182rg,
Seneca, pa24-250, and even the c172r, which have animated rudder
pedals with some degree of realism.

7:: c172p: As of rc2, there is no parking brake status indicator. Note
that landing with the parking brake set would be a disaster in a real
airplane.

8:: c172p: As of rc2, the electrical switches don't line up with their
labels.

9:: c172p: As of rc2, the panel voltmeter reads incorrectly. It is "in
the red" i.e. offscale high even when the actual voltage is within
the normal range.

10:: c172p: As of rc2, there do not appear to be any hotspots by which
the mouse could control carb heat, throttle, or mixture.

11:: c172p: As of rc2, the audio panel is beautiful to look at, but not
functional; i.e. audio signals are not routed through the audio panel.

12:: c172p: As of rc2, ADF hotspots do not line up with the buttons.

13:: c172p: As of rc2, the carb heat control has a funny shape. Also
it looks like it is "out" i.e. carb heat applied. Also it does not
respond when the pilot changes the carb heat setting. This stands in
contrast to the throttle and mixture controls, which do respond.

14:: c172p: As of rc2, when parked, the wheels appear to be several
inches above the ground ... the nose wheel more so than the mains.
This is particularly conspicuous if the aircraft is parked over or
near a stripe on the pavement.

15:: c172p: As of rc2, there does not appear to be any trim position
indicator. Trim is important.

16:: c172p: As of rc2, there does not appear to be any flap position
indicator. Also the flap handle is installed at an unrealistic
angle, so even that cannot be used as a realistic hint about flap
setting.

16) c172p: As of rc2, the fuel caps (atop the wing) are rotated 90
degrees relative to what they should be.

17:: c172p: As of rc2, the front wheel is not centered on the front
axle. This looks quite weird.

18:: c172p: As of rc2, the nutcracker on the nose gear strut is not
realistic when on the ground. It looks better but not 100% realistic
in flight. The nutcracker should fold, not just get shoved rigidly
through the bottom of the engine compartment.

19:: c172p: As of rc2, when looking at the aircraft from outside,
distant background is visible through gaps in the cowling:
-- near the firewall
-- near the spinner, especially just below the spinner.
The gap itself is OK. But there should be something solid inside the
engine compartment. Or at least double-sided opacity for the cowling
material.

20:: c172p: As of rc2, there does not appear to be any EGT gauge. This
seems unrealistic. Sure, the factory considers the gauge "optional",
but why would any owner pass up the option? To save money???

Note that the Seneca and the Comanche have nice-looking 3D EGT gauges.

21:: c172p and SenecaII: As of rc2, there is no transponder. Operating
at KSFO without a transponder is unrealistic.

Note that there is a nice-looking and well-behaved transponder in the
CVS c182rg.

22:: c172p: No GPS? Is it realistic to fly without a GPS these days?
Suggestion: Remove the ADF and DME from the main radio stack and use
the space for a transponder and GPS. The ADF and DME can be
relocated far to starboard or discarded entirely.

23:: c172p: Numerous performance / handling / FDM bugs ... as discussed
elsewhere.

24:: SenecaII: As of rc2, there is a "flap motor" noise when the flaps
are being extended or retracted. I don't think this is appropriate
for manually-operated flaps.

25:: Instrument: Phantom DME ident. As of rc2, sit on the ground at
Livermore, KLVK. That's within the base package. Tune up the Travis
VOR on 116.4 and listen for the ident. You will hear the TZZ VOR
ident ... so far so good ... and also the TZZ DME ident. That's a
problem, because there is no DME at Travis. The phantom DME ident
comes from a long-standing bug in the audio ident code.

26:: Core feature: As of rc2, if --fg-scenery points to something
nonexistent or unsuitable, no error message is produced. The sim
just starts up with no scenery. This appears to be a rather new bug.
Users would benefit from an informative error message.

27:: Multiple aircraft, including SenecaII: Inappropriate noises
resembing "gear motor" noises are heard during initialization. Also
a "clank" resembing a brief attempt to start an engine. This is a
very old bug.

28:: Multiple aircraft, including c172p and SenecaII: As of rc2, with
parking brake set, the aircraft does not hold position. Somewhat
noticeable at idle; very very noticeable during a full-throttle
runup.

This used to be a problem, then it got mostly fixed, and now it has
returned. Reportedly it is a problem with the "ground interaction"
features of the FDM.

29:: ATIS: Bugs too numerous to mention.

30:: Instrument: Localizer service volume: As of rc2, the localizer
service volume appears to be very different from what it is supposed
to be, as documented in the Aeronautical Information Manual. There
is no sign of the false localizer courses that real systems always
exhibit abeam the station.

Similar words apply to false GS beams and other service-volume
issues.

31:: Dialog: As of rc2, attempting to use the "glideslope" feature of
the locate-in-air dialog does not work. It does not work if the
altitude is specified (and not the distance). It does not work if
the distance is specified (and not the altitude). This has been a
known bug for years.

32:: Dialog: As of rc2, if you sit at KSFO and try to relocate to the
SAV VOR, it will take you to Savannakhet, Laos (SAV) ... even though
the pilot probably wanted to go to Savannah, GA (SAV). In case of
ambiguity, the rule should be to go to the /nearest/ fix of the given
name.

This has been a known bug for a very long time.

33:: Dialog: As of rc2, attempting to use the locate-in-air dialog more
than once tends to make the simulator unusable and to spew error
messages on the console. Example:

Could not open and/or write the state to the initial conditions file.
Model Author: Unknown
Creation Date: 2002-01-01
Version: $Id: c172p.xml,v 1.20 2008/09/01 15:14:33 torsten Exp $
Description: Cessna C-172
Trim Results:
Angle of Attack: 5.53 wdot: nan Tolerance: 1e-03 Failed
Throttle: 0.50 udot: nan Tolerance: 1e-03 Failed
Pitch Trim: 0.00 qdot: nan Tolerance: 1e-04 Failed

Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 0 average: 0.00 successful: 0 stability: 100.00
udot: 0 average: 0.00 successful: 0 stability: 100.00
qdot: 0 average: 0.00 successful: 0 stability: 100.00
Run Count: 55200
OpenAL error (AL_INVALID_VALUE): set_pitch
CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.0075 5.00004e-07 0.0),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

... followed by a rapid and endless spew of "nan" and such.

This situation nearly 100% reproducible if the dialog is used more
than once during a flight. The message is not terribly informative.
There is AFAIK no way to recover from this situation short of
restarting fgfs.

This is an old bug; it was first reported a couple of years ago.

34:: Core feature: The --model-hz=10 setting still crashes the sim.
Symptoms are variable: One time it initialized the aircraft in a 90
degree nose-up initial attitude and left it there, with 100% cpu usage
and zero frame-rate. Another time it spewed endless gibberish to the
console, such as the "nan" blocks mentiond above.

This is a very old bug.

35:: Airport: As of rc2, the runway centerline lighting is missing
from runway 28R at KSFO.

36:: As several people have reported over the years, the Saitek X52
interface needs many improvements. See:
http://www.av8n.com/fly/fgfs/README.X52
http://www.av8n.com/fly/fgfs/X52.xml.htm

[James Turner]

Post by John Denker
22:: c172p: No GPS? Is it realistic to fly without a GPS these days?
Suggestion: Remove the ADF and DME from the main radio stack and use
the space for a transponder and GPS. The ADF and DME can be
relocated far to starboard or discarded entirely.

I'm doing major GPS work locally, but sufficiently major that there is
no question of merging it before this release goes out (it's going to
temporarily break certain aircraft, until they are updated to use some
different /gps/ properties). In the medium term, I hope to be able to
support a realistic, appropriate GPS unit in the panel.

Post by John Denker
32:: Dialog: As of rc2, if you sit at KSFO and try to relocate to the
SAV VOR, it will take you to Savannakhet, Laos (SAV) ... even though
the pilot probably wanted to go to Savannah, GA (SAV). In case of
ambiguity, the rule should be to go to the /nearest/ fix of the given
name.

This one should be low-hanging fruit for me, I'll take a look today.

James

[James Turner]

Post by James Turner

Post by John Denker
32:: Dialog: As of rc2, if you sit at KSFO and try to relocate to the
SAV VOR, it will take you to Savannakhet, Laos (SAV) ... even though
the pilot probably wanted to go to Savannah, GA (SAV). In case of
ambiguity, the rule should be to go to the /nearest/ fix of the given
name.

This one should be low-hanging fruit for me, I'll take a look today.

Had a quick look, this is a combination of weakness in the position
init code, and an explicit design choice in the 'location-in-air'
dialog box.

Essentially, if you specify start-up position (via the command line or
some other property source), and use the --fix or --navaid forms,
you'll get a random (actually first by DB order) hit matching the
ident. I've considered (and still do) allowing a locale to be
established using an airport, country code or similar, or using
shutdown location, but it's all a compromise. (If you use frequency
and ident, you'll hopefully get an exact match, I haven't checked for
duplicates in that case)

The dialog box behaviour, is that it explicitly clears out the current
lat/lon before doing the navaid/fix search, so we get the same
behaviour from the GUI - at least it's consistent.

My proposed fix is to add a 'base position' or similar to the
properties, and use this as the start point for spatial searches in
the position init code. When running from the command line, I'll leave
it unset to avoid surprising anyone with new behaviour, but once we're
started I'll use the current position, which should make the GUI
dialog work as expected.

However, I'm not sure doing any of this is wise for 1.99.5, better to
do it after the release and let it get some testing, since there's so
many permutations of position-init command lines.

James

[John Denker]

Post by James Turner
The dialog box behaviour, is that it explicitly clears out the current
lat/lon before doing the navaid/fix search, so we get the same
behaviour from the GUI - at least it's consistent.
My proposed fix is to add a 'base position' or similar to the
properties, and use this as the start point for spatial searches in
the position init code. When running from the command line, I'll leave
it unset to avoid surprising anyone with new behaviour, but once we're
started I'll use the current position, which should make the GUI
dialog work as expected.
However, I'm not sure doing any of this is wise for 1.99.5, better to
do it after the release and let it get some testing, since there's so
many permutations of position-init command lines.

I reckon JT's previous estimate -- "low hanging fruit" --
is closer to the mark. (Guess how I know.)

I don't think a "base position" is needed. A notion of
"current position" sufficies. As for the CLI, it is useful
to process the positioning items _in order_ so that going
to --airport=KJFK and then to --vor=SAV will reliably get
you to Savannah, GA ... whereas specifying the options in
the reverse order would have a different meaning.

Other options obviously need to be processed out-of-order,
notably --help --verbose.

Of course the "locate" dialogs should not clear the current
position.

I suspect there is little risk of unhappy surprises. Very
few pilots intend to relocate from KSFO to Savannakhet in
one step.

This affects not just the CLI and the GUI, but also some
RNAV units.

I wrote the code to do this years ago, and have used it
a gazillion times since. It works fine. The concept
is simple:
-- Start at the lowest level. Whenever anybody looks
up an ID, always fetch *all* the matching IDs.
-- Always sort the list according to distance.
-- Then, at the next higher level, if somebody wants
only one match, give 'em the _nearest_ match.

These bugs arose because there were N different pieces
of ID-match code in FGFS. Recently JT has been fixing
that, so I reckon almost all of the infrastructure is
in place to make this bug go away once and for all,
hardly even as a bug-fix, but as a natural consequence
of a more general clean-up, which is usually the nicest
way for things to happen.

===========

While we're in the neighborhood: It would be good to
make all ID-matches become case-insensitive. I wrote
the code to do this years ago. It's very simple and
very helpful.

[James Turner]

Post by John Denker
I don't think a "base position" is needed. A notion of
"current position" sufficies. As for the CLI, it is useful
to process the positioning items _in order_ so that going
to --airport=KJFK and then to --vor=SAV will reliably get
you to Savannah, GA ... whereas specifying the options in
the reverse order would have a different meaning.
Other options obviously need to be processed out-of-order,
notably --help --verbose.

There's a technical issue here - fgPositionInit code see properties,
unordered, not arguments, I believe. But also, I think that specifying
both airport and a navaid is a bit ugly, syntax-wise.

I haven't come up with something neater, otherwise I'd have
implemented it already.

Post by John Denker
Of course the "locate" dialogs should not clear the current
position.
I suspect there is little risk of unhappy surprises. Very
few pilots intend to relocate from KSFO to Savannakhet in
one step.

I agree, but I tend to be ultra-cautious when proposing such changes
to long-standard functionality :)

Post by John Denker
While we're in the neighborhood: It would be good to
the code to do this years ago. It's very simple and
very helpful.

Yes, agreed, I'll update all my ident-based queries to normalise case.

James

[Tim Moore]

Post by John Denker

Post by Durk Talsma
If all goes well, I would like to prepare the final release version next
Friday.

Wow.

Post by Durk Talsma
Until that time please hold back on committing anything risky, and
give these prereleases a decent workout. Let's try to make this the best
FlightGear release yet. :-)

I haven't had time to do a decent workout ... just a pre-flight
walkaround and a re-check of some longstanding bugs.
Here is a list of a few dozen opportunities for improvement.

...

Post by John Denker
2:: c172p: As of rc2, there does not appear to be any interior area
lighting or any "post" lighting for the instruments. The light
sources are not present, and the knob that would control them is not
present. Lighting is ordinarily needed for night flight. It would be
nice to portray the lighting-control knob, but even nicer to have
additional control via the keyboard and/or via a drop-down menu,
since the knob would be hard to find at night, creating a
chicken-and-egg problem.
3:: c172p: As of rc2, the aircraft's landing and taxi lights are
not effective at illuminating the runway or other surfaces. This
is an issue for night operations.

...
After 2.0 I'll start merging in my Effects framework code that will make, among
other things, local light sources practical. I'm not sure if the best way to do
cockpit lighting is to have a light source in the cockpit or to simply turn up
the emissiveness of the instruments and dashboard...

Tim

[Frederic Bouvier]

Post by Tim Moore

Post by John Denker
3:: c172p: As of rc2, the aircraft's landing and taxi lights are
not effective at illuminating the runway or other surfaces. This
is an issue for night operations.

...
After 2.0 I'll start merging in my Effects framework code that will
make, among other things, local light sources practical. I'm not
sure if the best way to do cockpit lighting is to have a light
source in the cockpit or to simply turn up
the emissiveness of the instruments and dashboard...

I don't think there will be a 2.0 anytime soon. It took 10 years to have
v1.0 . I hope you mean 1.99.5

-Fred

[James Turner]

Post by Frederic Bouvier

Post by Tim Moore
After 2.0 I'll start merging in my Effects framework code that will
make, among other things, local light sources practical. I'm not
sure if the best way to do cockpit lighting is to have a light
source in the cockpit or to simply turn up
the emissiveness of the instruments and dashboard...

I don't think there will be a 2.0 anytime soon. It took 10 years to have
v1.0 . I hope you mean 1.99.5

Heh, I was wondering about this - I'm hopeful that Tim means what he
wrote, but that 2.0 will also be along soon, maybe even Q1 2009. And
then 2.1, 2.2 and so on...

James

[Tim Moore]

Post by James Turner

Post by Frederic Bouvier

Post by Tim Moore
After 2.0 I'll start merging in my Effects framework code that will
make, among other things, local light sources practical. I'm not
sure if the best way to do cockpit lighting is to have a light
source in the cockpit or to simply turn up
the emissiveness of the instruments and dashboard...

I don't think there will be a 2.0 anytime soon. It took 10 years to have
v1.0 . I hope you mean 1.99.5

All the better for scheduling :)

Post by James Turner
Heh, I was wondering about this - I'm hopeful that Tim means what he
wrote, but that 2.0 will also be along soon, maybe even Q1 2009. And
then 2.1, 2.2 and so on...

I meant that I would start checking this stuff in after the 1.99.5 release.

Tim

[James Turner]

Post by Tim Moore

Post by James Turner
Heh, I was wondering about this - I'm hopeful that Tim means what he
wrote, but that 2.0 will also be along soon, maybe even Q1 2009. And
then 2.1, 2.2 and so on...

I meant that I would start checking this stuff in after the 1.99.5 release.

Ah, even better.

James

[Heiko Schulz]

Post by James Turner

Post by Tim Moore

Post by James Turner
Heh, I was wondering about this - I'm hopeful

that Tim means what he

Post by Tim Moore

Post by James Turner
wrote, but that 2.0 will also be along soon, maybe

even Q1 2009. And

Post by Tim Moore

Post by James Turner
then 2.1, 2.2 and so on...

I meant that I would start checking this stuff in

after the 1.99.5

Post by Tim Moore
release.

Ah, even better.
James

Well, he didn't say when after the release- 2009, 2010, 2050.... ;-)

[Heiko Schulz]

Hi,

Well, This time I really think I should make my works commercial- or if you want to have all this give ma a lot of money.

I'm aware that we want to make it right, like our overall concept on flightgear.org says.
But this is also dependant of time and (!) information the model authos have.
All what I did was updating the 3d-modell to the state of the art now we can have with FGFS.

Post by John Denker
Here is a list of a few dozen opportunities for
improvement.
1:: c172p: As of rc2, the model makes weird, unrealistic
noises that
are presumably supposed to be engine noise, but do not
vary in pitch
or amplitude in the appropriate way. Real pilots are very
sensitive
to engine noise.

record me the original sonds and I try very best on it!

Post by John Denker
2:: c172p: As of rc2, there does not appear to be any
interior area
lighting or any "post" lighting for the
instruments. The light
sources are not present, and the knob that would control
them is not
present. Lighting is ordinarily needed for night flight.
It would be
nice to portray the lighting-control knob, but even nicer
to have
additional control via the keyboard and/or via a drop-down
menu,
since the knob would be hard to find at night, creating a
chicken-and-egg problem.

Give me the position of this knob, a plenty of time and money for my needed stoppage of real life work.

Post by John Denker
3:: c172p: As of rc2, the aircraft's landing and taxi
lights are
not effective at illuminating the runway or other
surfaces. This
is an issue for night operations.

Well- I always thought you are longer and more in FlightGear than me- so you should know, that there is yet no real lighting effect implemented and the workaround by Gerad Robin used in his aircraft and the pa24 is just a workaround. We want to make it right, remember?

Post by John Denker
4:: c172p: As of rc2, on the 3D cockpit nav heads, under
some
conditions when GS would be flagged, the GS needle just
disappears,
which is unrealistic, since it is a side-pivot needle. In
real life
it is physically impossible for this type of needle to
disappear.
Also as of rc2 there is some sort of barber pole showing
near the
bottom of the display under all conditions. The legend on
this
barber pole is illegible.
The NAV2 head in the Seneca is much better behaved.

I used the instrumentes given by FlightGear- instead using someones other instrument we should correct the existing ones. So when will you do this?

Post by John Denker
5:: c172p: As of rc2, there is no Kollsman window visible
on the
altimeter. Note that the Kollsman window is rather
important in real
flying situations.

Give us a altimeter with this working thing and I will use this then!

Post by John Denker
6:: c172p: As of rc2, the rudder pedals are oddly
positioned; mostly
out of sight of the pilot. Structurally, they appear to
come up from
the bottom on stalks, instead of down from above as they
should.
And as of rc2, the rudder pedals don't move when
rudder movement is
commanded. (The rudder moves, just not the pedals.) This
stands in
contrast to other aircraft in the fgfs fleet, including
the c182rg,
Seneca, pa24-250, and even the c172r, which have animated
rudder
pedals with some degree of realism.

Oh- did I mention that the aircraft is still WIP? Did I? No?

Post by John Denker
7:: c172p: As of rc2, there is no parking brake status
indicator. Note
that landing with the parking brake set would be a
disaster in a real
airplane.

Where is this indicator? Pics?

Post by John Denker
8:: c172p: As of rc2, the electrical switches don't
line up with their
labels.

Well, need some adjustements- llok at the answer on 6.)

Post by John Denker
9:: c172p: As of rc2, the panel voltmeter reads
incorrectly. It is "in
the red" i.e. offscale high even when the actual
voltage is within
the normal range.

So much as I knwo I known bug... Do we have some electrician here? You?

Post by John Denker
10:: c172p: As of rc2, there do not appear to be any
hotspots by which
the mouse could control carb heat, throttle, or mixture.

Look at the answer at 6.)

Post by John Denker
11:: c172p: As of rc2, the audio panel is beautiful to look
at, but not
functional; i.e. audio signals are not routed through the
audio panel.

Aks Mr. Dreyer why- but I'm pretty sure there is a meaning behind!

Post by John Denker
12:: c172p: As of rc2, ADF hotspots do not line up with the
buttons.

Look at answer 6.)

Post by John Denker
13:: c172p: As of rc2, the carb heat control has a funny
shape. Also
it looks like it is "out" i.e. carb heat
applied. Also it does not
respond when the pilot changes the carb heat setting.
This stands in
contrast to the throttle and mixture controls, which do
respond.

We don't have carburetor icing yet- so it doesn't work of course! But you can implement this!

Post by John Denker
14:: c172p: As of rc2, when parked, the wheels appear to be
several
inches above the ground ... the nose wheel more so than
the mains.
This is particularly conspicuous if the aircraft is parked
over or
near a stripe on the pavement.

Well- did you finally decide how the orientation of this aircraft has to be? I'm still waiting for a answer of YOU and so long I won't do anything on this issue!

Post by John Denker
15:: c172p: As of rc2, there does not appear to be any trim
position
indicator. Trim is important.

See my answer under 6.)

Post by John Denker
16:: c172p: As of rc2, there does not appear to be any flap
position
indicator. Also the flap handle is installed at an
unrealistic
angle, so even that cannot be used as a realistic hint
about flap
setting.

See my answer under 6.)

Post by John Denker
16) c172p: As of rc2, the fuel caps (atop the wing) are
rotated 90
degrees relative to what they should be.

..and there are the rivest missing, openings for maintenance and, and, and, and.....Well- I better aks Cessan for a complete CAD-Model....

Post by John Denker
17:: c172p: As of rc2, the front wheel is not centered on
the front
axle. This looks quite weird.

Look under point 6.)

Post by John Denker
18:: c172p: As of rc2, the nutcracker on the nose gear
strut is not
realistic when on the ground. It looks better but not
100% realistic
in flight. The nutcracker should fold, not just get
shoved rigidly
through the bottom of the engine compartment.

Ah- you my answer...

Post by John Denker
19:: c172p: As of rc2, when looking at the aircraft from
outside,
-- near the firewall
-- near the spinner, especially just below the spinner.
The gap itself is OK. But there should be something solid
inside the
engine compartment. Or at least double-sided opacity for
the cowling
material.

How about an engine-model? Give me photos I will try...

Post by John Denker
20:: c172p: As of rc2, there does not appear to be any EGT
gauge. This
seems unrealistic. Sure, the factory considers the gauge
"optional",
but why would any owner pass up the option? To save
money???

It is not unrealistic! See here:http://www.airliners.net/photo/Cessna-172P/1094256/L/

Post by John Denker
Note that the Seneca and the Comanche have nice-looking 3D
EGT gauges.

Maybe they look nice- but I'm pretty sure if use them you will come up again and say this is not realistic....

Post by John Denker
21:: c172p and SenecaII: As of rc2, there is no
transponder. Operating
at KSFO without a transponder is unrealistic.
Note that there is a nice-looking and well-behaved
transponder in the
CVS c182rg.

You know my answer- ->6.)

Post by John Denker
22:: c172p: No GPS? Is it realistic to fly without a GPS
these days?
Suggestion: Remove the ADF and DME from the main radio
stack and use
the space for a transponder and GPS. The ADF and DME can
be
relocated far to starboard or discarded entirely.

Yes, it is! And by the way- we don't have a good working GPS yet....

Post by John Denker
23:: c172p: Numerous performance / handling / FDM bugs ...
as discussed
elsewhere.

yep- and should be on the JSBSim-list- not here!

Post by John Denker
27:: Multiple aircraft, including SenecaII: Inappropriate
noises
resembing "gear motor" noises are heard during
initialization. Also
a "clank" resembing a brief attempt to start an
engine. This is a
very old bug.

Record us the real sounds, and the authors will implement this!

Post by John Denker
28:: Multiple aircraft, including c172p and SenecaII: As of
rc2, with
parking brake set, the aircraft does not hold position.
Somewhat
noticeable at idle; very very noticeable during a
full-throttle
runup.
This used to be a problem, then it got mostly fixed, and
now it has
returned. Reportedly it is a problem with the
"ground interaction"
features of the FDM.

Bug in JSBSim and YASim- we 3d-modellers can't do much

Post by John Denker
36:: As several people have reported over the years, the
Saitek X52
http://www.av8n.com/fly/fgfs/README.X52
http://www.av8n.com/fly/fgfs/X52.xml.htm

So much as I know it has been fixed.

@Durk: we really should stop the current Release, fix all bugs and come back again 2050! And for not crashing some mail servers we should prevent John from using the other aircrafts and helicopters and more, so that he can't flood the list we more or less important bug reports! [Attention] very ironic![/Attention]

@John again: Sorry, but I'm not happy with your type of criticism. I coulden't see anything comitting to FGFS from you yet, so I wonder if I should really take you seriously!
It was about 3 months ago when I finally decide to update the 3d-model and the panel of the c172p. I announced it on the list, had pics and the model itself for download - and just two answers which came from my "home community", the german flightGear community. I'm at least quite happy that one of them has a ppl and fly this aircraft regularly, so I could get some infos. But I coulden't get any flight nmanual nor having one real c172p as master!

Indeed, I was wondering several times if this is really a good idea to go on and not to stop, and now I think of it again!

It seems to me that you only can run something down, than really bringing in something positive. That makes the project FlightGear not better- it makes it worse and unserious!

HHS

[Alexis Bory - xiii]

Post by Heiko Schulz
Hi,
Well, This time I really think I should make my works commercial- or
if you want to have all this give ma a lot of money.
I'm aware that we want to make it right, like our overall concept on
flightgear.org says. But this is also dependant of time and (!)
information the model authos have. All what I did was updating the
3d-modell to the state of the art now we can have with FGFS.

Hi Heiko, you did a wonderful job! I'm sure most of us think the same.

When furbishing the Tomcat I have only one tester, Jano, and he gives
me useful feedback. (Yes Melchior also helps a lot with nasal reviewing).
With only a friend having a look at my job, there will never be a so much
in depth review. And yes some time I also feel tired fixing bugs and
unaccuracy again and again.

I think you shouldn't take this over detailed review as personal criticism
about your work. Writing such a review is already a hell of a job, and it
difficultly could take all historical aspects in account.

We are all stressed while building for ourself an idea of what should be
the next release. Anyhow, it is a good thing that you did precise what
is the
scope or area of you work.

Sure, the c172p will be near perfect soon or later.

All the best,
Alexis

[James Turner]

Post by Heiko Schulz
@John again: Sorry, but I'm not happy with your type of criticism. I
coulden't see anything comitting to FGFS from you yet, so I wonder
if I should really take you seriously!
It was about 3 months ago when I finally decide to update the 3d-
model and the panel of the c172p. I announced it on the list, had
pics and the model itself for download - and just two answers which
came from my "home community", the german flightGear community. I'm
at least quite happy that one of them has a ppl and fly this
aircraft regularly, so I could get some infos. But I coulden't get
any flight nmanual nor having one real c172p as master!
Indeed, I was wondering several times if this is really a good idea
to go on and not to stop, and now I think of it again!
It seems to me that you only can run something down, than really
bringing in something positive. That makes the project FlightGear
not better- it makes it worse and unserious!

This seems to be getting rather personal.

As far as I can tell, John 'reviewed' the C172 in much the same way a
commercial reviewer would, if given a C172 for MSFS. In doing so, he's
raised some bugs which are generic to all of FG (lack of runway
lighting and position init bugs), some genuine C172 issues, and some
opinions about which C172 we are modelling (the comments about whether
a GPS is/isn't accurate).

Heiko, as far as I can tell, was hoping for constructive feedback
about his work on the C172 panel and model, which is a rather
different thing. Especially since, as he noted, it's a work in progress.

Clearly Heiko's work on the C172 is appreciated, and obviously it will
always be difficult to decide what constitutes an accurate C172 in
many areas. And reporting issues is useful as well, so long as they
don't come across as an attack on someone's hard work.

For many of the C172 issues, someone really needs to dig in to the
code (not necessarily C++) and see why the battery voltage (for
example) is wrong, or copy an EGT gauge over from another aircraft.
It'd be lovely if bug reports were accompanied by some analysis (like
my Bravo/GPWS investigation) of this rather than just the user-level
feedback. Obviously that's much more time consuming, but *someone* has
to do that work, ultimately.

Regards,
James

[Heiko Schulz]

Post by James Turner
It'd be lovely if bug reports were accompanied by some
analysis (like
my Bravo/GPWS investigation) of this rather than just the
user-level
feedback. Obviously that's much more time consuming,
but *someone* has
to do that work, ultimately.
Regards,
James

That's the point- you also noticed bugs on FGFS. That's o.k.- because you did analyze them, proposed fixings and you still work on all this.
And it is o.k. if there is a reminder who remember us on all unfixed bugs.
But I don't like it if hey hide under the year of developement and when there is a release they come up and only making useless noise....

I have problems with his feedback because I have a private life, have to earn money and not the time to sit 24h daily at the computer to make the c172p realistic as possible. It is a work in progress and I'm at least happy to get a 3d-model and a panel to show than the old, poor 2d-panel we used before. In the moment the c172p is not worser than the orignal model by David Megginson. Problem: because Davis is gone from the project and I took over the c172p with the 3d-update, I'm now the maintainer...
If I had knew how important this model seems for FGFS, I had never began this work.

There is another big project by me, the ec135 and I know that there was a lot of people like them. It is broken now, and I don't see any time to have them fully back until the release because the c172p and of course prvate life, job etc- well, it is chrismas time here...And that makes me a bit sad.

[John Denker]

Post by Heiko Schulz

Post by John Denker
1:: c172p: As of rc2, the model makes weird, unrealistic
noises that
are presumably supposed to be engine noise, but do not
vary in pitch
or amplitude in the appropriate way. Real pilots are very
sensitive
to engine noise.

record me the original sonds and I try very best on it!

The sounds for the CVS c182rg are a vast improvement over the
rc2 c172p ... not perfect in absolute terms but relatively
much, much better, especially as regards the dependence on
RPM. They should be directly transferable with minimal effort.

Sorry for not mentioning this in the original post.

[Laurent Vromman]

Post by John Denker
22:: c172p: No GPS? Is it realistic to fly without a GPS these days?
Suggestion: Remove the ADF and DME from the main radio stack and use
the space for a transponder and GPS. The ADF and DME can be
relocated far to starboard or discarded entirely.

I have a few dozens of hours flying in planes from Cessna, Robin or Socata.
I have never used any GPS (nor a DME or an ADF). A map, a compas, a VOR to
be sure, that's enough. Except to do some night VFR or IFR flight, you need
almost anything in a plane. The C172 is a basic plane, "easy" to use in a
simulator to discover or train VFR flying. It doesn't need to much
electronic things the pilot loses time to use without looking outside for
his own security.

Laurent

[John Denker]

On 12/12/2008 09:36 AM, Durk Talsma asked for bug reports.
So on 12/15/2008 11:20 PM, I sent in some bug reports.
Please don't shoot the messenger.

Post by Heiko Schulz
Oh- did I mention that the aircraft is still WIP? Did I? No?
I always heard that the c172p is one of our
most realistic ones....
We have reports from real c172 pilots that thy don't see any issues!

1) As for me, I always assume all this stuff is a WIP, even
when people claim otherwise.

2) You can't make bugs go away by shouting "there are no bugs!"

3) There are some people on this list who are quick to turn
anything and everything into a personal attack, but it
doesn't need to be that way. There are plenty of other
lists in the world where that doesn't happen.

Post by Heiko Schulz
I used the instrumentes given by FlightGear- instead using someones
other instrument we should correct the existing ones. So when will
you do this?

I submitted patches to correct many of the "old bugs"
recently mentioned. Dozens of them. I submitted them
a couple of years ago. Nobody even looked at them.

If nobody wants to fix these bugs, that's OK ... but
it would be way, way off base to accuse me of not
offering constructive contributions.

[Melchior FRANZ]

Post by John Denker
I submitted patches to correct many of the "old bugs"
recently mentioned. Dozens of them. I submitted them
a couple of years ago. Nobody even looked at them.

I'm pretty sure that I looked at every single of them.
But either I wasn't competent to judge them and hoped
someone else would review/discuss/commit (atmosphere
stuff, instruments), or I was (sufficiently) competent,
but my complaints were not addressed (multiline
gdb-backtraces added to function headers etc.) and you
didn't re-submit fixed versions[1]. And then there were
a few of your patches that I actually committed. Two or
three, IIRC. And, finally, I even looked at the bug
list on your website and picked up two ideas from
there and implemented them.

Post by John Denker
it would be way, way off base to accuse me of not
offering constructive contributions.

That's true.

m.


[1] Of course, this doesn't mean that only code can go
in that *I* find acceptable. But OTOH, nobody can
expect me to commit something that I don't like. :-}

[James Turner]

(echoing Melchior slightly)

Post by John Denker
3) There are some people on this list who are quick to turn
anything and everything into a personal attack, but it
doesn't need to be that way. There are plenty of other
lists in the world where that doesn't happen.

Absolutely, but equally, people do take pride in their contributions.
Using strong language where mild language will do is not required,
most of the time. Especially when English is not people's native
language.

Post by John Denker
I submitted patches to correct many of the "old bugs"
recently mentioned. Dozens of them. I submitted them
a couple of years ago. Nobody even looked at them.

(Melchior addressed this bit)

Post by John Denker
If nobody wants to fix these bugs, that's OK ... but
it would be way, way off base to accuse me of not
offering constructive contributions.

The problem is, what happened a couple of years is irrelevant, in the
strictest sense of the word: it has zero relation to the present. You
know what you did and said, and some other people may recall, but the
'community' doesn't. Getting patches into CVS takes time, and
persistence, and diplomatically convincing people that it's the right
thing to do, and more persistence, and so on. (Personally I'd like it
to be easier, but that's exactly a *personal* opinion)

So, please do submit patches to fixed any of the issues you mentioned.
Maybe they'll get applied - or maybe not! But they fact that they're
not doesn't mean the issues aren't cared about, it just means people
feel ownership for different parts of the code, and have real lives as
well as FG, and many other factors. Possibly you'll have to explain in
several different ways why your believe a change is correct, but
that's still part of the process, based on my own experience of
submitting patches.

James

[John Denker]

Post by James Turner
The problem is, what happened a couple of years is irrelevant, in the
strictest sense of the word: it has zero relation to the present.

Except that the problem continues into the present. Very
recently I submitted a patch. The guy who specifically
requested the patch "didn't have time" to look at it.
OK, fine ... but I don't have time to submit patches
that aren't going to be looked at.

Post by James Turner
You
know what you did and said, and some other people may recall, but the
'community' doesn't. Getting patches into CVS takes time, and
persistence, and diplomatically convincing people that it's the right
thing to do, and more persistence, and so on. (Personally I'd like it
to be easier, but that's exactly a *personal* opinion)

I have found that it is much easier to send my code to
various third parties, who will remain nameless, and
let them submit it.

Or I just leave it lying around and wait for somebody
to plagiarize it.

It turns out that my code is perfectly acceptable to this
community, so long as it doesn't have my name on it.

There's a lot more I could say about this, but I choose
not to.

[Tim Moore]

Post by John Denker

Post by James Turner
The problem is, what happened a couple of years is irrelevant, in the
strictest sense of the word: it has zero relation to the present.

Except that the problem continues into the present. Very
recently I submitted a patch. The guy who specifically
requested the patch "didn't have time" to look at it.
OK, fine ... but I don't have time to submit patches
that aren't going to be looked at.

I think I'm the "guy" in this story, although perhaps this has happened more
than once. It's true, I looked at your Sport Model repository and found I didn't
have the time to deal with a branch that is based on FlightGear from over a year
ago. I struggled a bit with your first commit in SimGear, but it turns out that
there is no real consensus for committing it among those that seem to care about
texture animations in instruments, so I ended up dropping it. I'm surely not
alone among open source project committers in having a strong aversion to
dealing with patches against old versions. For what it's worth, I sort of
understand your reluctance to put work into something that you think isn't going
to be accepted anyway (though I do think you'd want to be up-to-date with all
our latest, greatest stuff); so there we are.

Post by John Denker

Post by James Turner
You
know what you did and said, and some other people may recall, but the
'community' doesn't. Getting patches into CVS takes time, and
persistence, and diplomatically convincing people that it's the right
thing to do, and more persistence, and so on. (Personally I'd like it
to be easier, but that's exactly a *personal* opinion)

I have found that it is much easier to send my code to
various third parties, who will remain nameless, and
let them submit it.
Or I just leave it lying around and wait for somebody
to plagiarize it.
It turns out that my code is perfectly acceptable to this
community, so long as it doesn't have my name on it.

Whatever works :) If you have really have found folks willing to work with you
to get your stuff committed, that's great. If you are having to leave your name
off the code as a result, that's bullshit; let me know what fixes went in
anonymously and I will make sure you are credited for them if you wish.

Post by John Denker
There's a lot more I could say about this, but I choose
not to.

By the way, I found your critique of problems in the rc2 useful and completely
appropriate.

Tim

[Martin Spott]

Post by John Denker
2) You can't make bugs go away by shouting "there are no bugs!"
3) There are some people on this list who are quick to turn
anything and everything into a personal attack, but it
doesn't need to be that way.

John, you should be aware that your understanding of a 'factual
discussion' which you have demonstrated occasionally on this very list
isn't necessarily shared by the majority of the readers and/or involved
persons.

To be a little bit more verbose: Imposing your very personal view onto
a topic to others (even if it's obviously plain wrong) and responding
to opposing views with blunt disrespect - as it has occured several
times - doesn't help. I'd deliver examples, if desperately requested,
but I don't think it's really required (at least I hope so, because I
didn't plan to spend my time on searching list archives ....).

If you'd try to put some more 'negotiation' into your style of factual
discussion, this certainly will make everyone's life easier,

Martin.

[John Denker]

A few more opportunities for improvement:

37:: Documentation: As of rc2, data/Docs/FGShortRef.pdf is in dire
need of an update. It bears a 2005 date, and internally refers to
version 0.8.0. For example, it thinks the "space" key (not the "s"
key) runs the starter.

38:: Documentation: As of rc2, I'm pretty sure data/Docs/getstart.pdf
needs to be updated in some place.

For example, I see instructions for downloading scenery, but they
don't mention the 1.0.1 scenery or where to find it. IMHO this is
release-critical.

Also: Have "release notes" been prepared to go with the new release?

39:: Scenery: As of rc2, fgfs is properly defensive about the "base
package version" but AFAICT that does not cover the scenery files,
which are often downloaded separately. Bad scenery files can lead to
strange, hard-to-diagnose bugs. Suggestion: Each and every scenery
file should contain a version number that is both machine-readable
and human-readable. Hint: see the unix man pages for file(1) and
magic(5). At every opportunity, fgfs should check the version
numbers on these files.

40:: Scenery servers: Question: Has anybody thought about the demand
for downloads that will be generated by a new release, especially one
that requires new scenery? Have the servers and mirrors been sized
appropriately?

[Martin Spott]

Post by John Denker
37:: Documentation: As of rc2, data/Docs/FGShortRef.pdf is in dire
need of an update. It bears a 2005 date, and internally refers to
version 0.8.0. For example, it thinks the "space" key (not the "s"
key) runs the starter.
38:: Documentation: As of rc2, I'm pretty sure data/Docs/getstart.pdf
needs to be updated in some place.
For example, I see instructions for downloading scenery, but they
don't mention the 1.0.1 scenery or where to find it. IMHO this is
release-critical.

Yup, you're right. Please submit either patches to the LaTaX source
code or just simple text files via a notice on this list or directly
via EMail to Stuart or me. If you like, find the appropriate
instructions for pulling the LaTeX source here:

http://www.flightgear.org/cvs/getstart-cvs.html

Post by John Denker
40:: Scenery servers: Question: Has anybody thought about the demand
for downloads that will be generated by a new release, [...]

Yes,
Martin.

[Martin Spott]

[...] If you like, find the appropriate
http://www.flightgear.org/cvs/getstart-cvs.html

.... or here (via GIT):

http://mapserver.flightgear.org/git/gitweb.pl?p=getstart

Martin.

[John Denker]

A couple more six-legged crawly things:

41:: c172p: As of rc2, if the pilot is tall or if the pilot's seat is
cranked up high, a weird artifact appears in the field of view. To
demonstrate this, use the property viewer to set
/sim/current-view/y-offset-m to 0.4 (instead of the default value of
0.3). I don't know what this artifact is or where it came from.
Perhaps it is a misplaced scrap of upholstery. I'm pretty sure it
can be deleted with no regrets.

42:: Instrument: KAP-140: As of rc2, as installed in the c172p and
presumably others, on initial startup the display of the Sim World
KAP-140 is blank. This is already a bug, because the display of the
Real World KAP-140 is never blank (unless you pull the circuit
breaker, which is not relevant to the present discussion). In
particular, the altitude alerter function is always active and cannot
be turned off, even in the rather common case where the auto-bank and
auto-pitch functions are on standby. In this case, the RW KAP-140
displays the target altitude. It would be nice if the SW KAP-140
did the same.

The nightmare scenario for the noobie pilot is taking off from an
airport situated above 1000 MSL and flying to an airport at 950 MSL.
Since the "default" target altitude is zero, there will be an alert
on short final at 1000 MSL == 50 feet AGL. Unexpected beeping
warnings at 50 feet AGL are not a good thing.

We note in passing that the instructions at
http://wiki.flightgear.org/index.php?title=Bendix/King_KAP140_Autopilot
do not even mention the alerter.

[John Denker]

43:: CPU hog: When the sim is paused, it eats CPU cycles. It will
happily use 99+% of the CPU if there is no competition. I don't
understand why any appreciable CPU cycles are needed during pause.

44:: Memory hog: When the sim is paused, if you leave it alone for 15
minutes or so, it starts eating virtual memory at the rate of several
megabytes per minute. That's a lot. I'm talking about the "VIRT"
quantity reported by top(1) ... in contrast to ps(1) which does not
make the problem quite so obvious.

I conjecture that the reason for the delay is that the sim has a
certain amount of memory already availble on its free list, and
the memory hog has to chew through that before new memory needs
to be requested from the VM system.

I observe that if the simulator is un-paused, virtual memory size
increases for a while, then levels out. I also observe that after an
un-pause, it takes another 15 minutes of pause before obvious memory
eating resumes. These observations lead me to conjecture that some
type of events or messages are getting backlogged during pause, but
are belatedly processed when the pause ends, thereby freeing up some
space on the free list.

[Csaba Halász]

Post by John Denker
43:: CPU hog: When the sim is paused, it eats CPU cycles. It will
happily use 99+% of the CPU if there is no competition. I don't
understand why any appreciable CPU cycles are needed during pause.

I assume you are not using sync-to-vblank or fps throttle. Those would
keep resource usage limited. I don't think any further optimization
for the paused state is worthwhile.

Post by John Denker
44:: Memory hog: When the sim is paused, if you leave it alone for 15
minutes or so, it starts eating virtual memory at the rate of several
megabytes per minute.

...

Post by John Denker
These observations lead me to conjecture that some
type of events or messages are getting backlogged during pause, but
are belatedly processed when the pause ends, thereby freeing up some
space on the free list.

Are you on multiplayer by any chance? This issue should be investigated.

[John Denker]

Post by Csaba Halász
I assume you are not using sync-to-vblank or fps throttle.

That's a correct assumption. Forsooth, I've never heard of
sync-to-vblank or fps throttle in this context. The names
sound nice, but
-- They are not mentioned in --help --verbose
-- They do not appear in the drop-down menus AFAICT.
-- They do not appear in the getstart manual or in
any of the plain-text documents in data/Docs AFAICT.

I mention this because I'm trying to test things from
the user's point of view. If these features are going
to be important to users, it would be useful to put
them where users can find them.

Or ... maybe turn them on by default. Recomputing the
image at a rate that exceeds the refresh rate of the
display seems kinda pointless, unless I'm overlooking
something.

Post by Csaba Halász

Post by John Denker
44:: Memory hog: When the sim is paused, if you leave it alone for 15
minutes or so, it starts eating virtual memory at the rate of several
megabytes per minute.

Are you on multiplayer by any chance? This issue should be investigated.

Not on multiplayer. No funny options. All I did
was fire up fgfs, pause it, and go out to dinner.

As I said at the top of this thread, I haven't had
time to give rc2 a thorough workout. I'm just
reporting bugs that leap out at me when I try to
use some of the basic features.

[Stuart Buchanan]

Post by John Denker

Post by Csaba Halász
I assume you are not using sync-to-vblank or fps throttle.

That's a correct assumption. Forsooth, I've never heard of
sync-to-vblank or fps throttle in this context. The names
sound nice, but
-- They are not mentioned in --help --verbose
-- They do not appear in the drop-down menus AFAICT.
-- They do not appear in the getstart manual or in
any of the plain-text documents in data/Docs AFAICT.

Good point.

If I get the chance before the release I'll check the manual
and make sure they are mentioned.

Post by John Denker
I mention this because I'm trying to test things from
the user's point of view. If these features are going
to be important to users, it would be useful to put
them where users can find them.
Or ... maybe turn them on by default. Recomputing the
image at a rate that exceeds the refresh rate of the
display seems kinda pointless, unless I'm overlooking
something.

That is a fair point, but I don't think we have any easy way
to determine the refresh rate of the display.

Setting the fps throttle by default in preferences.xml might be
worthwhile. I don't have it set myself, but I believe that many
people use it to provide more consistent frame-rates.

-Stuart

[John Denker]

45:: Mr. Freeze: Early in the flight, the first time the "v" key is
used to switch to a new view, the display freezes for several
seconds. The machine appears to be CPU-bound during this time;
usually no disk access is observed.

The controls are frozen also, but sim-time appears to pass after a
fashion, which means woe betide the pilot who was manuevering when
the "v" key was hit. The aircraft will continue to roll, pitch,
turn, etc., but the pilot cannot see it (until later) and cannot do
anything about it.

Switching to subsequent views (third, fourth, etc.) or back to the
original view does not seem to incur additional freeze time.


------------------------------------------------------------------------------

[John Denker]

46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
the "W" must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.


------------------------------------------------------------------------------

[Syd]

Post by John Denker
46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
the "W" must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

I'm open to suggestions.... would a dhc2-wheels , dhc2-floats make more
sense ?


------------------------------------------------------------------------------

[Erik Hofman]

Post by Syd

Post by John Denker
46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
the "W" must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.

I'm open to suggestions.... would a dhc2-wheels , dhc2-floats make more
sense ?

I think John is thinking of using non cases-sensitive aircraft names.

Erik

------------------------------------------------------------------------------

[John Denker]

Post by Erik Hofman

Post by Syd

Post by John Denker
46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
the "W" must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.

I'm open to suggestions.... would a dhc2-wheels , dhc2-floats make more
sense ?

I think John is thinking of using non cases-sensitive aircraft names.

I was ... but Syd raises a couple of other good points:

It wouldn't hurt to make the --aircraft=... option
a) insensitive to hyphenation, and
b) accepting of unique abbreviations
as well as
c) insensitive to case.

Example: If the "official" name is DHC2-wheels, then dhc2w would
automatically be an acceptable synonym.

This seems like an obvious step in the direction of user-friendliness.


------------------------------------------------------------------------------

[Frederic Bouvier]

Post by John Denker

Post by Erik Hofman

Post by Syd

Post by John Denker
46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
the "W" must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.

I'm open to suggestions.... would a dhc2-wheels , dhc2-floats make more
sense ?

I think John is thinking of using non cases-sensitive aircraft names.

It wouldn't hurt to make the --aircraft=... option
a) insensitive to hyphenation, and
b) accepting of unique abbreviations
as well as
c) insensitive to case.
Example: If the "official" name is DHC2-wheels, then dhc2w would
automatically be an acceptable synonym.
This seems like an obvious step in the direction of user-friendliness.

Well, and what about using a graphical aircraft chooser. I know a good
one ;-)

-Fred

PS: fgrun if you didn't get it.

[Melchior FRANZ]

Post by Frederic Bouvier
Well, and what about using a graphical aircraft chooser.
I know a good one ;-)

... or a shell completion script if you want it "pure"
(-> ./scripts/completion/).

Adding code for guessing what a user's bad input could
have meant is a rather bad idea. You'd need ways to
resolve ambiguities and there's no guarantee that the
guess is actually correct. I prefer a good old error
message in such cases.

m.

------------------------------------------------------------------------------

[Syd]

Post by Frederic Bouvier
Well, and what about using a graphical aircraft chooser. I know a good
one ;-)
-Fred
PS: fgrun if you didn't get it.

Its great for Windows users , but I dont use such things :)

------------------------------------------------------------------------------

[Curtis Olson]

There's no reason the chooser can't be made to run on any of our supported
platforms. It's written in fltk I believe and I've had it running in Linux
in the past. The only reason it might seem like it's a win32 only app is
that Frederic is really the only one who has taken the time to bundle it
with his binary build.

Regards,

Post by Syd

Post by Frederic Bouvier
Well, and what about using a graphical aircraft chooser. I know a good
one ;-)
-Fred
PS: fgrun if you didn't get it.

Its great for Windows users , but I dont use such things :)
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Jon Stockill]

Post by Curtis Olson
There's no reason the chooser can't be made to run on any of our
supported platforms. It's written in fltk I believe and I've had it
running in Linux in the past. The only reason it might seem like it's a
win32 only app is that Frederic is really the only one who has taken the
time to bundle it with his binary build.

Not quite true - it's been included in the Slackware Linux packages too.

Jon

------------------------------------------------------------------------------

[Curtis Olson]

Post by Jon Stockill

Post by Curtis Olson
There's no reason the chooser can't be made to run on any of our
supported platforms. It's written in fltk I believe and I've had it
running in Linux in the past. The only reason it might seem like it's a
win32 only app is that Frederic is really the only one who has taken the
time to bundle it with his binary build.

Not quite true - it's been included in the Slackware Linux packages too.

Excellent ... real proof it's not just a win32 application. :-)

Curt.

[Ron Jensen]

Post by Curtis Olson

Post by Curtis Olson
There's no reason the chooser can't be made to run on any of

our

Post by Curtis Olson
supported platforms. It's written in fltk I believe and

I've had it

Post by Curtis Olson
running in Linux in the past. The only reason it might seem

like it's a

Post by Curtis Olson
win32 only app is that Frederic is really the only one who

has taken the

Post by Curtis Olson
time to bundle it with his binary build.

Not quite true - it's been included in the Slackware Linux packages too.
Excellent ... real proof it's not just a win32 application. :-)

I also (ab)use it as a flightgear model viewer to quickly check submodel
placement... On debian where it builds just fine.

Ron



------------------------------------------------------------------------------

[Syd]

Post by Ron Jensen

Post by Curtis Olson

Post by Curtis Olson
There's no reason the chooser can't be made to run on any of

our

Post by Curtis Olson
supported platforms. It's written in fltk I believe and

I've had it

Post by Curtis Olson
running in Linux in the past. The only reason it might seem

like it's a

Post by Curtis Olson
win32 only app is that Frederic is really the only one who

has taken the

Post by Curtis Olson
time to bundle it with his binary build.

Not quite true - it's been included in the Slackware Linux packages too.
Excellent ... real proof it's not just a win32 application. :-)

I also (ab)use it as a flightgear model viewer to quickly check submodel
placement... On debian where it builds just fine.
Ron
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

I didn't mean it was a windows only option ... Ive used it with Linux
(also as a model viewer) , but I prefer the command line and an .fgfsrc
file :)
Cheers

------------------------------------------------------------------------------

[Roy Vegard Ovesen]

Post by John Denker
42:: Instrument: KAP-140: As of rc2, as installed in the c172p and
presumably others, on initial startup the display of the Sim World
KAP-140 is blank. This is already a bug, because the display of the
Real World KAP-140 is never blank (unless you pull the circuit
breaker, which is not relevant to the present discussion). In
particular, the altitude alerter function is always active and cannot
be turned off, even in the rather common case where the auto-bank and
auto-pitch functions are on standby. In this case, the RW KAP-140
displays the target altitude. It would be nice if the SW KAP-140
did the same.

Unfortunately I am unable to build FG at the moment but I think this patch
will display the target altitude at initialisation.

diff --git a/Aircraft/Generic/kap140.nas b/Aircraft/Generic/kap140.nas
index 1b76255..1e129c9 100644
--- a/Aircraft/Generic/kap140.nas
+++ b/Aircraft/Generic/kap140.nas
@@ -226,7 +226,7 @@ var apInit = func {
annunciatorFpm.setBoolValue(0);
annunciatorAlt.setBoolValue(0);
annunciatorAltArm.setBoolValue(0);
- annunciatorAltNumber.setBoolValue(0);
+ annunciatorAltNumber.setBoolValue(1);
annunciatorGs.setBoolValue(0);
annunciatorGsArm.setBoolValue(0);
annunciatorPtUp.setBoolValue(0);

Post by John Denker
The nightmare scenario for the noobie pilot is taking off from an
airport situated above 1000 MSL and flying to an airport at 950 MSL.
Since the "default" target altitude is zero, there will be an alert
on short final at 1000 MSL == 50 feet AGL. Unexpected beeping
warnings at 50 feet AGL are not a good thing.

Displaying the target altitude at all times will of course still result in the
beeping as you describe, but I guess it will be more expected. Can you
confirm that the RW KAP-140 behaves like this?

Post by John Denker
We note in passing that the instructions at
http://wiki.flightgear.org/index.php?title=Bendix/King_KAP140_Autopilot
do not even mention the alerter.

I was too lazy to document all the features, so I just pointed to the Pilot's
Guide :-) Feel free to add a mention of the altitude alerter in the Wiki.

[John Denker]

I was reminded [off list] that as of 2008, you can get by
without ADF in the US but not necessarily elsewhere.

Therefore I retract my half-suggestion that the ADF could
be removed entirely. Item 22 now reads:

22:: c172p: No GPS? Is it realistic to fly without a GPS these days?
Suggestion: Relocate the DME and the ADF tuner. Put them way over on
the starboard side. This makes room in the center stack for a
transponder and GPS.



------------------------------------------------------------------------------

[John Denker]

Remark: Not all of these bug reports are orignal with me. Some
were pointed out to me off-list.

47:: c172p, dhc2, and a tiny bit of SenecaII: As of 1.9.0, apparently
neither the c172p nor the dhc2 have have an outside air temperature
gauge. An OAT gauge is factory-standard equipment for these aircraft
in the Real World, although it is apparently not absolutely mandatory
in the US. In any case, trying to fly without an OAT gauge could be
mighty unpleasant, in a wide range of practical situations, including
hot weather or cold weather, especially at night and/or IFR,
especially in mountainous terrain.

As of 1.9.0, the SW SenecaII has a 3D OAT that looks great to viewers
inside the cockpit, but mysteriously disappears when the viewer is
outside looking in.

48:: dhc2: As of 1.9.0, the mixture cannot be controlled using a
joystick. A patch is available.

49:: dhc2: As of 1.9.0, there are multiple "fuel pressure" bugs.
Example 1: no contribution from the engine-driven fuel pump; in the
Real World this would be an obvious no-go condition. Example 2:
sometimes a low fuel pressure condition can force the mixture to be
/richer/ than it otherwise should have been. Example 3: the behavior
is improperly sensitive to the frame-rate of the sim. A patch is
available.

50:: YASIM engine, as installed on the dhc2 (but not on the pa24-250):
As of 1.9.0, while cranking the starter with less than full throttle,
the MAP exhibits dramatic, unrealistic fluctuations. MAP behavior
during shutdown is also a bit odd.

51:: Radio: navcom-kx155.xml as installed in the c172p and presumably
elsewhere: As of 1.9.0, the kHz digits unrealistically "carry" into
the MHz digits.

52:: Core feature: Nav: Reversible ILS: Consider the following
scenario. In the 1.9.0 Sim World, you are on the KJFK ILS RWY 31R
approach. You are at an altitude of 180 feet, centered on the
glideslope, about 1/2 mile from touchdown, i.e. just about to cross
over RWY 22L. All indications are stable. So far so good. Then
suddenly the localizer CDI needle switches from half a dot right of
center to full-scale left of center, through no fault of your own.

Evidently, the simulator has just switched the ILS transmitter from
31R to 13L, as you can confirm by listening to the ident. It does
this every time, as a function of aircraft position.

This means that in the 1.9.0 Sim World, the KJFK ILS RWY 31R is not
flyable under low-IFR conditions. I reckon the same problem arises
at every airport where there is a reversible ILS.

This is not good.

This is an old bug.

In the Real World, the active runway is determined based on wind
conditions (etc.) and the reversible ILS is set accordingly,
independent of aircraft position.

53:: In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower
airports, the lights are turned on during conditions of low
visibility and/or low ceiling, and also turned on if requested by the
pilot. For details, see FAA Order 7110.65p.

As of 1.9.0, runway and taxiway lights are turned on during the hours
of darkness, as determined by the angle of the sun. So far so good.

As of 1.9.0, runway lights and taxiway lights are turned on
automatically if visibility less than 5000 meters, day or night.
Apparently this is based on flight visibility (not on surface
visibility as they would be in the Real World). Consequently, as the
sim descends through a haze layer into improving visibility, you can
watch the Sim World lights turn themselves off, which is dramatically
unrealistic. Also: apparently the code treats a subset of approach
lights as part of the runway lights, so that subset has the same
dependence on time-of-day and visibility. The remaining approach
lights appear to be permanently off.

As of 1.9.0, there is apparently no dependence on ceiling. For
example, under a 150ft overcast ceiling, the lights are off during
the day. This is unrealistic i.e. inconsistent with FAA Order
7110.65p.

It is important to get the lighting right, because it affects both
the legality and the practicality of performing instrument approaches
in marginal conditions.

This bug has been known for a long time.

Suggestion: (DCL? Vivian?) -- As others have suggested, it sure would
be nice to have an "AI tower" that would correctly control the airport
lighting (including pilot-controlled lighting) and correctly determine
the runway in use (for ATIS, and for the reversible ILS, et cetera).
For some users -- not all, but some -- having a properly-behaved ILS
transmitter and properly-behaved lights is far more valuable than
having an AI wingman or having an AI Local Controller generating radio
traffic.

It would be especially nice for the AI tower to make these decisions
in a way that was consistent across all aircraft in the local
multiuser environment.

Lighting control and ILS control seem like policy decisions, the sort
of policy that ought to be implemented at fairly high level. It seems
odd -- especially in a multiuser situation -- to see such policy
implemented in low-level library functions such as
simgear/scene/tgdb/GroundLightManager.cxx. If we wanted to implement
features such as pilot-controlled lighting (for non-tower airports),
what would be the right place to do it?

54:: Core feature: When flying in the pattern at KJFK, I get "nan"
messages spewed on the console. The phenomenon is not hard to
reproduce, although I can't say exactly what conditions determine
the onset or rate of spew.

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.003005 -0.005005 5.00004e-07),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

55:: In the Real World, at large airports, the white runway lights are
highly directional, aimed along the direction of the runway. When
viewed in a direction transverse to the runway, they should be much
less bright, verging on invisibility when viewed from any appreciable
distance. As of 1.9.0, the lights (at, say, KJFK) seem to be
unrealistically omnidirectional.


------------------------------------------------------------------------------

[James Turner]

Post by John Denker
52:: Core feature: Nav: Reversible ILS: Consider the following
scenario. In the 1.9.0 Sim World, you are on the KJFK ILS RWY 31R

<snip>

Post by John Denker
In the Real World, the active runway is determined based on wind
conditions (etc.) and the reversible ILS is set accordingly,
independent of aircraft position.
53:: In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower
airports, the lights are turned on during conditions of low
visibility and/or low ceiling, and also turned on if requested by the
pilot. For details, see FAA Order 7110.65p.

<snip>

Both of these are related to airport dynamics, which is an area Durk
has been working on, and which I intend to get into in the medium-
(definitely not short-) term. Durk's code already tracks active
runways, but it's not hooked up to the rest of the code, i.e lighting,
ILS enables and so on. All of these things are doable and worthwhile.
PCL should also fall out of such a system.

At some point I hope to have a discussion about sorting out the
division of labour between FGAirport and FGAirportDynamics, since most
of the code only wants to deal with FGAirport, but would like some
dynamic information to be queried (transparently) from the dynamic
information.

As you note, most of these decisions are high-level, so I hope that
most of this work will be Nasal, not C++, once some more APIs are
exposed to the scripting layer.

James


------------------------------------------------------------------------------

[John Denker]

57:: Core feature: As of CVS 26 Dec 2008 I observe that at (say) KJFK
the "Tower" view and the "Tower Look From" view are conspicuously
broken. Other airports are broken, just less conspicuously so. This
appears to be the same problem previously discussed on the devel list
under the heading "nearcamera still not rendering" ... i.e. users can
see through the ground and discover that short buildings are really
just tall buildings sunk deep into the ground. Previously the remedy
was to upgrade to OSG 2.7.3 or higher ... but it appears the problem
still exists with OSG 2.7.7.

Also in the "Helicopter" view, there is some weird flickering that
may be the "flickering gap" previously attributed to nearcamera
problems.

58:: Instrument backend: As of CVS 26 Dec 2008, adf.cxx was doing a
number of conspicuously unrealistic things, including continuing to
drive the needle even after the tuner had been turned off. A patch
is available.

59:: Instrument: As of CVS 26 Dec 2008 it appears that the 2D ADF
front-end (as installed in e.g. the c182 and c182rg) lacks an on/off
switch. What's worse, it appears to lack any kind of "test" function
... which is sometimes rather important when using an ADF in the Real
World.

In contrast, the 3D ADF front end in the c172p does implement these
features (although it still needs to get its hotspots lined up with
its buttons; see bug #12).

60:: c172p: several instruments: As of CVS 26 Dec 2008, several
instruments including the ADF and the VHF navcomms as installed in
the c172p have the following property: When the electrical power is
cut off, their front-end displays continue to glow merrily (even
though the VOR CDI needles stop working). This is unrealistic.

As discussed on the list, it would be straightforward to fix this
bug plus the previous bug (and bug #12 too) by patching the "private"
copies of these instruments associated with the c172p, but it would
be a much better use of resources, in the short run and
super-especially in the long run, to un-fork the code and teach the
c172p to use instruments e.g. from the pa24-250 where these bugs have
long since been fixed. A patch to do this is available.


------------------------------------------------------------------------------

[John Denker]

Additional JSBsim FDM initialization-related bugs:

62:: I observe that in a JSBsim aircraft e.g. c182rg, after departing
the runway via the location-in-air menu item, there remains "weight
on wheels". That is, the gear/wow property remains true. It appears
to remain true forever, long after the model aircraft is airborne.

This is significant because it prevents the gear from retracting.

This is an old bug that was fixed for a while but has now returned.

This bug is *not* observed in non-JSBsim aircraft such as the pa24-250.

63:: The command-line options --roll-deg and --pitch-deg are
documented to exist according to --help --verbose, and are accepted
by the CLI parser ... but in JSBsim aircraft (such as the default
c172p) they are not observed to have any effect on the aircraft.

As previously reported, the corresponding presets have no effect
during a re-init, e.g. via fgcommand("presets-commit").


------------------------------------------------------------------------------

[John Denker]

74:: As of 1.9.0, the cockpit/panel system will segfault if the
<type>switch</type> statement is omitted from a layer that has
nothing but sublayers. Actually you don’t even need any sublayers; an
empty layer also segfaults:

<layer>
<name>SIGSEGV</name>
</layer>

The same of course applies to layers of the undocumented type
"group", as mentioned in bug 73, since leaving out one type of <type>
directive is pretty much like leaving out another.

But therein lies a clue as to how best to solve the problem: There
ought not be any distinction between type "group" and type "texture"
(which is the default). There ought to be one heterotic type of
layer, whose contents can include zero or one textures and zero or
more subsidiary layers (plus of course conditionals, transformations,
etc. that apply to all the texture and/or sublayers collectively).
This "heterotic" type should be the default, and "group" and
"texture" should be synonyms for it.


For context, including other bugs, see
http://www.av8n.com/fly/fgfs/htm/bug-list.htm

[John Denker]

79:: As of 1.9.0, changing "helvetica-bold" to "helvetica" in e.g.
Instruments/altimeter.xml causes the cockpit/panel loader to
segfault.

a) It would be nice if helvetica were supported.

b) Failing that, if helvetica is called for it would be nice to print
a warning and substitute some similar font.

[John Denker]

75:: As of 1.9.0, in the c182, the altimeter is not self-consistent.
There is an analog scale and a digital readout. It takes 10 clicks of
the Kollsman setting knob to move the digital readout ten hundredths
of an inch. It takes 14 or 15 clicks to rotate the analog scale the
corresponding amount.

Neither readout appears to produce entirely accurate altimetry,
although the analog scale is clearly worse. This is highly
unrealistic.

There exist other altimeter models that are both prettier and more
functional.


76:: Newton’s laws are still being violated by environment.cxx.

The pressure profile (P versus h) is incorrect. This has many
consequences. It greatly affects altimetery, but also affects
engine performance, airfoil performance, et cetera. In particular
it means the simulator fails to exhibit the HALT phenomenon
(high altimeter because of low temperature).

For quantitative details on this, see
http://www.av8n.com/fly/fgfs/htm/bug-list.htm

This bug has been known for years. The code to fix it was written
years ago, but not incorporated.


77:: In the default c172p model, sitting on the runway at KSFO, at
full power the engine consumes about 78 pph of fuel. So far, so good.

Now stop the engine by pulling the mixture to cutoff. I observe that
the fuel flow, as reported by the FDM via the property tree, settles
above 8 pph. That’s more than a gallon per hour, with no mixture and
no revs. That seems like rather a large leak.

Similar phenomena have been observed in other aircraft models.


78:: As of 1.9.0, in the c182rg, I observe that the menu item "reload
panel" doesn’t reload the panel. Shift-F3 doesn’t reload the panel
either.

[Ron Jensen]

Post by John Denker
77:: In the default c172p model, sitting on the runway at KSFO, at
full power the engine consumes about 78 pph of fuel. So far, so good.
Now stop the engine by pulling the mixture to cutoff. I observe that
the fuel flow, as reported by the FDM via the property tree, settles
above 8 pph. That’s more than a gallon per hour, with no mixture and
no revs. That seems like rather a large leak.
Similar phenomena have been observed in other aircraft models.

In the code FuelFlow_gph is the canonical property, FuelFlow_pph is only
calculated when we actually consume fuel. Slamming the mixture to 0 at
a high fuel flow rate causes consumption to stop leaving the
FuelFlow_pph value unable to update and stuck indicating a high value.

If you'll notice, fuel is not actually flowing, its just an incorrect
indication.

Ron

[Jon S. Berndt]

Post by Ron Jensen
In the code FuelFlow_gph is the canonical property, FuelFlow_pph is only
calculated when we actually consume fuel. Slamming the mixture to 0 at
a high fuel flow rate causes consumption to stop leaving the
FuelFlow_pph value unable to update and stuck indicating a high value.
If you'll notice, fuel is not actually flowing, its just an incorrect
indication.
Ron

Still, this sounds like a code bug. I'll take a look.

Jon

[John Denker]

79:: Let’s do an ordinary preflight runup in the c182rg. With the
prop control full forward, advance the throttle to 1700 rpm in
accordance with the POH checklist. Now pull the prop control full
back. In the Sim World as of 1.9.0, I observe the RPM drops from 1700
to 1400. This is highly unrealistic, because in the Real World, the
drop is much greater; I estimate the low RPM is down around 900 or
so.

As a related observation, with the SW throttle all the way back, the
property tree says that the governor is regulating the propeller at
900 rpm. That is, the propeller pitch is not on the fine-pitch stop,
even with the throttle all the way back, with the engine developing
only 10% of its rated shaft horsepower. This is highly unrealistic.
As previously mentioned, 900 RPM is about the right number, but the
prop really should be on the fine-pitch stop.

Advancing the throttle a tiny bit above idle causes the prop to hit
the coarse-pitch stop.

This suggests there is something wrong with the propeller model.

There is no chance that this problem is related to bug 80. The
propeller is misbehaving as a function of shaft power, and if you
know the shaft power, it doesn’t matter what throttle setting or
other settings produced that power.

80:: As of 1.9.0, in the c182rg on the runway at KSFO, I observe
that with the throttle wide open the MAP is 29.97. With the throttle
pulled back to 0.6, the MAP is still 29.97. This is wildly
unrealistic. Similar problems in the c172p model have been reported.
In the Real World, the throttle is a butterfly valve; flowing a large
amount of air through a half-closed butterfly valve causes a large
pressure drop. Any RW pilot would notice this before takeoff, and
would conclude that the throttle (or throttle linkage) was broken.

This problem almost certainly results from an unphysical model
embodied in the .cxx code. The code does not model the throttle as a
valve. As a consequence, no amount of fiddling with the engine
configuration .xml files will fix this problem.

There is no chance that this problem is related to bug 79.

81:: Consider the case where FlightGear is run with the
--disable-ai-models command line option.

It appears that some of the ai-related code continues to run. You can
easily verify by turning on log-level=info, in which case you will
see screen after screen of “scheduling” messages. The messages refer
to “scheduling” events many days in the future. I reckon they shouldn't
be scheduled at all when the ai-models feature is turned off.

For additional details, see
http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-ai-scheduling

[Ron Jensen]

Post by John Denker
80:: As of 1.9.0, in the c182rg on the runway at KSFO, I observe
that with the throttle wide open the MAP is 29.97. With the throttle
pulled back to 0.6, the MAP is still 29.97. This is wildly
unrealistic. Similar problems in the c172p model have been reported.
In the Real World, the throttle is a butterfly valve; flowing a large
amount of air through a half-closed butterfly valve causes a large
pressure drop. Any RW pilot would notice this before takeoff, and
would conclude that the throttle (or throttle linkage) was broken.

Since you don't list an RPM, let me suggest at 0 rpm this is the desired
behavior :). You're suggesting we're flowing a large amount of air
through a half closed valve, but without an RPM I can't verify this.
Also, you don't mention what the ambient pressure at KSFO is. Its been
running about 30+ inHg of late if you have real weather turned on.

Please don't duplicate your bug reports, especially as this has been
fixed up stream, you are just generating noise here.

Post by John Denker
81:: Consider the case where FlightGear is run with the
--disable-ai-models command line option.
It appears that some of the ai-related code continues to run. You can
easily verify by turning on log-level=info, in which case you will
see screen after screen of “scheduling” messages. The messages refer
to “scheduling” events many days in the future. I reckon they shouldn't
be scheduled at all when the ai-models feature is turned off.

This is not a bug. ai-models refers explicitly to the 3D models, which
are used by scenarios, multiplayer and AI traffic. AI traffic
scheduling is done by the traffic-manager. You want
--prop:/sim/traffic-manager/enabled=0

Post by John Denker
For additional details, see
http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-ai-scheduling

[John Denker]

Post by Ron Jensen
this has been
fixed up stream,

Wow. That's great. Perhaps I overlooked the announcement.

Will the fix be coming downstream anytime soon?

Is there any other news we should know about.

[Brian Schack]

81:: Consider the case where FlightGear is run with the
--disable-ai-models command line option.
It appears that some of the ai-related code continues to
run. You can easily verify by turning on log-level=info, in
which case you will see screen after screen of ?scheduling?
messages. The messages refer to ?scheduling? events many days
in the future. I reckon they shouldn't be scheduled at all when
the ai-models feature is turned off.

Ron> This is not a bug. ai-models refers explicitly to the 3D
Ron> models, which are used by scenarios, multiplayer and AI
Ron> traffic. AI traffic scheduling is done by the
Ron> traffic-manager. You want
Ron> --prop:/sim/traffic-manager/enabled=0

I've noticed that with AI traffic turned on, there is a constant
setting and resetting of the time accessed by
globals->get_time_params(), presumably as a result of events scheduled
"many days in the future" that John mentioned in his post. This
doesn't seem to cause any obvious problems in FlightGear, but this
does cause Atlas to get horribly confused when connected to FlightGear
- the time-stamped messages it receives jump all over the place. With
AI traffic turned off, the problem goes away.

Assuming that AI traffic is indeed the source of the problem, is there
any way to tell the AI aircraft not to reset the clock? Or,
alternatively, is there a pristine time source that the atlas.cxx code
can use, instead of globals->get_time_params()?

Brian

[Erik Hofman]

Post by Brian Schack
I've noticed that with AI traffic turned on, there is a constant
setting and resetting of the time accessed by
globals->get_time_params()

This sounds like a misplaced leading slash in a property for AI models
to me.

Erik

[John Denker]

I quote from
http://www.av8n.com/fly/fgfs/htm/bug-list.htm


80:: As of mid-January 2008, there is a “new” version of
FGPiston.cpp floating around. It has not yet been committed to
FlightGear CVS. It gets rid of the specific problems mentioned in bug
79, replacing them with new and different unrealistic behaviors.
For one thing, it causes many FG aircraft – including the c172p – to
idle at very low revs, or stall completely.

It is not realistic at high throttle settings either. In the FG
"flagship" c172p for example, on the runway at KSFO, full throttle,
standard say, it develops 1205368 ft density altitude, standard day,
full throttle, it develops 104

Unlike the “old” version mentioned in bug 79, the “new” version
pretends to model the physics of the throttle. Alas, it is a very
thin pretense. It uses physicsy-sounding words like ThrottleAngle and
throttle_area, but these are only words. The code that computes them
bears no discernible relationship to real physics. This is
particularly odd, since the physics was worked out some time ago and
shows remarkably good agreement between the model and Real World
data. This is explained at ../../engine.htm.

Code to implement a reasonable physics-based throttle model exists.
It does not fix all the bugs in FGPiston.cpp, but it is a step in the
right direction.

81:: The FlightGear interface to the festival text-to-speech
server is documented in section 5.6.2 of the getstart manual. I
observe that it doesn’t work (even though the festival server itself
works fine when FG is not running). It hasn’t worked for years. I
have never heard of anyone actually using it.

The TTS idea would be a lot more useful if it were integrated via the
c++ API as documented at
http://www.speech.cs.cmu.edu/festival/manual-1.4.1/festival_28.html

82:: Choppy video and sound. I observe that things work fine when
the FlightGear window is the default size, 800x600. The frame rate is
in the range 45 to 50. However, if I enlarge the window even
slightly, e.g. 1000x750, things go to pot. The reported frame rate
(as given by the orange number in the lower-right corner) drops to
around 30, which wouldn’t be so bad except that the actual frame rate
drops to around 5. That is to say, the video becomes horribly choppy.
The sound also becomes horribly choppy, to the point where the ATIS
and IDENT features are unusable.

No error messages, no warnings, just choppy video and sound.

I observe that things work much better using the command-line option
–prop:/sim/frame-rate-throttle-hz=30.

This is observed using an ATI RV350 [Mobility Radeon 9600] and the
proprietary fglrx driver. (The last time I checked, the xorg radeon
driver was not an option, since it lacked some required
capabilities.)

83:: The Environment system is in need of some TLC.

For one thing, FlightGear appears to have several different models of
the atmosphere.

0) The FDM has its own model, but this is sometimes turned off and
the FDM is slaved to the FG model, so maybe this one shouldn’t even
count.

1) The popup GUI has its own model of the atmosphere. It is a very
complicated model with approximately seven layers just within the
troposphere. This GUI has been used, with some success, to specify
multiple layers of clouds. However, the GUI imparts the distinct
impression that users can independently set the temperature and
pressure in each layer, which is a wild violation of the laws of
physics.

The backend performs complex calculations based on the pressure and
temperature numbers provided by the GUI, but this is all in vain. The
results of almost all these calculations are ignored.

2) There also exists an inchoate "METAR" interface. The relationship
between this and the popup GUI is complex and buggy.

This holds out some hope of a future interface that makes sense, i.e.
multiple layers of clouds plus a two-parameter model of the
atmosphere.

3) The code that calculates the actual static pressure seen by the
airplane ignores almost all of the many numbers provided by the GUI.

I can’t decide whether this is one-parameter model or a two-parameter
model. It purports to be a two-parameter model, but it ignores one of
them. Specifically, it ignores the temperature when calculating the
pressure-versus-height profile, in defiance of the laws of physics.
This is a bug.

This model is tabulated, and ends abruptly at around 100,000 feet.
Some modelers find this limitation to be a problem.

What’s more, it takes the “zero AGL” number from the GUI and uses it
as if it were the “zero MSL” number. This is another bug.

4) The altimeter has its own model. This is a highly accurate
algebraic (not tabulated) model. It is currently valid to the top of
the stratosphere, but could easily be extended to the top of the
mesosphere. (A patch to do this exists.)

Code exists to provide FlightGear with a highly accurate
two-parameter model of the atmosphere, valid up to 262,467 feet, i.e.
80 kilometers, i.e. the top of the mesosphere. This gets rid of
several bugs in the current model. It uses the same code as the
current altimeter.

========================

For additional details and context, see
http://www.av8n.com/fly/fgfs/htm/bug-list.htm

[Erik Hofman]

Post by John Denker
I quote from
http://www.av8n.com/fly/fgfs/htm/bug-list.htm
80:: As of mid-January 2008, there is a “new” version of
FGPiston.cpp floating around. It has not yet been committed to
FlightGear CVS. It gets rid of the specific problems mentioned in bug
79, replacing them with new and different unrealistic behaviors.
For one thing, it causes many FG aircraft – including the c172p – to
idle at very low revs, or stall completely.

This is fixed by using the corresponding engine configurtion file.

Post by John Denker
It is not realistic at high throttle settings either. In the FG
"flagship" c172p for example, on the runway at KSFO, full throttle,
standard say, it develops 1205368 ft density altitude, standard day,
full throttle, it develops 104

This might be the same, please report bug for committed code only.

Erik

[Melchior FRANZ]

Post by John Denker
81:: The FlightGear interface to the festival text-to-speech
server [...] doesn’t work [...] It hasn’t worked for years. I
have never heard of anyone actually using it.

Works for me since years.

m.

[Martin Spott]

Post by Melchior FRANZ

Post by John Denker
81:: The FlightGear interface to the festival text-to-speech
server [...] doesn???t work [...] It hasn???t worked for years. I
have never heard of anyone actually using it.

Works for me since years.

Someone who's using this feature might check if chapter 5.6 of The
Manual is still up to date and, if this is not the case, provide fixes,

Martin.

[Tatsuhiro Nishioka]

Hi,

Post by James Turner

Post by Frederic Bouvier

Post by Tim Moore
After 2.0 I'll start merging in my Effects framework code that will
make, among other things, local light sources practical. I'm not
sure if the best way to do cockpit lighting is to have a light
source in the cockpit or to simply turn up
the emissiveness of the instruments and dashboard...

I don't think there will be a 2.0 anytime soon. It took 10 years to
have
v1.0 . I hope you mean 1.99.5

Heh, I was wondering about this - I'm hopeful that Tim means what he
wrote, but that 2.0 will also be along soon, maybe even Q1 2009. And
then 2.1, 2.2

I guess Tim means 1.9.0, not 2.0.

Actually 1.99.5 is just a temporal number for fgfs/cvs and (I believe)
we're heading to 1.9.0. Curt told us that he put 1.99.5 since he had
missed the discussion on this list about the version number for the
first OSG release. This is why I gave 1.9.0-preN to mac binaries.

Got confused? The final dicision will be made soon, so we'll see.

Anyway, shorter release cycle can give flightgear a chance to get more
attension, so I like that idea. If quarterly releasing cycle is a bit
too often, then semiannual is fine for me.

What do you guys think?

Tat

[Curtis Olson]

On Tue, Dec 16, 2008 at 9:42 AM, Tatsuhiro Nishioka

Post by Tatsuhiro Nishioka
I guess Tim means 1.9.0, not 2.0.
Actually 1.99.5 is just a temporal number for fgfs/cvs and (I believe)
we're heading to 1.9.0. Curt told us that he put 1.99.5 since he had
missed the discussion on this list about the version number for the
first OSG release. This is why I gave 1.9.0-preN to mac binaries.
Got confused? The final dicision will be made soon, so we'll see.
Anyway, shorter release cycle can give flightgear a chance to get more
attension, so I like that idea. If quarterly releasing cycle is a bit
too often, then semiannual is fine for me.
What do you guys think?

Personally, I think a big build up to an oddball version number like 1.99.5
is a little strange, but again, I'm not so hung up on version numbers as
long as they keep increasing. It would also be odd to backtrack since the
point of version numbers is to distinguish releases in some logical order.
I had in my mind that there would be a 1.99.x release sequence as a build up
to a major v2.0 release (rather than 1.99.5-rcX building up to a v1.99.5
release.) So there are some crossed wires here that unfortunately is
leading to a weird version number situation.

In the meantime, I have been working on a script that will streamline the
release process a bit. My hope is to start doing more frequent source
releases once this major release is pushed out the door.

Regards,

Curt.

[James Turner]

Post by Tatsuhiro Nishioka
Anyway, shorter release cycle can give flightgear a chance to get more
attension, so I like that idea. If quarterly releasing cycle is a bit
too often, then semiannual is fine for me.
What do you guys think?

Quarter annual at least, if not every two months. My reason is selfish
- I'd like it be understood that CVS is for compiled code development,
and things to be really changing, so C++ changes can be worked on
without upsetting aircraft developers or users. It could even be
possible to make interim releases with only the base package changed.

I'd like a rate fast enough that nightly builds / CVS snapshots become
almost unnecessary, and counter-productive - because CVS is never that
far from a release. Hopefully this would allow some proper testing of
code changes before a release, and easier targeting if a bug makes to
an official release: 'blah worked fine in 2.5, you've broken in in 2.6-
rc1' knowing there's only a couple of months of commits to check
through to identify the cause.

Keep in mind that by release I mean something almost entirely
automatic - there should be a script that tags, branches, creates a
tarballs, and uploads, and hopefully Fred and you can similarly create
the builds with little or no manual intervention. Clearly a rapid
release cycle will never happen if 'doing a release' is a day of
someone's time.

James

[Frederic Bouvier]

On Tue, Dec 16, 2008 at 9:42 AM, Tatsuhiro Nishioka <
I guess Tim means 1.9.0, not 2.0.
Actually 1.99.5 is just a temporal number for fgfs/cvs and (I believe)
we're heading to 1.9.0. Curt told us that he put 1.99.5 since he had
missed the discussion on this list about the version number for the
first OSG release. This is why I gave 1.9.0-preN to mac binaries.
Got confused? The final dicision will be made soon, so we'll see.
Anyway, shorter release cycle can give flightgear a chance to get more
attension, so I like that idea. If quarterly releasing cycle is a bit
too often, then semiannual is fine for me.
What do you guys think?
Personally, I think a big build up to an oddball version number like
1.99.5 is a little strange, but again, I'm not so hung up on version
numbers as long as they keep increasing. It would also be odd to
backtrack since the point of version numbers is to distinguish
releases in some logical order. I had in my mind that there would be a
1.99.x release sequence as a build up to a major v2.0 release (rather
than 1.99.5-rcX building up to a v1.99.5 release.) So there are some
crossed wires here that unfortunately is leading to a weird version
number situation.
In the meantime, I have been working on a script that will streamline
the release process a bit. My hope is to start doing more frequent
source releases once this major release is pushed out the door.

For the moment, the really strange thing is that the mac version has
another numbering scheme. If we are pushing for a more frequent release
rate, maybe the -rcX thing should be skipped and fix bugs from release
to release. That also means that the aircraft list should be frozen in
order to capitalize on experience.

-Fred

[Tatsuhiro Nishioka]

Hi guys,

Post by Frederic Bouvier

Post by Curtis Olson
Personally, I think a big build up to an oddball version number like
1.99.5 is a little strange, but again, I'm not so hung up on version
numbers as long as they keep increasing. It would also be odd to
backtrack since the point of version numbers is to distinguish
releases in some logical order.

We had a change to revert the version back to 1.8.x or something before releasing 1.99.5-rc1 thing, didn't we?

Post by Frederic Bouvier

Post by Curtis Olson
I had in my mind that there would be a
1.99.x release sequence as a build up to a major v2.0 release (rather
than 1.99.5-rcX building up to a v1.99.5 release.) So there are some
crossed wires here that unfortunately is leading to a weird version
number situation.

And you are a person who can fix it up.

Post by Frederic Bouvier

Post by Curtis Olson
In the meantime, I have been working on a script that will streamline
the release process a bit. My hope is to start doing more frequent
source releases once this major release is pushed out the door.

For the moment, the really strange thing is that the mac version has
another numbering scheme.

This is because we don't have any clear versioning policy, and I really don't want to
buy such meaningless number as an official release. I thought that pushing for
having clear versioning policy should be after the release, but I take it back.
We really need a clear versioning policy.

I already asked once or twice that we need to settle the official release number soon, but none did.
That's why I stayed in 1.9.0 with respect to the result of the discussion made in this list.

I already told Curt that we need to have versioning policy before going to make scripts for automatic release process.
Automation for the release is basically good, but if that is the cause of using such a weird number,
We better not use it.

What does 5 in 1.99.5 mean?
Did we release 1.99.0 or 1.99.1? No!!

Please do not use such a weird meaningless version number.
Curt, please think twice. I never want to buy 1.99.5 number at all.
It doesn't have to be 1.9.0, but 1.99.5 is way too bad!

Is it only me who thinks we are facing to very weird and confusing situation?
And do you think that a different version number on FG/Mac is the cause of this?
If many think so, I'm very very sad.

Post by Frederic Bouvier
If we are pushing for a more frequent release
rate, maybe the -rcX thing should be skipped and fix bugs from release
to release. That also means that the aircraft list should be frozen in
order to capitalize on experience.

If we have a release branch, I totally agree with this idea.


Tat

[Durk Talsma]

Hi Tat et al.,

Post by Tatsuhiro Nishioka
Hi guys,

Post by Curtis Olson
Personally, I think a big build up to an oddball version number like
1.99.5 is a little strange, but again, I'm not so hung up on version
numbers as long as they keep increasing. It would also be odd to
backtrack since the point of version numbers is to distinguish
releases in some logical order.

Just to make a blunt suggestion, although not completely of my own
imagination: would it be an idea to release this version as 2.0?. Initially,
we wanted to do a 1.9.0 release, because we felt that the OSG transition
wasn't quite there yet. Since then, enormous progress has been made, in
particular in the 3D clouds departments. So given this unexpected progress,
would labeling this release as 2.0 be a viable option? I know that Curt's
been in favor of calling this release 2.0. I initially was a bit more
reluctant, but given the enormous progress, I have to say I'd be open to the
suggestion.

I agree with Tat that we need to think of a good versioning system for future
releases.

Cheers,
Durk

[Jon Stockill]

Post by Durk Talsma
Just to make a blunt suggestion, although not completely of my own
imagination: would it be an idea to release this version as 2.0?. Initially,
we wanted to do a 1.9.0 release, because we felt that the OSG transition
wasn't quite there yet. Since then, enormous progress has been made, in
particular in the 3D clouds departments. So given this unexpected progress,
would labeling this release as 2.0 be a viable option? I know that Curt's
been in favor of calling this release 2.0. I initially was a bit more
reluctant, but given the enormous progress, I have to say I'd be open to the
suggestion.
I agree with Tat that we need to think of a good versioning system for future
releases.

There are still problems with the clouds (the draw order problem with
particles), and Tim has already mentioned his intention to start
committing the code required for shadows after this release. I believe
that code also makes landing lights a possibility. I'd be tempted to
make the first release including both of those features 2.0

Jon

[Heiko Schulz]

Post by Jon Stockill
There are still problems with the clouds (the draw order
problem with
particles), and Tim has already mentioned his intention to
start
committing the code required for shadows after this
release. I believe
that code also makes landing lights a possibility. I'd
be tempted to
make the first release including both of those features 2.0
Jon

I agree!

I'm pretty fine with 1.99.5 - with these announces by Tim with shadows, light sources, the improvements by Yon we really should wait.
I can remember that we wnated to have 1.0.0 when we have landing lights. So this time we should really name it 2.0.0 when we have back the shadows and maybe the landinglights.

[Melchior FRANZ]

Post by Durk Talsma
would it be an idea to release this version as 2.0?.

I'm against that. fgfs is in acceptable shape for a minor
release, but it would be an embarrassment for a major release.
Curt says he doesn't care about version numbers, but the
"community" certainly does. 2.0 sounds like a big(ger) step
forward, and at the moment I don't see that. Just teleport
or reset and you are likely to run into your terminal being
flooded with NaN messages, from which you can only escape
by aborting. That doesn't sound like 2.0 material, and I
don't think it will be fixed by the weekend. Rushing out
releases is never a good idea, but it's especially bad
for a major "symbolic" release. 0.95 (or something like that)
would be OK -- as a kind of preview for the "big release".

Before we drop the 0.9* idea, I'd rather defer the release
a few months. If we don't want that release numbers imply
anything other than "next step", then we have to just number
them 1..infinity or label them with their release date,
without "major", "minor" numbers. Otherwise there *is* a
meaning to about anyone, whether we like it or not.

m.

[Melchior FRANZ]

[...] 0.95 (or something like that)

Err ... 1.95

Before we drop the 0.9* idea, [...]

and 1.9*. But I guess you got the idea. :-)

m.

[Michael Smith]

Ok, this might be a silly question but here it goes, Will the final 1.99
release be on the main flightgear website and replace 1.0 on the site?

Thanks

[Durk Talsma]

Post by Durk Talsma
Just to make a blunt suggestion, although not completely of my own
imagination: would it be an idea to release this version as 2.0?.
Initially, we wanted to do a 1.9.0 release, because we felt that the OSG
transition wasn't quite there yet. Since then, enormous progress has been
made, in particular in the 3D clouds departments. So given this unexpected
progress, would labeling this release as 2.0 be a viable option? I know
that Curt's been in favor of calling this release 2.0. I initially was a
bit more reluctant, but given the enormous progress, I have to say I'd be
open to the suggestion.

Okay, of the people who responded, the vote was unanimously against this idea.
If it's up to me, I vote for going back to our original consensus, and
releasing this version as 1.9.0. As far as I can tell, this number has the
majority vote, and although not Curt's preference, he can live with it.

To be honest, I personally would also not be too happy with the 2.0 version
number yet.

Cheers,
Durk

[Melchior FRANZ]

Post by Durk Talsma
I vote for going back to our original consensus, and
releasing this version as 1.9.0.

Sounds good to me. With the subtitle: "technology preview;
test it, fire up your editors and fix all the bugs". :-)

1.95 would also have worked for me, but 1.99.5 is really
a bit far-fetched.

m.

[Stuart Buchanan]

Post by Durk Talsma
Okay, of the people who responded, the vote was unanimously against this idea.
If it's up to me, I vote for going back to our original consensus, and
releasing this version as 1.9.0. As far as I can tell, this number has the
majority vote, and although not Curt's preference, he can live with it.

OK. I'll update the manual source to say 1.9.0 rather than 1.99.5.

Durk - if you change your mind right before the release, can you make sure
that Martin has checked in a new version of the manual with the new version
number.

Martin - I'll assume you are happy to generate the manual for the release and
check it in. Let me know if you're too busy.

-Stuart

[Martin Spott]

Post by Stuart Buchanan
Martin - I'll assume you are happy to generate the manual for the release and
check it in.

Definitely .... yet I didn't recieve any updates for The Manual from
John D., though ;-)

Martin.

[Bohnert Paul]

All,

I spent a couple of hours installing all the latest updates. According to the Mirosoft Update site I'm up to date.

I loaded FlightGear-1.99.5-RC2 on my Windows XP Pro. SP3 box.

FlightGear will not start. Missing MSVCR71.dll not found error.

Is this a file I should have?


Best Regards,

Paul B.

[Tatsuhiro Nishioka]

Hi,

So we three are all busy around the release date :-)

I'm OK if it will be either Friday or Saturday, or even after that. I
need to make some tests before the release, but this time it can be
slow since my spare time for FG is very limited in a given time frame.
So the Mac version will be released hopefully within a week after the
source code release.

Curt, please give the official version number until the release.

And I wish all of you have a happy holiday.

-----
Tatsuhiro Nishioka

Post by Durk Talsma
Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may have
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I have a
Christmas dinner this Friday, so I won't be able assemble the final
release by
then. Saturday will be fine for me, so I hope to roll up the release
then.
Cheers,
Durk

[Richard Hornby]

I have just run 1.9.RC2 from your dowload site for the first time.
First, continued thanks for your work in making this distro.

I am getting 'consistent' crashes with all the non-yasim A/C. To
put it another way, only the Yasim A/C are working.

Attached are the first few lines of the crash report of various JSB
sim A/C

Zero, Cessna 172, Moyes Dragonfly, Kawasaki T4, Zeppelin

Path: /Applications/FlightGear.app/Contents/Resources/fgfs
Identifier: fgfs
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: FlightGear [524]

Date/Time: 2008-12-19 08:55:45.432 +0000
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6

Exception Type: EXC_SOFTWARE (SIGTRAP)
Exception Codes: 0x0000000000000007, 0x0000000000000000
Crashed Thread: 2


Cessna 172 (2D)

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread: 0


Seneca II

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffffff4
Crashed Thread: 2


And on other sim types: -

Camel (both versions, Larcsim) - as for Zero, etc

FG Video assistant

EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000027aaf890
Crashed Thread: 0

UFO - no crash report

I have installed this straight from the box - no tweaks or prefs.

I upgraded to the latest Mac OS X release yesterday.

Can send a full crash log off-net if you want.

Brgds,

R

[Tatsuhiro Nishioka]

Hi,

Thanks for the report.

Please send me the crash logs.
I need to take a look at these.

I'll also update OSX tomorrow and see what's going on.


-----
Tatsuhiro Nishioka

On Dec 19, 2008, at 6:19 PM, Richard Hornby

Post by Richard Hornby
I have just run 1.9.RC2 from your dowload site for the first time.
First, continued thanks for your work in making this distro.
I am getting 'consistent' crashes with all the non-yasim A/C.
To put it another way, only the Yasim A/C are working.
Attached are the first few lines of the crash report of various JSB
sim A/C
Zero, Cessna 172, Moyes Dragonfly, Kawasaki T4, Zeppelin
Path: /Applications/FlightGear.app/Contents/Resources/fgfs
Identifier: fgfs
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: FlightGear [524]
Date/Time: 2008-12-19 08:55:45.432 +0000
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6
Exception Type: EXC_SOFTWARE (SIGTRAP)
Exception Codes: 0x0000000000000007, 0x0000000000000000
Crashed Thread: 2
Cessna 172 (2D)
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread: 0
Seneca II
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffffff4
Crashed Thread: 2
And on other sim types: -
Camel (both versions, Larcsim) - as for Zero, etc
FG Video assistant
EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000027aaf890
Crashed Thread: 0
UFO - no crash report
I have installed this straight from the box - no tweaks or prefs.
I upgraded to the latest Mac OS X release yesterday.
Can send a full crash log off-net if you want.
Brgds,
R
---
---
---
---------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Frederic Bouvier]

Post by Durk Talsma

Post by Durk Talsma
Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may have
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I have

a

Post by Durk Talsma
Christmas dinner this Friday, so I won't be able assemble the final

release

Post by Durk Talsma
by then. Saturday will be fine for me, so I hope to roll up the

release

Post by Durk Talsma
then.
Cheers,
Durk

Hello, Durk
How do you schedule the period test with OSG 2.8 before rolling up
the
release ?
OR do you avoid any test with it ?

A lot of people are already using OSG/SVN. So tests are going on under the hood.

-Fred

[gerard robin]

Post by Frederic Bouvier

Post by Durk Talsma

Post by Durk Talsma
Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may have
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I have

a

Post by Durk Talsma
Christmas dinner this Friday, so I won't be able assemble the final

release

Post by Durk Talsma
by then. Saturday will be fine for me, so I hope to roll up the

release

Post by Durk Talsma
then.
Cheers,
Durk

Hello, Durk
How do you schedule the period test with OSG 2.8 before rolling up
the
release ?
OR do you avoid any test with it ?

A lot of people are already using OSG/SVN. So tests are going on under the hood.
-Fred

Sorry for that question which seems to annoy everybody.
I agree, the question was not realistic and not constructive, it was stupid.
I am glad to know that there is a LOT of persons testing it.
:) :)

Merry Christmas :)
See you next year.

[Frederic Bouvier]

Post by Heiko Schulz

Post by Frederic Bouvier

Post by Durk Talsma

Post by Durk Talsma
Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may

have

Post by Frederic Bouvier

Post by Durk Talsma

Post by Durk Talsma

Post by Frederic Bouvier
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I

have

Post by Frederic Bouvier

Post by Durk Talsma
a

Post by Durk Talsma
Christmas dinner this Friday, so I won't be able assemble the

final

Post by Frederic Bouvier

Post by Durk Talsma
release

Post by Durk Talsma
by then. Saturday will be fine for me, so I hope to roll up the

release

Post by Durk Talsma
then.
Cheers,
Durk

Hello, Durk
How do you schedule the period test with OSG 2.8 before rolling

up

Post by Frederic Bouvier

Post by Durk Talsma
the
release ?
OR do you avoid any test with it ?

A lot of people are already using OSG/SVN. So tests are going on

under the

Post by Frederic Bouvier
hood.
-Fred

Sorry for that question which seems to annoy everybody.
I agree, the question was not realistic and not constructive, it was
stupid.
I am glad to know that there is a LOT of persons testing it.
:) :)
Merry Christmas :)
See you next year.

Is it me or are you implying you are the only one to care, and there are nobody at the moment committing patches and building binaries for the community ?

Anyway merry christmas.

-Fred

[gerard robin]

Post by Frederic Bouvier

Post by Heiko Schulz

Post by Frederic Bouvier

Post by Durk Talsma

Post by Durk Talsma
Hi Fred,

Post by Frederic Bouvier
I replied that the target is next Friday. After that I may

have

Post by Frederic Bouvier

Post by Durk Talsma

Post by Durk Talsma

Post by Frederic Bouvier
difficulties to build a binary from where I will be.
-Fred

How would your availability be after Friday. As it turns out, I

have

Post by Frederic Bouvier

Post by Durk Talsma
a

Post by Durk Talsma
Christmas dinner this Friday, so I won't be able assemble the

final

Post by Frederic Bouvier

Post by Durk Talsma
release

Post by Durk Talsma
by then. Saturday will be fine for me, so I hope to roll up the

release

Post by Durk Talsma
then.
Cheers,
Durk

Hello, Durk
How do you schedule the period test with OSG 2.8 before rolling

up

Post by Frederic Bouvier

Post by Durk Talsma
the
release ?
OR do you avoid any test with it ?

A lot of people are already using OSG/SVN. So tests are going on

under the

Post by Frederic Bouvier
hood.
-Fred

Sorry for that question which seems to annoy everybody.
I agree, the question was not realistic and not constructive, it was
stupid.
I am glad to know that there is a LOT of persons testing it.
:) :)
Merry Christmas :)
See you next year.

Is it me or are you implying you are the only one to care, and there are
nobody at the moment committing patches and building binaries for the
community ?
Anyway merry christmas.
-Fred

Fred,
I only apologized regarding my question (a stupid question which got, from
you, the suitable answer).
I know, that, the effort i did, to get the right computer/configuration in
order to build FG with OSG 2.75, and the feedback that i gave about the new
3D Clouds with Metar, was not useful.
In anycase less useful than your contributions, like you suggested.
Anyhow, i am leaving out, from any computer until next year.

Greetings to everybody

[Frederic Bouvier]

Post by Bohnert Paul
All,
I spent a couple of hours installing all the latest updates.
According to the Mirosoft Update site I'm up to date.
I loaded FlightGear-1.99.5-RC2 on my Windows XP Pro. SP3 box.
FlightGear will not start. Missing MSVCR71.dll not found error.
Is this a file I should have?

This is the C runtime. You can get a copy here :
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71
and you will need
http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71

-Fred