[Flightgear-devel] Debugging under CygWin
Can any of you debug FlightGear using the CygWin GDB? Whenever I try, I can use the basic functions (stepping, breakpoints, view source code, etc) if I am very careful to treat it gently, but when FlightGear crashes GDB tends to crash too. I am using version 20010428-3 and I use the GUI (Insight) but I think it's the underlying GDB itself that usually crashes. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight.hxx accessors
John Wojnaroski wrote: Also can't find where the baro/altimeter setting is to correct for density altitude. Tried searching on barometric, kollsman, etc nada. (I'd like to but a vowel) ;-) Look for datum or subscale in Cockpit/steam.cxx, where the altimeter reading is calculated. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Altitude Calculation
John Wojnaroski wrote:
In steam.cxx the pressure datum is set to some setting that represents
atmospheric pressure. Okay, so far
But can't find any connection between the two.
...
In the present FlightGear code, the atmospheric pressure (the_STATIC_inhg) used to
calculate the altimeter reading is itself calculated from the altitude by a simple
formula. This may seem pointless or confusing. The only reason it converts altitude
to pressure and then back to altitude (and does not just display the known altitude
directly) is to prepare for when we will replace the first part of this calculation.
In FGSteam::_CatchUp() we need to replace the pressure calculation with something like:
sgVec3 plane_pos = { cur_fdm_state-get_Latitude(),
cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Altitude() * SG_FEET_TO_METER };
double static_inhg = WeatherDatabase-get(plane_pos).AirPressure * (0.01 /
INHG_TO_MB);
set_lowpass ( the_STATIC_inhg, static_inhg, dt );
This will drive the altimeter directly from the pressure given by Christian Meyer's
weather model. I have tried this and it gives good results.
My guess is that the actual variations in pressure gradients (Highs and
Lows) is not modeled and we fly in a
uniform atmosphere so that runway elevation at KLAX and KJFK have the same
baro setting. Which says I can
use the altimeter value set at takeoff to runway elevation as the *elev*
value to calculate navigational positions, ranges, and
things like glideslope positions. And this is also the *h* value used in the
EOMs.
Is this correct? Or is there a non-uniform atmospheric model corrected for
local temperature and pressure?
I don't know what *h* or *elev* or EOM are, or what kind of atmosphere variations are
modelled.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base package CVS: read lock failed
Still happening just the same. Is it my fault? - Julian John Check wrote: On Wednesday 16 January 2002 04:28 pm, you wrote: Does this indicate a problem on the base package CVS server? ... cvs server: Diffing Aircraft/X15/Panels cvs server: Diffing Aircraft/X15/Panels/Textures cvs server: Diffing Aircraft/c172 cvs server: Diffing Aircraft/c172/Instruments cvs server: failed to create lock directory in repository `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments': No such file or directory cvs server: failed to obtain dir lock in repository `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments' cvs [server aborted]: read lock failed - giving up - Julian OOps, somebody added directories.. will fix shortly ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Auto-generated files in CVS
This has been discussed before and I don't recall any reason why these auto-generated files should be in CVS. If this is the case please could someone remove them. SimGear: aclocal.m4 simgear/simgear_config.h.in FlightGear: aclocal.m4 src/Include/config.h.in - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem compiling recent Simgear CVS
Until this is fixed properly, you can fix this by adding the line: AC_PREREQ(2.13) at the beginning of configure.in, just after the dnl ... lines which are comments. At least, this works for me. - Julian Michael Basler wrote: Hi, when I tried to build CVS Simgear today, I got with autogen.sh: -- Michael Basler@MICHAEL /usr/local/source/simgear $ ./autogen.sh Host info: CYGWIN_NT-5.1 i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/xml/Makefile.am: INCLUDES must be set with `=' before using `+=' Running autoconf configure.in:18: error: possibly undefined macro: AC_SG_SET_COMPILER == ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base package CVS: read lock failed
Thanks, John - that fixes it. I suppose CVS didn't delete it because I had made modifications in it. I'd expect it to say so, though! - Julian John Check wrote: just did cvs up -dP and no problems. Try deleting your c172/Instruments directory, it's no longer relevant. TTYL J On Wednesday 16 January 2002 04:28 pm, you wrote: Does this indicate a problem on the base package CVS server? ... cvs server: Diffing Aircraft/X15/Panels cvs server: Diffing Aircraft/X15/Panels/Textures cvs server: Diffing Aircraft/c172 cvs server: Diffing Aircraft/c172/Instruments cvs server: failed to create lock directory in repository `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments': No such file or directory cvs server: failed to obtain dir lock in repository `/home/cvsroot/FlightGear/FlightGear/Aircraft/c172/Instruments' cvs [server aborted]: read lock failed - giving up ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: AW: [Flightgear-devel] Problem compiling recent Simgear CVS
Now I've got another problem with it. I don't seem to need the AC_PREREQ(2.13) any
more (it doesn't make any difference to the following output), but I get CXX = and
CC = followed by failure further down. Although it says checking whether make sets
${MAKE}... (cached) yes, there is no config.cache file before or after I try this.
The autogen.sh here is identical to the one in FlightGear/ but FlightGear configure
works fine.
I'm using automake 1.4 and autoconf 2.52 in CygWin.
Any ideas anyone?
- Julian
$ ./autogen.sh
Host info: CYGWIN_ME-4.90 i686
automake: 1.4 (14)
Running aclocal
Running autoheader
Running automake --add-missing
Running autoconf
==
Now you are ready to run './configure'
==
$ ./configure
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
CXX =
CC =
checking whether make sets ${MAKE}... (cached) yes
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... .exe
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
configure: error: cannot run /bin/sh ./config.sub
$
Michael Basler wrote:
-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag von Julian Foad
Until this is fixed properly, you can fix this by adding the line:
AC_PREREQ(2.13)
at the beginning of configure.in, just after the dnl ... lines
which are comments. At least, this works for me.
One million thanks, Julian, this fixed the case for me. Same goes for
FlightGear, as I detected a few minutes later.
Could someone responsible (Curt, Dave...) fix this in the CVS? Thanks a
lot.
Regards, Michael
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] properties problem
By false you mean they are null, I assume. Well, latitude and longitude are
created a few lines further up by:
// Any time after globals is created we are ready to use the
// property system
static const SGPropertyNode *longitude
= fgGetNode(/position/longitude-deg, true);
static const SGPropertyNode *latitude
= fgGetNode(/position/latitude-deg, true);
So these must be failing. There should probably be a check for null pointers there.
- Julian
Erik Hofman wrote:
Julian Foad wrote:
Erik Hofman wrote:
The latest FlightGear from CVS gives me a core after startup.
I traced it back to SimGear/simgear/misc/props.hxx line 730:
Process 14190 (fgfs) stopped on signal SIGSEGV: Segmentation violation
(default) at [SGPropertyNode::getAttribute(SGPropertyNode::Attribute)
const:730 +0x10,0x103b2110]
730 bool getAttribute (Attribute attr) const { return ((_attr attr)
!= 0); }
I have no idea why this happens.
Does anybody else have any idea?
I think you need to look higher up in the call stack: perhaps the object pointer
on which this method is called was invalid.
You are right, I forgot to mention:
I tracked the probelm down to FlightGear/src/Maim/main.cxx
SGTime *t = new SGTime( longitude-getDoubleValue()
* SGD_DEGREES_TO_RADIANS,
latitude-getDoubleValue()
* SGD_DEGREES_TO_RADIANS,
zone.str() );
Tests show that both longitude and latitude are false ...
Hope this helps some more.
Erik
I'm lost at this one :(
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem compiling recent Simgear CVS
Norman Vine wrote: Michael Basler writes: Julian Foad write: Until this is fixed properly, you can fix this by adding the line: AC_PREREQ(2.13) at the beginning of configure.in, just after the dnl ... lines which are comments. At least, this works for me. One million thanks, Julian, this fixed the case for me. Same goes for FlightGear, as I detected a few minutes later. Could someone responsible (Curt, Dave...) fix this in the CVS? Thanks a lot. The problem is that the GNU autotools had a non-backwards compatable change and we might have to live with hand tweaking the configure scripts for a while untill all systems have changed over to the newer release They did have a major change, but adding AC_PREREQ(2.13) is a way of making the files compatible with the new CygWin autotools (the auto-detecting ones that explicitely look for this), while still remaining compatible with the old ones. I use the old versions of the tools and they work fine with or without that line. I hope that's right because I recently asked Curt to add that line in both SimGear/configure.in and FlightGear/configure.in. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: AW: [Flightgear-devel] Problem compiling recent Simgear CVS
OK: a CygWin update followed by mv acsite.m4 aclocal.m4 fixed it for me. Details
below.
Norman Vine wrote:
Julian Foad writes:
Now I've got another problem with it. I don't seem to need
the AC_PREREQ(2.13) any more (it doesn't make any difference
to the following output), but I get CXX = and CC =
followed by failure further down. Although it says checking
whether make sets ${MAKE}... (cached) yes, there is no
config.cache file before or after I try this.
$ ./autogen.sh
Host info: CYGWIN_ME-4.90 i686
automake: 1.4 (14)
Running aclocal
This should be
aclocal -I .
The autogen.sh adds -I . only for Irix. That souns a bit suspicious because I used
to have to use it in CygWin, so I tried it just now, but it didn't make any difference
to my present problem. I guess it's needed for some versions of the autotools but not
others.
Then I updated my CygWin autotools to the latest, because although my older versions
had been working OK I thought I might have an inconsistent set of different packages.
This led to different errors, and since the CygWin installer doesn't let me return to
earlier versions even though I still have the package files locally, I had to continue.
Host info: CYGWIN_ME-4.90 i686
automake: 1.4-p5 (14)
Running aclocal
Running autoheader
./aclocal.m4:254: /usr/bin/m4: Warning: Excess arguments to built-in `define' ignored
/usr/autotool/stable/bin/autoheader: Symbol `GZCAT' is not covered by
/usr/autotool/stable/share/autoconf/acconfig.h ./acconfig.h
/usr/autotool/stable/bin/autoheader: Symbol `ZCAT' is not covered by
/usr/autotool/stable/share/autoconf/acconfig.h ./acconfig.h
Running automake --add-missing
automake: Makefile.am: installing `./INSTALL'; error while making link: File exists
Running autoconf
./aclocal.m4:254: /usr/bin/m4: Warning: Excess arguments to built-in `define' ignored
configure.in:32: AC_PROG_CPP was called before AC_PROG_CC
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_CC
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_MSG
...
Eventually I remembered that Ross Golder had found that mv acsite.m4 acinclude.m4
worked for him. I already had an acinclude.m4 which was identical to my acsite.m4, so
the only effect of this command was to delete acsite.m4. But it worked! I wish I
understood this magic.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: Intro music on Windows
Blimey! What a wierd combination of effects. On Windows ME its nearly the same: just start .\notepad is different. C:\ver Windows Millennium [Version 4.90.3000] C:\start /m notepad -- notepad started minimized C:\start .\notepad Cannot find file '.\notepad' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. C:\start c:/Windows/notepad -- notepad started successfully C:\start ./notepad Cannot find file './notepad' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. C:\start ./notepad.exe -- notepad started successfully And also: C:\start .\notepad.exe Cannot find file '.\notepad.exe' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. - Julian Norman Vine wrote: Julian Foad writes: The /m switch specifies a minimised (iconised) window. Could Windows users check whether this is supported on various versions of Windows. It is on Windows ME. AFAIK 'start /m' is supported on all Win32 systems The cygpath -w command converts the unix-like pathname to a Windows one which the Windows program will recognise. Something like this may be needed in the non-CygWin case. I'm not sure what the values of get_fg_root() and /sim/startup/intro-music will or should be. Can the SGPath class convert between native and unix-style pathnames? AFAIK get_fg_root() should always return a path that the underlying system should understand, and WIN32 almost understands . Note the following 'quirks' though Microsoft(R) Windows 98 (C)Copyright Microsoft Corp 1981-1998. C:\WINDOWSstart /m notepad -- notepad started minimized C:\WINDOWSstart .\notepad -- notepad started successfuly C:\WINDOWSstart c:/Windows/notepad -- notepad starts successfuly C:\WINDOWSstart ./notepad Cannot find file './notepad' (or one of its components). Check to ensure the path and filename are correct and that all required libraries are available. C:\WINDOWSstart ./notepad.exe -- notepad started successfuly to be sure of success when launching a program with start on WIN32 use the FULL filename to include the extension ! Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Norman Vine wrote: Removed fgReshape() call from main loop That's undoubtedly a good thing. Never mind who can see a speed benefit and who can't. I can only imagine it was put there to work around some bug. If so, let's see if the bug shows up again, and fix it properly if it does. Removed fgIdle from the main loop once things are up and running 1) initially glutDisplayFunc() is set to new mySplashDraw function 2) when idle state reaches 1000 glutDisplayFunc() set to fgRenderFrame() glutIdleFunc() reassigned to fgMainLoop() This only saves a few integer comparisons at run time, but looks like a good logical clean-up. Made a local copy of a property value when it is used multiple times inside of the same function and used it moved static property nodes pointers from function scope to file scope. I'm ambivalent about these. I can't check frame rate because mine is continuously fluctuating by about 10% from one second to the next, and depends very strongly on the exact view. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Metakit 2.4.2 = 2.4.3
Jon S Berndt wrote: On Wed, 27 Mar 2002 23:08:59 + Julian Foad [EMAIL PROTECTED] wrote: The SimGear root includes metakit-2.4.2-32.tar.gz. Version 2.4.3 is now available and fixes several potentially serious bugs. I'm not saying Flight Gear is affected by any of them (I have no idea) but I think it's worth considering upgrading. FWIW, under my CygWin systems (on both Win2k and WinME), metakit fails to build on tcl-related stuff and I have to configure --without-tcl. A trivial typo in Julian: I noticed that MetaKit failed to *finish* the make process when I installed it the other evening. However, it failed after it had already installed the required libraries (at least it did so on my system). It *may* be that this is occuring on your system, as well. Did you try make install on metakit, and then trying to build SimGear? You might give that a shot. Maybe your metakit build was good enough? I didn't try make install after it failed to build, but I guess that might well have installed enough files to work with. I just fixed the typo in configure and ran configure --without-tcl and make and make install and that was fine. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Pilot view offset
The recent 3D work is absolutely lovely. With Jim's view manager work, can we re-instate the F5-F8 keys so that they move the pilot's head up/down/left/right relative to the airframe? The effect would be equivalent to the old 2D panel moving around the screen. In particular, moving the pilot's head up would have the same effect as moving the panel down the screen to expose more view of the ground. This is pretty essential to me. Actually, the up/down is most important. Forward/backward would be the next most useful: it would be a bit like the zoom function (keys x/X) but would have the effect of zooming in on the panel without noticeably changing the view through the window. Moving the head left/right is not very important in my opinion, but should be available. In fact, all six degrees of freedom should be available but not necessarily bound to convenient keys by default. All six should be available from the View menu, though, and the menu and keyboard adjustments should be usable in both pilot and spotter view modes. I hope this will all be easy with the new code. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Runway numbers: leading zero
In Britain, as far as I know, we always use two-digit numbers for the runway direction - e.g. 09 or 09L or 09R, not 9L. Is this not the case in the USA and elsewhere? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Throttle movement squared
The joystick axis squared mode seems to default to on, and is applied at the centre of the axis, not the zero-point of the output value. In the default joysticks.xml, the throttle bindings do not explicitly set it false, so the throttle movement is very odd, so I edited my joysticks.xml. However, I think it would be a good idea to change the default to false because this squared feature is not the Right Thing for a general input axis. It is, like a dead band, an arbitrary work-around for normally-centred, low-resolution joystick axes, that some people want and others don't. It is a useful feature to have available, but only when the user asks for it. Would people be prepared to change the property's default value in CVS? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
Quint, There is Atlas (atlas.sourceforge.net), which connects to Glight Gear and plots the aircraft's track on a nice moving map display. It doesn't record any other data, but the source code will show you one way of getting data out of FlightGear. - Julian Quint Mouthaan wrote: FlightGear. The first thing we want to do is analyze some flight data. I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] /controls/parking-brake
David Megginson wrote: Frederic Bouvier writes: MSVC has no 'fmax' function. 'max' is ok (a macro !). Hmm -- max won't work under GCC because it's an inlined function. Heh? You mean the inlined (templated) max function from algorithm/stl_algobase.h? What's wrong with that? It is used in other JSBSim files (FGNozzle.cpp, FGLGear.cpp). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: ... Aside from removing unreferenced variables, the bulk of the changes were in the area of the use of floating-point. Since C does all passing of floats as doubles, and does all math in double, could we have a mandate that all floating-point valued be double? I can see it being a pain for the programmer to always add the 'f' at the end of float constants, just go get around the compiler warnings. No: C (since about 1995) and C++ do not pass all floats as doubles and do not do all (floating) math in double. If the result is going to be converted back to float, the compiler is allowed to to the calculation in float precision. Adding f to constants is a pain, I agree. Some compilers can be told to choose the appropriate type for unsuffixed constants in this situation. While on the subject of floating-point, I will get on one of my soap boxes. Taking 5/2.0 may not always yield the result you intend. I would suggest using 5.0/2.0 or, if you really want the integer result, floor(5.0/ 2.0) and ceil(5.0/2.0). The C/C++ programmer will intend the result to be 2.5. This is defined by the standard arithmetic conversion rules of C/C++. What do you think might happen instead? I highly recommend Stroustrup's book The C++ Programming Language. It explains everything. Another personal nit is the lack of a leading zero on numbers 1.0 (I prefer seeing 0.5 rather than .5). Is there a general preference for FlightGear? I prefer the leading zero too, but I don't think there is a strong reason to persuade everyone to use it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Propellor graphics
The spinning propellor (on c172-3d) needs a bit of work. It spins even when the model is parked and the engine stopped. If pause mode is on, it spins more slowly but still does not stop. With magnetos off but starter engaged, the tachometer shows about 600 RPM (i.e. 10 revs per second). The propellor spins at one and a bit revs per second. I think the propellor is supposed to be directly driven from the engine crankshaft, but I'm not sure. The two blades are not twisted relative to each other: one blade is pushing and the other pulling. The transparency feature is not working for me, so the propellor disc suddenly appears as an opaque object. I have applied David Megginson's plib-smoothing.dif and my plib (from CVS) already appears to have the equivalent of the transparency patch. That bug may be the only reason for the following observation: The disc that fades in at higher speeds is solid grey for me. It needs to have a (radial) colour profile that matches the blades, i.e. mostly black with some red bits. The expected grey appearance will come automatically when a partially transparent black disc is displayed over a light background (sky etc.). But nevertheless it is a nice fun, eye-catching feature. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: My C training goes back to circa 1985, at which time all floats were passed as doubles. Yes, they were. In fact, the modern C/C++ compilers to which I have access still do this (I don't use gcc, except to rebuild FlightGear). Oh? Which compilers? All floating-point co-processors do their work in extended precision (usually 80-96 bits) and shorten the numbers back to the range desired by the user, Certainly some do. I'm pretty sure that not all do, at least not for functions that can be done significantly faster at lower precision. and the single-precision math libraries I have used just cast the results of the double-precision routines to be single-precision (it saves on duplicated code). At work we use an Intermetrics C compiler (Intertools for NEC V20 series processors) that is supplied with a standard software floating-point library that includes separate single and double-precision versions of most of the routines. There is also an alternate version of the library which uses the same data sizes (4 and 8 bytes) but does not calculate to the full accuracy, and is considerably faster. You can choose the most appropriate library for your application. I must be older than anyone else here, but my collegiate C training drove home the fact that mixing integer and floating-point can give you unpredictable results. Granted, this was pre-ANSI C. Maybe it was unpredictable before standardisation, but I feel that's unlikely; I don't have the original (KR) reference book to check. Another possibility is that the teacher couldn't predict the results because he/she didn't know the language well enough ... that's quite common, unfortunately. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realy strange
This is what you get if the wrong version of automake/autoconf is used. Unfortunately the old and new versions are not compatible. SimGear needs the old version. The automake/autoconf supplied with CygWin automatically detects which version to use, and it might be possible to get these auto-detecting auto-tools for SuSE ... but I don't know where from. The easiest solution might be to get and install the SuSE packages for the previous version of automake and autoconf. While we're on the subject, I have to do mv acsite.m4 acinclude.m4 before running autogen.sh, otherwise I get a different set of errors. - Julian Alexander Kappes wrote: I recently upgraded from SuSE 7.2 to 8.0 and since then I get strange error messages when I try to run autogen for SimGear (and also FlightGear): --- Host info: Linux i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Installing only changed header files
Thanks; I think I'll do that. - Julian David Megginson wrote: Julian Foad writes: Doesn't everyone have the same problem that I have: that after re-building plib and/or SimGear, even after a one-file change, the make install copies all of the header files to the install directory, putting the current date stamp on them, even though they have not changed. This causes almost every file in FlightGear to be re-compiled. I keep the SimGear source tree in /usr/local/src, then just do this: rm -rf /usr/local/include/simgear ln -s /usr/local/src/SimGear/simgear /usr/local/include ln -sf `find /usr/local/src/SimGear -name '*.a' -print` /usr/local/lib Then, I make sure I never do a 'make install' in /usr/local/src/SimGear, and everything works nicely. For plib, the procedure is slightly different, since all include files have to be in the same directory: rm -rf /usr/local/include/plib mkdir /usr/local/include/plib ln -sf `find /usr/local/src/plib/ -name '*.h' -print` /usr/local/include/plib ln -sf `find /usr/local/src/plib/ -name '*.a' -print` /usr/local/lib I'm doing this from memory, so please forgive any typos. There's one caveat -- if SimGear or plib changes only in the cxx files, you will have to remove the FlightGear binary to force a relink. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realy strange
Alexander Kappes wrote: Thanks for the information Julian. Yes, I removed the old config.cache file. Did I get this right, the only way to make it work again is reverting to the old version? The old version of the auto-tools will probably work, but I don't know for sure. And I don't know whether that is the only way to make it work. Sorry. You should also check that SimGear/configure.in contains the line AC_PREREQ(2.13) near the beginning. If you are not using a recent version from CVS, you need to add it: AC_INIT(simgear/bucket/newbucket.cxx) + # Require at least automake 2.13 + AC_PREREQ(2.13) + dnl Initialize the automake stuff AM_INIT_AUTOMAKE(SimGear, 0.0.18pre1) That might solve the problem. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Installing only changed header files
Alex Romosan wrote: Julian Foad [EMAIL PROTECTED] writes: Doesn't everyone have the same problem that I have: that after re-building plib and/or SimGear, even after a one-file change, the make install copies all of the header files to the install directory, putting the current date stamp on them, even though they have not changed. This causes almost every file in FlightGear to be re-compiled. how about: make INSTALL='install -pc' install from the install man page: -p, --preserve-timestamps apply access/modification times of SOURCE files to corresponding destination files this works for me. --alex-- Excellent! That's the sort of thing I was hoping for. I don't know how I missed that when I read the install manual. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Simgear timezone file parsing anomaly
What this code says is ignore anything after a hash ... unless we're compiling with
Microsoft C, in which case only ignore lines which start with a hash. Surely this
isn't intended. Curt checked in the change last May, but almost certainly didn't
invent it.
My tentative guess would be that MSVC users were bitten by the memory over-run bug in
the same file, which was fixed only last month (thanks to Melchior) and that this was
sort of a crude work-around for it. Not sure, though.
Unless someone has a valid reason for it, I suggest the #ifdef _MSC_VER ... #else
section be removed.
TimezoneContainer::TimezoneContainer(const char *filename)
{
...
fgets(buffer, 256, infile);
...
#ifdef _MSC_VER
if( buffer[0] == '#' )
continue;
#else
for (char *p = buffer; *p; p++) {
if (*p == '#') {
*p = 0;
break;
}
}
#endif
if (buffer[0]) {
...
}
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS Link Error
Paul Deppe wrote:
When making the latest CVS FGFS on Cygwin/Win2k, the following link error
occurs:
/usr/lib/libplibul.a(ulContext.o)(.text+0x47):ulContext.cxx: undefined
reference to `wglGetCurrentContext@0'
collect2: ld returned 1 exit status
I don't know the reason for it, but you can work around it temporarily by patching
plib/src/util/ulContext.cxx: ulIsValidContext() so that it just returns true without
trying to call wglGetCurrentContext.
bool ulIsValidContext ( void )
{
- #if defined(CONSOLE)
+ #if 1 // defined(CONSOLE)
return true ;
#elif defined(WIN32)
return ( wglGetCurrentContext () != NULL ) ;
#elif defined(macintosh)
return ( aglGetCurrentContext () != NULL ) ;
#elif defined(__APPLE__)
return ( CGLGetCurrentContext () != NULL ) ;
#else
return ( glXGetCurrentContext () != NULL ) ;
#endif
}
I'll ask Sebastian Ude on the plib list about this, because he has just moved that
function from a different module (plib/src/ssg/ssg.cxx).
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Propellor speed error due to FGSubsystem::update(multi_loop)
The error in the speed of the propellor, and other things that we might not have noticed yet, is caused by the handling of the variable multi_loop in main.cxx:fgUpdateTimeDepCalcs(). After being used to update the FDM, this multi_loop value (or the value 1 in freeze mode) is passed to the various subsystem update methods: globals-get_model_mgr()-update(multi_loop); globals-get_aircraft_model()-update(multi_loop); globals-get_viewmgr()-update(multi_loop); current_radiostack-update(multi_loop); The model manager, at least, is expecting to receive the number of milliseconds that have elapsed since the last call. The multi_loop number does not seem to be that. Nor does the definition of FGSubsystem::update help: /** * Update the subsystem. * * pFlightGear invokes this method every time the subsystem should * update its state. If the subsystem requires delta time information, * it should track it itself./p */ virtual void update (int dt) = 0; That looks wrong to me. Surely it should track it itself applied before the dt parameter existed, and now the dt parameter is intended to provide the time difference and should be defined here. Anyone prepared to sort this out? If dt is to represent milliseconds, it would be a good idea to rename it dt_ms (in the derived classes too). I haven't checked how other classes interpret it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propellor graphics
Update to my own comments: Julian Foad wrote: The spinning propellor (on c172-3d) needs a bit of work. It spins even when the model is parked and the engine stopped. If pause mode is on, it spins more slowly but still does not stop. That works now (it stops). Maybe I didn't have that recent fix (in JSBSim). With magnetos off but starter engaged, the tachometer shows about 600 RPM (i.e. 10 revs per second). The propellor spins at one and a bit revs per second. I think the propellor is supposed to be directly driven from the engine crankshaft, but I'm not sure. Still wrong, but not David's fault. Due to mis-use of update(multi_loop) - see separate message. The two blades are not twisted relative to each other: one blade is pushing and the other pulling. David has fixed this. The transparency feature is not working for me, so the propellor disc suddenly appears as an opaque object. I have applied David Megginson's plib-smoothing.dif and my plib (from CVS) already appears to have the equivalent of the transparency patch. I had two copies of plib installed - oops! Transparency and smoothing are now working for me. The disc that fades in at higher speeds is solid grey for me. It needs to have a (radial) colour profile that matches the blades, i.e. mostly black with some red bits. The expected grey appearance will come automatically when a partially transparent black disc is displayed over a light background (sky etc.). Apologies - it looks pretty good as it is, both in sunlight and at night, now that I see it as intended - i.e. very feint, so the colouring of it is not too important. In fact, the light grey colour of it looks like a highlight reflection off the blades. The only situation in which it goes wrong is in an external view, it cuts out the cloud texture (so it looks like a solid grey disc) - but ground textures show through it perfectly, and both ground and clouds show through properly in the pilot's eye view. Is there a way to make the prop fade out and the disc fade in as RPM changes? Something like animation type=transparency ? I tried making the propeller material transparent in the .ac file, and that works except that behind a transparent propeller blade, the clouds and some parts of the airframe disappear (engine cowling, tail fin, ...) while the rest remains (seats, wings, ...). Yet behind the disc, the whole of the airframe is OK and only the clouds disappear. OK, I'd better step back from 3D modelling. I've never done it and this seems to be one of those tricky areas that you modellers learn about. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Cygwin/Win2k link error for wglGetCurrentContext
Thanks guys. Apologies for implying that it might have been a problem with plib. Curt, will you change this line (see end of this message) in CVS? I've tried it and it works for me, and it looks like the right fix. - Julian Sebastian Ude wrote: I guess this is the problem. -lopengl32 (or whatever library contains the wgl* routines; I'm not a Windows programmer) must come *after* -lplibul. Could you FlightGear developers take care of that ? Yes, it looks like we can :-) Norman Vine wrote: It appears as if the easiest way to fix this is to change the line in the Main / Makefile.am file that includes the other PLib libraries to also include -lplbul Note that this is probably only a Cygwin problem and will not appear on Unix because of the difference in the way linking is done. On Cygwin all symbols must be defined at link time. ie ld --no-undef behaviour in Linux ld allows including a library more then once in the link library list so this should not be a problem Cheers Norman === cut == src / Main / Makefile.am 86c86 -lplibpu -lplibfnt -lplibnet -lplibssg -lplibsg \ --- -lplibpu -lplibfnt -lplibnet -lplibssg -lplibsg -lplibul \ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
Andy,
The original code assumed that dt was in milliseconds. The variable name
velocity_rpms presumably stood for revs per millisecond.
Your patch assumes that dt is in 1/120ths of a second. Is this linked to your frame
rate?
The meaning of dt needs to be consistent across the various instances of
FGSubsystem, and I don't think it is: see my post Propellor speed error due to
FGSubsystem::update(multi_loop), reproduced below.
- Julian
Andy Ross wrote:
Here's a patch to model.cxx that restores the proper rotation speed of
the propeller spin.
It just replaces the single 1/6 constant with one that is
(hopefully) more clearly derivable from basic principles. The
original number was off by a factor of 3/25; maybe something got
double-factored? One thing I didn't do is grab the 120 Hz update rate
from a real source; it's hardcoded instead. I forget where it comes
from.
Andy
diff -u -r1.10 model.cxx
--- model.cxx 20 Apr 2002 15:07:47 - 1.10
+++ model.cxx 30 Apr 2002 23:17:55 -
@@ -527,8 +527,9 @@
void
FG3DModel::SpinAnimation::update (int dt)
{
- float velocity_rpms = (_prop-getDoubleValue() * _factor / 6.0);
- _position_deg += (dt * velocity_rpms * 360);
+ float velocity_rpms = _prop-getDoubleValue() * _factor;
+ // 120Hz update, 60 sec/min, 360 degrees/revolution
+ _position_deg += (dt * (1/120.0) * (1/60.0) * velocity_rpms * 360);
while (_position_deg 0)
_position_deg += 360.0;
while (_position_deg = 360.0)
--
On 21 April Julian Foad wrote:
The error in the speed of the propellor, and other things that we might not have
noticed yet, is caused by the handling of the variable multi_loop in
main.cxx:fgUpdateTimeDepCalcs(). After being used to update the FDM, this
multi_loop value (or the value 1 in freeze mode) is passed to the various subsystem
update methods:
globals-get_model_mgr()-update(multi_loop);
globals-get_aircraft_model()-update(multi_loop);
globals-get_viewmgr()-update(multi_loop);
current_radiostack-update(multi_loop);
The model manager, at least, is expecting to receive the number of milliseconds that
have elapsed since the last call. The multi_loop number does not seem to be that.
Nor does the definition of FGSubsystem::update help:
/**
* Update the subsystem.
*
* pFlightGear invokes this method every time the subsystem should
* update its state. If the subsystem requires delta time information,
* it should track it itself./p
*/
virtual void update (int dt) = 0;
That looks wrong to me. Surely it should track it itself applied before the dt
parameter existed, and now the dt parameter is intended to provide the time
difference and should be defined here.
Anyone prepared to sort this out? If dt is to represent milliseconds, it would be
a good idea to rename it dt_ms (in the derived classes too). I haven't checked how
other classes interpret it.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Extra GCC warnings
Andy queried why we aren't using the GCC option -Wall. I've been compiling for a few weeks now with extra GCC warnings enabled, to see whether it will help with portability issues or just be a nuisance. I used these options: -Wall -pedantic -Wpointer-arith -Wall is highly recommended, and means all normally useful warnings. The author of the GCC manual says you would never want to use -pedantic, but it seems to be just what we need in order to write portable code. I added -Wpointer-arith to my list because it seemed like a good idea, but I haven't researched the pros and cons. This is how I use them: GCCFLAGS=-Wall -pedantic -Wpointer-arith [... and my other favourite options ...] CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS ./configure I have looked through all of the warnings from SimGear, and there are very few. About half are annoyances and half genuine (in my opinion); I have made notes on them, below. In FlightGear itself, there are (naturally) more warnings, but most of them are genuine. My conclusion is that these settings are useful, and that the gain is worth the pain of working around the non-useful warnings. I recommend putting these settings in CVS (in autogen.sh ?). - Julian --- Here are all of the warnings from SimGear (about a week old): Making all in xml In file included from xmltok.c:260: xmltok_impl.c: In function `normal_getAtts': xmltok_impl.c:1394: warning: `open' might be used uninitialized in this function In file included from xmltok.c:653: xmltok_impl.c: In function `little2_getAtts': xmltok_impl.c:1394: warning: `open' might be used uninitialized in this function In file included from xmltok.c:792: xmltok_impl.c: In function `big2_getAtts': xmltok_impl.c:1394: warning: `open' might be used uninitialized in this function [open is not actually used uninitialized, so this is an annoyance; we would have to give it an initialiser, even though it would be redundant.] Making all in misc props.cxx: In method `SGPropertyNode::hash_table::~hash_table()': props.cxx:1980: warning: comparison between signed and unsigned [This is mostly harmless but should be fixed (and can be fixed easily and correctly).] Making all in io In file included from lowlevel.cxx:28: lowlevel.hxx:40: warning: ANSI C++ does not support `long long' lowlevel.hxx:41: warning: ANSI C++ does not support `long long' lowlevel.hxx: In function `void sgEndianSwap(uint64 *)': lowlevel.hxx:151: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:152: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:153: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:154: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:155: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:156: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:157: warning: ANSI C++ forbids long long integer constants lowlevel.hxx:158: warning: ANSI C++ forbids long long integer constants [Is there a more standard way to get a 64-bit integer, like int64_t in stdint.h of ANSI C'99? This warning only appears when -pedantic is used, and can be inhibited with -Wno-long-long. This bunch of warnings came out four times.] Making all in metar Dcdmetar.cpp: In function `int DcdMETAR(char *, Decoded_METAR *)': Dcdmetar.cpp:2252: warning: `enum DcdMETAR(char *, Decoded_METAR *)::METAR_obGroup SaveStartGroup' might be used uninitialized in this function Dcdmetar.cpp: At top level: Dcdmetar.cpp:1298: warning: `bool vrblVsby(char *, char *, Decoded_METAR *, int *)' defined but not used [SaveStartGroup is not actually used uninitialized, so this is an annoyance; we would have to give it an initialiser, even though it would be redundant. vrblVsby is an unused static function which should probably be removed or used.] Making all in threads In file included from SGThread.cxx:9: SGThread.hxx:58: warning: comma at end of enumerator list [We should correct this. Although a trailing comma can be considered neat and handy, we do not expect to be able to put one after a list of variables or function arguments, so we should not do so here. I am guilty of another instance of this, in FG's viewer.hxx.] --- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] windows binary
It seems to be caused by a recent change in CygWin. Here is Norman's answer to the same question: Norman Vine wrote (on Tue, 23 Apr 2002): The opengl libs got moved to / lib / w32api / directory don't ask me why ? I just made a link to these in my '/ lib' dirrectory you could also just copy them there or add a -mwindows flag to the gcc link options IMHO None of the above are the right solution but I have quit pushing for what IMHO is the 'right' way of doing things in Open Source projects when one can easily change things in your local copy If-I-wanted-to-be-borg-I-wouldn't-need-a-compiler'ly yrs Norman [EMAIL PROTECTED] wrote: I've been trying to compile the latest version, but I've encountered some problems linking against the opengl library. ... Has anybody seen this error before ? ... /usr/local/lib/libsgscreen.a(screen-dump.o): In function `sg_glDumpWindow(char const *, int, int)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:84: undefined reference to `glFinish' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/screen-dump.cxx:86: undefined reference to `glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trEndTile(_TRctx *)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:404: undefined reference to`glFlush' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:418: undefined reference to`glReadPixels' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:437: undefined reference to`glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trRasterPos3f(_TRctx *, float,float, float)': /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:468: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:476: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:477: undefined reference to`glGetDoublev' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:484: undefined reference to`gluProject' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:495: undefined reference to`glRasterPos3f' /cygdrive/d/fg/SimGear-0.0.18/simgear/screen/tr.cxx:500: undefined reference to`glBitmap' collect2: ld returned 1 exit status ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux IDE
Source Navigator (originally by Cygnus, then RedHat, but now being maintained on SourceForge) is well worth a try. Right now, the patched version at http://oimanager.de/sn.htm is best, but there should be an official release some time soon. It has more cross-referencing features than MSVC, but I'm not sure about debugger integration. Available for Windows and Unix. I've used it a bit for source browsing and editing. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re fgfs-base-0.7.10.zip
Norman Vine wrote: FYI Most Win32 archive tools WinZip ect support tar files nowadays FYI The Latin for and the rest is et cetera, abbreviated etc. (or less commonly c.) :) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main options.cxx,1.162,1.163
Christian Mayer wrote: Note: You 2nd version does *not* use the string concatenation. The 2nd version boils down to the very C++ dependant operator(operator(operator(cout, usage),endl),...); Yes, it does. What point are you trying to make by saying very C++ dependant? Nearly all of FlightGear depends on C++. That syntax is the first thing taught in any book on C++, and is just as suitable for use by experts as by beginners. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
John Wojnaroski wrote: I recall reading an article several years ago in a flying mag (can't remember exactly where or when) on someone's proposal to change the number of degrees on the compass from 360 to 400. ... Have you noticed Deg/Rad/Grad or DRG on every scientific calculator? Those are Grads. I've heard that the military use them ... but I haven't seen any evidence of it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cameron's time zone
Cameron, your latest e-mail message is time-stamped with: Date: Fri, 17 May 2002 09:41:01 -0500 which means 09:41 on the 17th, local time, which is 5 hours behind UTC, which is about a day into the future. (The current time now is Thu 16 May 2002 16:38 UTC.) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main options.cxx,1.162,1.163
Christian Mayer wrote: I wanted to point out the very big (internal) differnce of the ANSI C style string1 string2 THat ends up as string1string2 in a normal array of char vs. The C++ way: cout string1 string2 wich uses the operator() method. Both are valid and have their pro and cons. But they are fundamentally different (and the later doesn't use the string concatenation), although Yes, fair enough. It does seem a bit of a waste to have a separate function called. I think part of the reason for the existence of endl is this: If endl were enforced as the only legal way (i.e. if \n was made illegal in a future version of C++) then the string outputting functions would no longer have to scan for '\n' in the text that they output. Presently, each time they find '\n' they generally flush the stream output buffer, as well as to converting it to the local line ending character(s) where necessary. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cameron's time zone
Alex Perry wrote: Cameron, your latest e-mail message is time-stamped with: Date: Fri, 17 May 2002 09:41:01 -0500 which means 09:41 on the 17th, local time, which is 5 hours behind UTC, which is about a day into the future. Don;t worry about it; Cameron just likes to have his messages at the top of your in-box. That way you get around to reading them somewhat earlier. Actually I read my messages in chronological order, so I get to his last! No, wait ... I won't get to read his messages until tomorrow :) (The current time now is Thu 16 May 2002 16:38 UTC.) No, it isn't ... not any more. :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
Another idea: you might have old versions of SimGear, plib or other libraries
installed somewhere. This should find exactly one copy of libsgsky:
$ find /usr -name 'libsg*' -exec grep -l getSpan_m {} \;
/usr/local/lib/libsgsky.a
If it finds none or more than one, there's a problem with the SimGear build/install.
- Julian
Keith Wiley wrote:
environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_span_m(int)
const':
environment_mgr.cxx:206: no matching function for call to `SGCloudLayer::getSpan_m
()'
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: The telnet interface produce wrong line ending when I run both FlightGear and the telnet client on Win2k. I've just sent a patch to Curt that produce line ending based on the platform where fgfs is running ( something between #ifdef and #endif ). For the moment, this patch only address the issue when fgfs and the telnet client run on the same platform. Thinking of it now, it would be better to generate proper line endings based on the capabilities of the client. Do the telnet interface support telnet commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced from the incoming command. Ideas ? Idea: the receiver should accept any of these four line endings: CR LF CR,LF LF,CR In fact, I strongly believe that all text parsers, viewers, and readers of any kind should accept these. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
I (Julian Foad) wrote: Idea: the receiver should accept any of these four line endings: Sorry, I misunderstood. I was thinking of a peer-to-peer type connection. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: Perhaps I didn't made me clear. The problem is when FlightGear send text to the telnet client. Each line begins where the previous ends because Win2k telnet client needs a cariage return (\r) with the line feed (\n). OK. The Telnet protocol (RFC854) requires that line ends are sent as CR-LF, so I think FlightGear is faulty. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Does yasim-747 work?
Jim Wilson wrote: Andy, I dumped the last 3 iterations (for my own benifit) and following that is the solution report. What I did for now was go into the Airplain.cpp Airplain - Airplane ? Drag factor: 1.000199 Lift Factor: 1.000410 aoaDelta: 0.000110 tailDelta: 0.83 elevDelta: 0.000114 Drag factor: 1.000475 Lift Factor: 1.000451 aoaDelta: 0.000100 tailDelta: 0.000986 elevDelta: 0.95 Drag factor: 1.000276 Lift Factor: 1.42 aoaDelta: 0.10 tailDelta: 0.001069 elevDelta: 0.18 tailDelta is increasing here. At a guess, I'd say maybe the solution is oscillating. YASim solution results: Iterations: 10002 Drag Coefficient: 12.3517 Lift Ratio: 85.8242 Cruise AoA: 2.97772 Tail Incidence: -4.82189 Approach Elevator: -0.714202 CG: -29.5, -0.0, 1.3 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations[ - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SimGear tidy-up (GCC -Wall warnings etc.)
1. simgear/simgear_config.h.in should not be in CVS, as it is generated from
configure.in and so gives conflicts on every update.
2. simgear/metar/Dcdmetar.cpp: function static bool vrblVsby is unused, so could
profitably be removed or surrounded by #if 0. (Note that, being static, it can't
possibly be used by anything outside that file. Hence gcc -Wall warns about it.)
3. simgear/threads/SGThread.hxx: comma at end of enumeration list is warned about, so
we ought to get rid of it:
diff -u -3 -p -r1.3 SGThread.hxx
--- simgear/threads/SGThread.hxx11 Apr 2001 21:14:24 - 1.3
+++ simgear/threads/SGThread.hxx5 Jun 2002 20:58:33 -
@@ -54,7 +54,7 @@ public:
{
CANCEL_DISABLE = 0,
CANCEL_DEFERRED,
- CANCEL_IMMEDIATE,
+ CANCEL_IMMEDIATE
};
public:
4. simgear/timing/geocoord.cxx: variable nearest is possibly used un-initialised,
according to GCC, so we ought to initialise it, even though I've checked that it is
actually OK:
diff -u -3 -p -r1.3 geocoord.cxx
--- simgear/timing/geocoord.cxx 24 Mar 2001 03:20:47 - 1.3
+++ simgear/timing/geocoord.cxx 5 Jun 2002 20:58:34 -
@@ -80,7 +80,7 @@ GeoCoord* GeoCoordContainer::getNearest(
sgVec3 first, secnd;
float dist, maxDist=SG_MAX;
sgSetVec3( first, ref.getX(), ref.getY(), ref.getZ());
- GeoCoordVectorConstIterator i, nearest;
+ GeoCoordVectorConstIterator i, nearest = NULL;
for (i = data.begin(); i != data.end(); i++)
{
sgSetVec3(secnd, (*i)-getX(), (*i)-getY(), (*i)-getZ());
5. simgear/xml/xmltok_impl.c: variable open is possibly used un-initialised,
according to GCC, so we ought to initialise it, even though I've checked that it is
actually OK:
diff -u -3 -p -r1.1 xmltok_impl.c
--- simgear/xml/xmltok_impl.c 26 Jul 2000 19:17:46 - 1.1
+++ simgear/xml/xmltok_impl.c 5 Jun 2002 20:58:39 -
@@ -1391,7 +1391,7 @@ int PREFIX(getAtts)(const ENCODING *enc,
{
enum { other, inName, inValue } state = inName;
int nAtts = 0;
- int open;
+ int open = 0;
for (ptr += MINBPC(enc);; ptr += MINBPC(enc)) {
switch (BYTE_TYPE(enc, ptr)) {
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Patch for options.cxx
If the program cannot find options.xml, I strongly suggest that it still should give a sensible (if brief) reply to --help. This reply should tell the user how to help it to find options.xml. - Julian C. Hotchkiss wrote: Erik Hofman wrote: C. Hotchkiss wrote: ... If the file isn't needed because an error wasn't made, does the program abort because it cannot find the file? Admittedly I'm being lazy in not testing this myself. It only throws an exception when --help (or an incorrect argument) was specified or *and* the file options.xml doesn't exsist. So, does the program abort or advise and go on? I'm thinking that the exception event would be rare, but even so, a miss installation or an accidentally deleted file shouldn't leave the user scratching his or her head. When easily done, good hints about why things went wrong should be given. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Property browser bugs
I'm debugging the property browsers. Currently they don't handle indexing properly: multiple instances of /input/mice/mouse/mode[0]/button/ are shown without indices because the buttons are numbered 2,3,4 but the test it uses is Is there a child of this name with index 1?. Clicking on any of them causes a seg-fault because no such node (with implied index zero) exists. I propose to change it to display the index if the index is non-zero OR it has siblings with the same name (i.e. if index!=0 or there are two or more different indices). I also want to factor out this code from FG's telnet interface, FG's property picker, and SGPropertyNode::getPath which all try to do the same thing. Proposal: /** * Return name[index], or just name if 'simplify' is true and * the index is 0 and there are no siblings with the same name. */ string SGPropertyNode::getPrettyName(bool simplify) const; (PrettyName is a horrible name. Suggestions?) This seems an appropriate addition because the class already contains the ability to parse such a string (name with optional index) in getNode(const char * relative_path, ...) and to generate one as a complete path, but not yet to generate one as a single path component. While investigating, I found that SGPropertyNode::getPath returns a (char *) pointer to the character data of a string on its stack, i.e. to undefined memory after it returns. I remember someone was changing strings to char* for efficiency. Perhaps this bug was introduced then. I'll include a patch for it with my eventual patch for the above, unless someone beats me to it. I don't think it affects any existing callers: they all want a string anyway. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Altimeter broken
The altimeter seems to be broken at the moment. /steam/altitude-ft shows a huge, unchanging, random value for me, and the instrument (on more than one aircraft) just stays at zero. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate properties?
I see rho-slugsft3 in the built-in property browser (View/Properties), but rho-slugs_ft3 in the httpd property browser. I think what is happening is that the latter is correct, but the PLIB default font fails to show underscore characters. I would guess that you took the name as you saw it without the underscore, inserted it in an XML configuration file and then ran FG, which would cause your new property to be created. Then the property browser would show both of them; it knows they are different, but they display the same. We need a different (or rather a complete) font. This has been mentioned before. The PLIB guys said something like It's easy to create one. We could supply one in Flight Gear, but really someone ought to complete the one in PLIB. - Julian John Wojnaroski wrote: Odd. I'm only calling tie once, and my little fltk property browser only shows the correct value. The duplicate showed up in the pull-down menu from view properties. You might check the value of /environment/density-slugft3. It's probably better to use that one anyway as it is not FDM specific. Right, that's what I wound up doing. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Altimeter broken
I should have mentioned that the altimeter in my local source code is connected to the
reported air pressure, rather than just an artificial conversion of the FDM's known
altitude. This is what I have in steam.cxx to find the static pressure:
#ifdef FG_WEATHERCM
sgVec3 plane_pos = { cur_fdm_state-get_Latitude(),
cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Altitude() * SG_FEET_TO_METER };
double static_inhg = WeatherDatabase-get(plane_pos).AirPressure *
(0.01 / INHG_TO_MB);
#else
double static_inhg =
globals-get_environment_mgr()-getEnvironment().get_pressure_inhg();
#endif
set_lowpass ( the_STATIC_inhg, static_inhg, dt );
It was working OK with WEATHER_CM, but not now with the new Environment.
FGEnvironment::get_pressure_inhg() is returning a ridiculously tiny number.
By the way, I have just stepped through this and I noticed that
FGEnvironmentMgr::getEnvironment returns a _copy_ of the environment object, which
involves setting up new interpolation tables. Wouldn't it be more appropriate to
return a reference to it?
- Julian
Julian Foad wrote:
The altimeter seems to be broken at the moment. /steam/altitude-ft shows a huge,
unchanging, random value for me, and the instrument (on more than one aircraft) just
stays at zero.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Capturing warnings
Making all in Main
c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
-I/usr/local/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O1 -finline-limit-6
-finline-functions -Wall -pedantic -Wpointer-arith -c main.cxx
main.cxx: In function `void fgUpdateTimeDepCalcs()':
main.cxx:766: warning: unused variable `int i'
main.cxx: In function `void fgLoadDCS()':
main.cxx:1742: warning: unused variable `class ssgVertexArray * lights'
main.cxx:1746: warning: `int light_type' might be used uninitialized in this function
... and there are many others in other files.
I have realised that in order for warnings to be useful, it is no good for them just
to scroll past and then be lost until after the next make clean. At work, I capture
the compiler output for each file and then display all the warnings and errors at the
end of the build. Not just those from the files that were compiled during the last
run of make, but for all source files. I don't want to force everyone to see the
warnings if they don't want to, but I think we should provide a set-up that makes it
easy to do so.
Three things are needed:
1. Enable warnings. e.g.
GCCFLAGS=-g -O1 -Wall -pedantic -Wpointer-arith
CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS ./configure
2. Save the error output for each C file as (e.g.) .deps/*.err. E.g. in each
Makefile.in:
%.o: %.cxx
@echo '$(CXXCOMPILE) -c $'; \
- $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
@-cp .deps/$(*F).pp .deps/$(*F).P; \
tr ' ' '\012' .deps/$(*F).pp \
| sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
.deps/$(*F).P; \
- rm .deps/$(*F).pp
+ rm .deps/$(*F).pp; \
+ cat .deps/$(*F).err
3. Display the results (when?). e.g.
find . -type d -name .deps -exec cat {}/*.err \;
So, can anyone suggest good ways of doing each of these steps, especially step 2: how
do I get that change into every Makefile.in, or what would be a better way?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Metakit build problem...
Gene Buckle wrote: I get the attached error when building Metakit. I'm using the latest Cygwin installation. g++ -c -O2 -I../unix/../include -I/usr/include/generic -I/usr/include ../unix/../tcl/mk4tcl.cpp -DDLL_EXPORT -DPIC In file included from ../unix/../tcl/mk4tcl.cpp:22: ../unix/../tcl/stubtcl.h:3: syntax error before `*' I had the same problem building MetaKit on CygWin. I just typed: ../unix/configure --without-tcl and the rest of it would then build and install, which was enough for FlightGear. (n.b. The --without-tcl option was broken in metakit version 2.4.2, but fixed in 2.4.3) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
I now have a practical solution for saving the compiler warnings: a wrapper script
replacement for the compiler.
rm config.cache # Otherwise it keeps the previous values of CC and CXX.
GCCFLAGS=-Wall -pedantic -Wpointer-arith
CC=saveoutp gcc CXX=saveoutp c++ CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS
./configure
where ~/bin/saveoutp contains:
#!/bin/bash
# Run a program, also capturing stderr to a file.
#
# Usage: saveoutp program option... filename
#
# Treat the argument list as a shell command. Run the command, displaying
# stderr but also capturing it into a file named .deps/filename.err.
# (Bug: the command's exit status is reduced to just true or false.)
if [ -d .deps ] ; then
# Make name of error file from last positional argument.
ERRFILE=.deps/${!#}.err
# Execute program; save stderr; display stderr; return true/false exit code.
{ $* 2 $ERRFILE cat $ERRFILE 2; } || { cat $ERRFILE 2; false; }
else
$*
fi
This wrapper script is specific to Bash, but it would be possible to write one for any
shell that can redirect stderr, or even write a compiled program.
Then you will always have the last warnings available for each C file and can run
(e.g.)
cat src/*/.deps/*.err
to see them.
[
My previous attempt was no good. I wrote:
2. Save the error output for each C file as (e.g.) .deps/*.err. E.g. in each
Makefile.in:
...
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
...
But if the compilation fails, 'make' will quit before displaying the error output
file. That's no good. It needs to be done within a single command. What I really
need is one of these:
gcc 2| tee file.err# No: stderr-pipe not available AFAIK, and exit
status is lost.
gcc 2 file.err 2 /dev/con# No: in Bash the first output file has nothing
written to it.
gcc 2(tee file.err) # No, though Bash can _almost_ do this on _some_
systems.
gcc 2 file.err || { cat file.err; false; } # This might just about work!
... but I don't know if I can get automake to put stuff like this in the generated
make files.
]
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS log browser broken
Curtis L. Olson wrote: I'm not a python expert and do not claim to have any knowledge on the subject. But tcl will give very similar errors when a sub program dies. It builds a pipe to the IO of the other process and if it dies it reports a 'broken pipe.' So my best guess is still that enscript is dying, breaking the 'pipe' between it and the viewcvs python script. OK. I know almost nothing about it, so I expect you are right. Maybe for now I'll just hope the problem goes away when the next version comes out. No problem. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Andy Ross wrote: Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. Yup, I see just the same as you. On crossing the dotty white crack, my little plane topples over on its back like a beetle waving its legs in the air. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote:
I've just checked in a new patch for automatic joystick type detection
(where available). NOTE: it will work *only* if you have a recent (2
months or so) CVS version of plib.
...
Please send me your bindings for your own device. Under Linux, you
can find the device name with a command like
jstest /dev/js0 | less
(You must include any trailing spaces.)
May I offer this patch which will help non-Linux users find their joysticks' names:
Index: js_demo.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Input/js_demo.cxx,v
retrieving revision 1.1
diff -u -3 -p -d -r1.1 js_demo.cxx
--- js_demo.cxx 4 Jun 2001 19:26:53 - 1.1
+++ js_demo.cxx 5 Jul 2002 17:47:09 -
@@ -26,9 +26,12 @@ int main ( int, char ** )
t = 0;
for ( i = 0; i Z; i++ )
{ useful[i] = ! ( js[i]-notWorking () );
-if ( useful[i] )
+if ( useful[i] ) {
t++;
-else printf ( Joystick %i not detected\n, i ) ;
+#ifdef FG_PLIB_JOYSTICK_GETNAME
+ printf ( Joystick %i: \%s\\n, i, js[i]-getName() ) ;
+#endif
+} else printf ( Joystick %i not detected\n, i ) ;
}
if ( t == 0 ) exit ( 1 ) ;
For my Saitek Cyborg 3D Gold USB joystick, that gave:
Joystick test program.
~~
Joystick 0: Microsoft PC-joystick driver
Joystick 1 not detected
...
which is presumably because I haven't bothered to install Saitek's driver, because the
default Windows one does the job. Some other people will have done the same, of
course, but there's not a lot we can do about it.
On a related note (Windows compatibility), a given joystick's axes are sometimes
numbered differently under Windows and under Linux. This is nearly always true for
the hat switch with the present version of PLIB. Therefore we should either:
- provide different configurations for the same joystick under different OSs; or
- make PLIB present the axes numbered in the same way under all OSs.
PLIB is supposed to provide cross-platform portability, so obviously the latter should
be attempted. It is not a simple bug in PLIB, it is a slightly complicated issue due
to the different ways the joystick interface is provided by the different OSs, and may
rely on cooperation from the vendor driver writers. I will raise the issue on the
PLIB list.
One more point: it would be good to separate the joystick axis number-to-name mappings
(axis 0 = left/right, axis 2 = twist, axis 3 = slider, etc) from the name-to-function
mappings (left/right = ailerons, twist = rudder, etc.). At least, if we don't
separate them, we should probably make sure that all of our joystick mapping files
give the same functions. It would be silly if users find that the twist axis controls
rudder when they use some types of joystick, but controls view direction when they use
other types.
I have hat fwd/back mapped to elevator trim. Are we standardising on the hat
controlling view direction (for the supplied bindings; I know I can keep my local
changes)?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
I (Julian Foad) wrote: For my Saitek Cyborg 3D Gold USB joystick, that gave: Joystick test program. ~~ Joystick 0: Microsoft PC-joystick driver Joystick 1 not detected ... which is presumably because I haven't bothered to install Saitek's driver, because the default Windows one does the job. Some other people will have done the same, of course, but there's not a lot we can do about it. Hmmm... Saitek's driver for the Cyborg 3D Gold USB is called Saitek Gaming Extensions (e.g. SGEv3.exe). This is NOT a joystick driver (the default Windows driver is used) but just facilites for customising the joystick for different games. I installed it but it did not change the name reported. Does this happen with all USB joysticks? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote:
I've just checked in a new patch for automatic joystick type detection
(where available). NOTE: it will work *only* if you have a recent (2
months or so) CVS version of plib.
The present sets of bindings result in the throttle being squared about its centre,
which is silly. This is because the squared parameter is not set by the throttle
binding, but the default is true. We discussed this before and I think there was
general agreement that the default should be false on the basis of generality.
Therefore may I request this change to the default (in src/Main/fg_commands.cxx):
class PropertyCommandState : public SGCommandState
{
...
virtual const SGPropertyNode * getSquared () const
- { return _squared ? _squared : _dummy_1; }
+ { return _squared ? _squared : _dummy_0; }
...
};
Thanks.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS not working
The CVS server is not working for me at the moment. It was working 10 hours ago when I last tried it. $ cvs diff cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS not working
Curtis L. Olson wrote: Julian Foad writes: The CVS server is not working for me at the moment. It was working 10 hours ago when I last tried it. $ cvs diff cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF Seems to be working for me at the moment. Yes, it's back again for me too. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug tracker
The SourceForge Bug Tracker has the following outstanding bug reports: ID SummaryDate Assigned To Submitted By 433286 Sun lights plane at night. 2001-06-14 17:33 nobody dmegginson (still a bug) 433288 Switching view causes slow pan.2001-06-14 17:38 nobody dmegginson (still a bug) 433735 FDM Airport Altitude 2001-06-16 07:38 nobody apeden 435655 no terrain intersection bug at e75n35 2001-06-22 20:39 nobody hrothgar 439307 LaRCSim Segfault Bug 2001-07-07 09:31 nobody nobody 440019 Aircraft level when it shouldn't be2001-07-10 05:02 nobody nobody 471112 Visual zoom out squashes and twists view 2001-10-14 14:03 nobody julianfoad (fixed) 471116 Some text on panel stays white at night2001-10-14 14:09 nobody julianfoad (mostly fixed) 471118 Turn ball flickers from side to side. 2001-10-14 14:14 nobody julianfoad (fixed) 471127 Setting sun chopped by horizon and cloud 2001-10-14 14:39 nobody julianfoad (still a bug) 471134 Httpd seg-faults on invalid paths. 2001-10-14 14:46 nobody julianfoad (I have a fix; not in CVS yet) 471136 Nav needle flickers when nav radio off 2001-10-14 14:50 nobody julianfoad (still a bug) 477578 Mouse pointer lost when menu turned off2001-11-02 09:33 nobody dluff 504761 No video when starting FGFS2002-01-16 23:41 nobody jtwilley I have marked the status in parentheses of some of these. (The oldest one is still a hot topic!) Anyone got any info on the rest? I don't know whether the tracker can be made to send notification to this mailing list of any new reports or changes, but I would like that as long as the frequency stays low. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] concave mirrors
The focal point is where rays will be focussed to/from a parallel beam of light - like the rays from an object at infinite distance. The theory is normally quoted in these terms, as it avoids having to consider two distances at once (the distance to the object and the distance to the image or observer). Thus: / Parallel rays from a distant object / | | + Are all focussed to here | (the focal point, by definition) \ \ ... but in real life, the object will be nearer than infinity ... / /Non-parallel rays from nearby object (O) | | + I O | \Are focussed to an inverted real image somewhere else (I) \ ... and as the object moves closer to the mirror, the image of it moves further away, and crosses over the object position (at the point where, looking into the mirror, you find the image of your eye disappearing into a singularity) and continues to move further away until ... / / | Rays from an object at the focal point (O) | O | \ \ Are focussed to infinity ... you get back to an easy-theory situation. The geometry of the intermediate positions is probably something like: (1 / distance_to_object) + (1 / distance_to_image) = (1 / focal_length) ... at least qualitatively. I don't know whether that is correct quantitatively. I hope this was the clue to the obvious that you needed. - Julian Curtis L. Olson wrote: Ok, this is *way* off topic, but I'm hoping the people here are a bit smarter than my stupid coworkers (I guess stupid _self_ is implied.) :-) The following web site explains the basic behavior of a concave mirror and pretty much agrees with everything I remember from physics: http://www.physicsclassroom.com/Class/refln/U13L3a.html If the object distance is beyond the focal point, the reflected image will be inverted. If the object is at the focal point, the reflected image will hit a singularity. If the object distance is less than the focal length, the object will be magnified and right-side up. Now, I have a concave mirror with a 40 radius of curvature. This means it has a 20 focal length. My problem is that I'm not observing behavior that matches the theory. My initial speculation is that the position of my eye is an important factor that isn't addressed by the simple theory, but from the simple theory, I don't see how that could be possible. Here are some things I'm observing: if my eye is closer to the mirror than the focal distance, I see myself and the entire room right side up. Even though objects in the distance (i.e. the other side of the room) are further than the focal point, they are still right-side up. If I move my eye point away from the mirror and watch myself, I seem to hit the singularity at 40 which is the center of curvature, not the focal point. Yes, I've verified that the radius is indeed 40 and is most definitely not 80. If my eye point is further than 40 I can move an object (such as a pen in and out and it hit's the singularity at 40 and inverts beyond that.) If I move my eye away from the mirror and watch an object on the otherside of the room, it hits the singularity and inverts at 20. This sort of agrees with the above theory except it's a distant object that never moves, only my viewpoint is moving. ?!? I've been trying to reconcile this all in my head and have put myself into a state of complete befuddlement ... Can anyone tell me what stupid thing I am missing? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Updating to new CVS trunk repository
Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Joystick files still contain bad names
Two base package files, Input/Joysticks/CH/pro-pedals-usb.xml Input/Joysticks/CH/pro-yoke-usb.xml both still (or again) contain nameMicrosoft-PC-Joysticktreiber /name namePilote de joystick PC Microsoft /name which is less than useful as discussed before. Please could someone remove those lines, and could contributors please be careful not to include such lines in their contributions. Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? - Julian Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Curtis L. Olson wrote: Julian Foad writes: Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? Personally, I just did a fresh checkout. Curt. D'oh. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Julian Foad wrote: Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v ... Can anyone tell me how to get CVS update going again? Well, I think I've worked out what I need to do: 1. Connect to the old repository (was -0.7, now renamed to -0.8, I think) and update to the 0.8 release tag (there is one, I hope) which indicates the point at which you created the new (-0.9) repository. 2. Connect to the new repository (-0.9), force all my local CVS/Entries files to refer to revision 1 of each source file, and then update. Anybody want to stop me before I try this? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internal compiler error
Andy Ross wrote: http://www.memtest86.com/ I haven't noticed random crashes or corruption in the two years I've been running my current PC, but I decided to try this anyway. Most of the tests showed no problems, but the block move tests found thousands of errors, mostly in a particular bit of the data bus. I was surprised and concerned! This is running at rated speed; I haven't yet tried under-clocking. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FWIW
Cameron Moore wrote:
Also while I'm here, I wanted to mention that I get around 3 spams per
day to the flightgear lists that noone ever sees (I'm the primary
moderator if you haven't picked that up yet). The moderating is working
out pretty well I think.
Yes, it must be because I haven't noticed anything. My day job is
firmware for building control systems (ventilation, heating, lighting
etc.) so the same criterion applies: if the customers don't notice it
then it is working well.
trying_to_make_myself_seem_more_useful('ly yours');
Ooh! So you run a 64-bit C compiler!
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross wrote: This is a good point, actually. Almost all the Linux filesystems use a 4k block as the minimum allocation unit*, and I presume NTFS is similar. I thought it was the other way around: that most Linux filesystems (by which I mean ext2) and NTFS had 1K or 0.5K blocks, and that Windows FAT filesystems had big (generally 4K to 16K) blocks. [* Geeky aside: reiserfs doesn't. It has a unique tail folding feature where the last sub-block of files gets folded into a single block with the tails of other files, so small files take space proportional to their actual size. Very cool, although apparently not used much.] ReiserFS is the default with SUSE 8.1 which I've just installed. Oh yes ... hey folks, I've just made the switch from Windows to Linux. Played with RedHat and Debian a couple of times in the last few years, but now I think it's a permanent switch. The windows issue is, I think, true only on very old FAT32 variants. I'm pretty sure the block size limitation went away at the same time the 2G limit did, no? Everything from Win98SE on should be fine, I believe. Any windows users want to comment? Certainly anyone running XP won't have this problem. My Windows ME (successor to 98SE) had a single 15 GB FAT-32 partition, and it uses 8 KB blocks. On that, FG scenery was eating large chunks of my disk space. I think FAT-32 is capable of using small (0.5K or 1K) blocks but is not configured to do so because the FAT itself would be big and therefore slow when following the block chain in large files. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
Jacek M. Holeczek wrote: ... There are two problems with the joystick. First, there are two vertical bars/arrows in the cockpit for the elevators, but only the right one is following the joystick (the left one always stays in the middle) - however, if I view the plane from outside I can see that both (left and right) are moving up/down. This is correct: the right-hand indicator is indicating elevator position, but the left-hand indicator is indicating elevator trim, which can be adjusted with numeric keypad 7 and 1 (or is it 9 and 3) and possibly with joystick buttons/hat switch if the joystick configuration file says so. Second - both the aileron and elevator quite often misbehave - what I observe is that when I move them then appropriate bars/arrows are also moving, but every now and then the bars/arrows suddenly jump to the neutral position (and so they quite often jump between the actual joystick position and the neutral position). This can also be seen when I view the plane from outside - indeed ailerons and elevators are jumping - this makes the steering quite difficult. I monitored the joystick with an external utility and this utility does not show such problems, so it must be the software. I did not observe such problems with the rudder, but ... maybe it is just the lack of experience. That sounds like both the joystick and some other input device are trying to drive the controls at the same time. The other device might be the mouse, which has three modes, indicated by three different cursor shapes. Clicking the right-hand mouse button cyles around the three modes. When the cursor is a normal pointer, it is for pointing and clicking on menus and the panel controls. When it is a cross (+), it is in control of the elevators and ailerons - perhaps that is what you have. When it is a double arrow (=) it controls the view direction, for looking around. Hope this helps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 pannel lights
Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Agreed. Instruments that test whether they are powered should default to powered if the aircraft does not provide a suitable electrical system. This could translate to if the required power bus property is not present. A simple default electrical system that provides just a main bus would only satisfy instruments that connect _directly_ to the main bus. I know that David disagrees with me on some of this, but my view is that the electrical system should provide common named outputs. Hang on ... I don't think these are mutually exclusive options. Woudn't you agree that, as well as standardising on bus names as much as possible, it would be good to smooth the transition from always-on to having a proper electrical system, by making all instruments default to on if they have been modified to check whether power is provided but have been plugged into an aircraft which does not yet specify any electrical system? For instance, panel lights would always check /systems/electrical/outputs/panel-light-power or something like that. And the green navigation light would check /systems/electrical/outputs/nav-lights-power and the turbofan engines' fuel flow monitors would check /systems/electrical/outputs/engines/engine[n]/monitoring-power and ... The only way I can see of making a generic simple electrical system serve this scheme is if we can somehow make /systems/electrical/*/*-power return true - i.e. any unknown property under a given branch returns a default value. I don't think the property mechanism has this feature at the moment, but it might be possible to add it. However, I completely agree that, to the extent possible, it makes sense to standardise the names. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Curtis L. Olson wrote: I'm guessing that Ay / Az is roughly proportional to Fy / Fz so these two methods won't be exactly the same, but should be similar enough. Well, a classic rule of physics is F = m.a (force = mass x acceleration) and that applies to the directions of the force and acceleration as well as their magnitudes. Therefore at every instant Ay / Az must be precisely equal to Fy / Fz. Well, assuming that Ay is in the same frame of reference as Fy, etc. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote:
What I would like to propose for people's consideration, is the idea
of taking each of FlightGear's component libraries and converting them
to the LGPL license. The top level wrapper code (i.e. whatever is in
src/Main) would remain GPL.
Well, it doesn't matter what license is used for the wrapper code:
for (i=1, iN; ++i) {
subsystem[i].start();
}
because anyone could re-write it easily. Effectively we're talking
about putting as much as possible under LGPL. At first I thought that
sounded like betrayal, but now I'm thinking it sounds good. It would
allow companies who sell a product to include part or (essentially) all
of Flight Gear in their product. They would still have an obligation to
make freely available any modifications to Flight Gear components, so we
and anyone else would not lose out and might benefit if they felt
generous. They might just put minimal hooks in to get at what they
need, and not contribute anything valuable back to us. I don't think
that matters much. They won't gain a special commercial advantage,
because all of their competitors will be able to use FG in their
products too.
If we do not do this, companies which might want to use (part of) FG in
their products will instead write their own proprietary code, and almost
certainly keep it proprietary. Their potential input to the world of
computing will be sealed in a private box and never shared.
Curt, you have mentioned before that you work in a Human Factors
Research Lab and use FG (or parts of it) for (ground-) vehicle display
systems. I assume you are thinking of enabling a commercial product to
be made from this. That's OK by me.
As a programmer I strongly support measures that avoid duplication of
work. I'm not sure whether GPL does this better by persuading users
to share their own code so that they can use shared code, or the LGPL,
by giving users more flexibility with what they can do.
If people are concerned about unfair use of LGPL'd libraries, then we
should think about how to make such a library less susceptible, probably
by making its interface tighter.
Disclaimer: these are just some current thoughts, and I reserve the
right to change my mind.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
Curtis L. Olson wrote: ... What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. ... mod-up would seem to be the appropriate syntax. If that doesn't work for mouse buttons, perhaps making it work for mouse buttons would be better than inventing a new type of action. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraGear build failure: global_logstream/rstrip
With GCC 3.2 I get: Making all in DemChop make[3]: Entering directory `/home/julianfoad/src/TerraGear/src/Prep/DemChop' saveoutp c++ -O1 -finline-limit-256 -finline-functions -Wall -pedantic -Wpointer-arith -L/usr/X11R6/lib -o demchop demchop.o ../../../src/Lib/DEM/libDEM.a -lsgbucket -lsgmisc -lsgdebug -lsgxml -lz -lm demchop.o: In function `main': demchop.o(.text+0x52): undefined reference to `global_logstream' demchop.o(.text+0x7f): undefined reference to `global_logstream' demchop.o(.text+0x8c): undefined reference to `global_logstream' demchop.o(.text+0xa4): undefined reference to `global_logstream' demchop.o(.text+0xe9): undefined reference to `global_logstream' demchop.o(.text+0xef): more undefined references to `global_logstream' follow ../../../src/Lib/DEM/libDEM.a(dem.o): In function `FGDem::read_a_record()': dem.o(.text+0x423): undefined reference to `simgear::strutils::rstrip(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: ld returned 1 exit status PLIB and SimGear were built from today's CVS, and installed. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraGear bits and pieces
I am carrying some local changes to TerraGear which probably ought to go
into CVS. Patch attached. They are just minor and cosmetic fixes;
nothing that affects the generated scenery.
- Julian
Index: acinclude.m4
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/acinclude.m4,v
retrieving revision 1.1
diff -u -3 -p -d -r1.1 acinclude.m4
--- acinclude.m428 Aug 2002 14:13:51 - 1.1
+++ acinclude.m424 Oct 2002 14:26:38 -
-102,7 +102,7 for exdir in $exdirs ; do
mylibdir=${exdir}/lib${subexdir}
wi_EXTRA_LDIR($mylibdir)
- progdir=${exdir}/bin${subexdirr}
+ progdir=${exdir}/bin${subexdir}
wi_EXTRA_PDIR($progdir)
fi
done
Index: configure.ac
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/configure.ac,v
retrieving revision 1.5
diff -u -3 -p -d -r1.5 configure.ac
--- configure.ac18 Oct 2002 22:25:45 - 1.5
+++ configure.ac24 Oct 2002 14:26:40 -
-240,6 +240,8 fi
AC_MSG_CHECKING(for proper simgear version)
AC_TRY_RUN([
+#include stdio.h
+
#include simgear/version.h
#if !defined(SIMGEAR_VERSION)
-256,7 +258,8 AC_TRY_RUN([
int main() {
int major, minor, micro;
-printf(%d.%d.%d or greater... , MIN_MAJOR, MIN_MINOR, MIN_MICRO);
+printf(need %d.%d.%d, have %s... , MIN_MAJOR, MIN_MINOR, MIN_MICRO,
+STRINGIFY(SIMGEAR_VERSION));
sscanf( STRINGIFY(SIMGEAR_VERSION), %d.%d.%d, major, minor, micro );
Index: src/Airports/GenAirports/rwy_prec.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Airports/GenAirports/rwy_prec.cxx,v
retrieving revision 1.3
diff -u -3 -p -d -r1.3 rwy_prec.cxx
--- src/Airports/GenAirports/rwy_prec.cxx 22 Mar 2002 15:05:54 - 1.3
+++ src/Airports/GenAirports/rwy_prec.cxx 24 Oct 2002 14:26:41 -
-88,7 +88,7 void gen_precision_rwy( const FGRunway
double length = rwy_info.length / 2.0;
if ( length 3075 ) {
SG_LOG(SG_GENERAL, SG_ALERT,
- This runway is not long enough for precision markings!);
+ Runway rwy_info.rwy_no is not long enough (
+rwy_info.length ) for precision markings!);
}
double start_pct = 0;
Index: src/BuildTiles/Parallel/client.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/BuildTiles/Parallel/client.cxx,v
retrieving revision 1.11
diff -u -3 -p -d -r1.11 client.cxx
--- src/BuildTiles/Parallel/client.cxx 30 Jan 2002 14:10:00 - 1.11
+++ src/BuildTiles/Parallel/client.cxx 24 Oct 2002 14:26:43 -
-200,7 +200,7 bool construct_tile( const SGBucket b,
for (int i = 0; i (int)load_dirs.size(); i++) {
command = command + + load_dirs[i];
}
- command = command + + result_file + 21;
+ command = command ++ result_file + 21;
cout command endl;
system( command.c_str() );
-253,7 +253,8 usage (const string name)
cout--host=address endl;
cout--port=number endl;
cout--rude endl;
- cout--cover=landcover-raster ] endl;
+ cout--cover=landcover-raster endl;
+ cout--min-angle=degrees ] endl;
cout load directory... endl;
exit(-1);
}
Index: src/Lib/Geometry/line.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Lib/Geometry/line.cxx,v
retrieving revision 1.4
diff -u -3 -p -d -r1.4 line.cxx
--- src/Lib/Geometry/line.cxx 14 Aug 2002 15:41:54 - 1.4
+++ src/Lib/Geometry/line.cxx 24 Oct 2002 14:26:46 -
-48,7 +48,7 Line::addPoint (const Point3D point)
_points.push_back(point);
}
-const Rectangle
+Rectangle
Line::getBounds () const
{
Point3D min;
-68,11 +68,9 Line::getBounds () const
if (_points[i].y() max.y())
max.sety(_points[i].y());
}
-return Rectangle(min, max);
}
- Rectangle bounds;
- return bounds;
+ return Rectangle(min, max);
}
};
Index: src/Lib/Geometry/line.hxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Lib/Geometry/line.hxx,v
retrieving revision 1.3
diff -u -3 -p -d -r1.3 line.hxx
--- src/Lib/Geometry/line.hxx 14 Aug 2002 15:41:54 - 1.3
+++ src/Lib/Geometry/line.hxx 24 Oct 2002 14:26:46 -
-82,7 +82,7 public:
*
* return The bounding rectangle.
*/
- virtual const Rectangle getBounds () const;
+ virtual Rectangle getBounds () const;
private:
vectorPoint3D _points;
Re: [Flightgear-devel] Clickable cockpit
Andy Ross submitted a patch which changes the way the HUD works. Norman Vine wants the old behaviour to remain available as an option. I really shouldn't get involved in this, but ... well ... here are my views. When a developer changes a program that is used by other people, he/she needs to consider the inconvenience that change may cause, and to minimise that inconvenience as far as is compatible with the other aims. Perhaps someone has developed other software which interfaces to FlightGear and will need to be changed to accommodate these changes. For example, Andy says he has inverted the sense of the compression tag to correct it. If the only configuration files that matter are under our control then he should supply a patch to fix them and the correction will be complete. If users are likely to have their own files which would, after this patch, be broken, he should consider fixing the problem in a backward-compatible manner, e.g. by deprecating the existing tag while introducing a new one. The important point is how to judge, for each little change, whether backward compatibility is worth the effort. Airing the proposed change and listening to objections is an OK way to do this. However, when the number of people objecting is small, the objection itself appears small unless it is backed up by reasons. Norman seems to be wanting backward compatibility in general, which may indicate that he _uses_ this flight simulator more than _plays_ with it, which is great. Unfortunately it takes a lot of effort to keep backward compatibility in every respect, and so the request is just wishful thinking unless it can be narrowed down to specific items of importance. Because Norman's skill and contributions to the project are respected, other developers want to keep the features that he values while still being able to develop the software and change things that don't seem right. If no progress is made soon, I recommend that the old behaviour option be implemented, and that Andy should modify the if statement so that it can be selected at run time. That would seem to satisfy the current objection, subject to the compatibility of the HUD configuration files being satisfactory. Then a separate patch to delete the old functionality can be proposed immediately, and the discussion of that can continue without holding up development in the short term. When the maintenance of that old codes becomes a hindrance, that will be an argument for removing it. At least, in the short term, it will be useful to have the old version available while any issues with the new version are resolved. Finally, I believe V. S. Renganathan did substantial work on the HUD for use in a research project. If anyone knows whether he is still interested in it, that might also be helpful. Please let the resolution be swift and easy so that developers will not be put off trying to change anything. - Julian Foad, Secretary, IASFGP (International Arbitration Service for Flight Gear Programmers) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Clickable 3D panel
Lovely stuff. For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). So there are two places you can click to get the autopilot wing leveler button, or any other button. One where you can see the button, and another where the same button would appear on the other type of panel. A minor misalignment of some of the hotspots makes one or two controls a little awkward (e.g. COM1 tuning button). That is nothing to do with the 3D code; they are misaligned in the 2D view as well. That is, if you click just to the left of the centre of that knob it should decrease the digits but it increases them instead. A way to display the hot-spot outlines would be useful for checking and debugging ... don't know if that's as easy as it sounds though. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross wrote: Julian Foad wrote: For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). Are you sure? I thought this might be it too, and tried tracking it down. The 3D panels are loaded through the model code, and never get a chance to register themselves as the current_panel object in globals. Is there an invisible 2D panel loaded from somewhere else? FWIW, I still haven't been able to duplicate the rogue mouse click problem. Well, I'll put it this way: If I turn the 2D panel on and off with P while flying --aircraft=c172-3d, and note where a particular button is, and then turn it off so that only the 3D panel is visible, I can still click where the 2D button was as well as where the 3D button is visible. Clicking in either place has the same result of activating the feature. As I said, if the position of one of these invisible 2D hot-spots obscures a 3D hot-spot, then the 3D one appears not to be working, until you change view direction a bit or zoom so it is in a different area of the screen. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ExternalNet FDM
Martin Spott wrote: So the only command line change would be to go from --native=socket,in,30,,5500,udp --fdm=external to --native=socket,in,30,,5500,udp --fdm=null btw, do we have an 'official' port number assignment ? Over the time I read several suggestions by several members over the use of port 5500: --props=socket,bi,5,localhost,5500,tcp --nmea=socket,out,2,localhost,5500,udp --httpd=5500 --native=socket,in,30,,5500,udp --fdm=null [... maybe some more ...] It would be useful at least to postulate a FlightGear assignment - it does not have to meet RFC1340 Martin. Actually I don't think 5500 is a good idea - it is already assigned to someone else: fcp-addr-srvr1 5500/tcp fcp-addr-srvr1 fcp-addr-srvr1 5500/udp fcp-addr-srvr1 # Mark Zeiss [EMAIL PROTECTED] (see http://www.iana.org/assignments/port-numbers). Unless and until we have an assigned number, we should use a number from the Dynamic and/or Private Ports range: 49152 through 65535. So 55000 would be OK! Of course you can use any number you like on a private network (not connected to the Internet, and where you know that the port you choose is not in use by any other protocol) or when you know that the machines sending and receiving are not going to use that other protocol. There is actually a reasonabe chance that an assigned port number would be granted if we requested one. My company recently got one, even though I was expecting we wouldn't be able to justify the need for it. However, I don't think it would be appropriate until the protocol has settled down and been used for a while. So may I suggest changing the suggested number to 55000 in the documents that mention it? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
David Megginson wrote: A while ago, Curt suggested moving from ... and so on, to something more sane: /controls/engine[0]/ /controls/engine[1]/ /controls/engine[2]/ /controls/engine[3]/ Yes, lovely. Excellent. We could even go to /controls/engines/engine[0/ and so on to simplify the /controls/ top level further. No - we have that in some places, but I was thinking recently that it's not the right way to go. I think the only practical purpose is to reduce clutter in the browser; but the property browser could and should do this for us if we want it to. For example, it could display controls/ elevator engine[*] flaps ... and then, when the user clicks on it, expand it to controls/ elevator engine[0] engine[1] engine[2] engine[3] flaps ... or to controls/engine [0] [1] [2] [3] From an abstract point of view, engines/engine[n]/ could more succinctly be arranged as engines/n/ or engine[n]/ and this last seems to be the way the property manager was designed to handle it. Note that engines/engine[n]/ is identical to engines[0]/engine[n]/ which starts to look a bit silly again. Just my opinion. Also, could a similar thing be done with the engine output properties (mainly to drive the guages - RPM, temperature, etc.)? I can't think right now where they are at the moment. I have this vision of enabling the JSBSim piston engine and the Yasim piston engine models to be plug-in-compatible with one another. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Engine models: start-up and commonality between FDMs
I was having a look at the piston engine start-up code. I absolutely love the way it chugs away for a second or two and then coughs into life - the sound effects really make it - but I wanted to make the speeds and stuff more realistic. Looking at the JSBSim engine code, it uses lots of arbitrary speeds and time delays and abrupt transitions from one mode to another. I have some improvements to this. Much of this code in JSBSim is very similar to FDM/IO360.cxx which seems to be only used by LARCsim even though it is not in the LARCsim subdirectory; presumably one was derived from the other. I really don't like duplication; I feel that any work I do on one of them is half wasted if it isn't automatically shared by the other. And then there is Yasim's engine code. Three piston engine models, each specific to its own FDM. So I started thinking about deriving them all from a common PistonEngine interface with the aim of making the engine models interchangeable. Haven't gone anywhere down this road yet, though. Thoughts? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross wrote:
[about making the panel hot spots visible]
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property.
That is excellent! So simple, and in conjunction with David's recent
zoom in/out/normal (+/-/=) bindings, it immediately makes clear what's
going on with the hot spots, and shows up the existing mistakes.
Everyone designing clickable instruments will benefit from this, so I
think your patch should go into CVS permanently.
I was just trying to sort some hot spots out by editing the numbers,
when I remembered that you'd just sent this patch. What a powerful tool
visualisation is!
- Julian
Index: panel.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.hxx,v
retrieving revision 1.2
diff -u -r1.2 panel.hxx
--- panel.hxx 29 Oct 2002 19:44:03 - 1.2
+++ panel.hxx 5 Nov 2002 21:38:59 -
-370,6 +370,7
virtual ~FGPanelInstrument ();
virtual void draw () = 0;
+ virtual void drawHotspots();
virtual void setPosition(int x, int y);
virtual void setSize(int w, int h);
Index: panel.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.3
diff -u -r1.3 panel.cxx
--- panel.cxx 29 Oct 2002 19:44:03 - 1.3
+++ panel.cxx 5 Nov 2002 21:38:59 -
-436,6 +436,21
glPopMatrix();
}
+ // Draw yellow hotspots if directed to. This is a panel authoring
+ // feature; not intended to be high performance or to look good.
+ if(fgGetBool(/sim/panel-hotspots)) {
+glPushAttrib(GL_ALL_ATTRIB_BITS);
+glDisable(GL_DEPTH_TEST);
+glDisable(GL_TEXTURE_2D);
+glColor3f(1, 1, 0);
+
+for(int i=0; i_instruments.size(); i++)
+ _instruments[i]-drawHotspots();
+
+glPopAttrib();
+ }
+
+
// restore some original state
glPopAttrib();
glPolygonOffset(0, 0);
-647,6 +662,25
it++) {
delete *it;
*it = 0;
+ }
+}
+
+void
+FGPanelInstrument::drawHotspots()
+{
+ for(int i=0; i_actions.size(); i++) {
+FGPanelAction* a = _actions[i];
+float x1 = getXPos() + a-getX();
+float x2 = x1 + a-getWidth();
+float y1 = getYPos() + a-getY();
+float y2 = y1 + a-getHeight();
+
+glBegin(GL_LINE_LOOP);
+glVertex2f(x1, y1);
+glVertex2f(x1, y2);
+glVertex2f(x2, y2);
+glVertex2f(x2, y1);
+glEnd();
}
}
Re: [Flightgear-devel] data logging
Boslough, Mark B wrote: O.K. I've got a couple of new FDMs. 1) fdm=csv replays a flight from a csv file, running forward or backwards in time while controlling the rate. 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). Have you tried --fdm=ufo? It can go backwards. Just want to check if you've done something that's already there. Hmm ... I see that it isn't mentioned in the --help. Ooops. But it does exist. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Megginson wrote: I like the idea as well: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs (let's try the J3 cub with 180HP). Unfortunately, the FDM people haven't been too enthusiastic: in particular, JSBSim is supposed to run standalone as well as inside FlightGear, so they need some kind of internal engine model. Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. While that's the sort of thing I do at work, I'm not yet in a position to do it here. As for the guts of how the engines are modelled ... I first worked on the starting and stopping behaviour of the JSBsim engine. The thermodynamic model of the engine is probably very good but there's lots of yucky stuff there to do with starting etc. I've done some stuff there, and in the sound configuration, but not finished. I'll go into that later. Then I looked at the YASim piston engine to see how that handles starting. Before I try to do anything in there I want to ask about some things (Andy?): 1. PistonEngine::calc says // Calculate manifold pressure as ambient pressure modified for // turbocharging and reduced by the throttle setting. According // to Dave Luff, minimum throttle at sea level corresponds to 6 // manifold pressure. Assume that this means that minimum MP is // always 20% of ambient pressure. (But that's too much idle // power, so use 10% instead!) But we need to produce _zero_ // thrust at that setting, so hold onto the output value // separately. Ick. _mp = pressure * (1 + _boost*(_turbo-1)); // turbocharger float mp = _mp * (0.1f + 0.9f * _throttle); // throttle _mp *= _throttle; What's that bit about the separate output mp? An engine doesn't produce zero thrust at idle, just a low thrust. And manifold pressure isn't supposed to be related to thrust in a simple way, is it? Sorry to peer into a nasty bit. The beauty of Open Source is ... we can see the whole thing, warts and all! :-) 2. At the end of the same function, _egt = corr * (power * 1.1f) / (massFlow * specHeat); if(_egt temp) _egt = temp; When I'm running this at idle, _egt comes out at 80 (kelvin); presumably this should be added to ambient temp (which is 288) rather than clamped to it: _egt = corr * (power * 1.1f) / (massFlow * specHeat); _egt += temp; 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. There is a negative torque added that should make it stop quickly, and I can't see what's wrong with it (that would have this effect). Actually, as acceleration of the engine is equally slow, perhaps the problem is in the transfer of the torque to the external propulsion system code - perhaps the wrong units? 4. That negative torque: Interpolate it away as we approach cruise RPMs, though, to prevent interaction with the power computations. Ugly. Actually, the only way the variable power is used after that point is to compute the EGT, and that wants to know thermally developed power anyway (i.e. excluding the starter motor contribution and the friction reduction) so that should be fine. I think it would be correct to subtract the torque loss at all speeds - in fact, more loss at higher speeds because of gas flow turbulence etc. By the way, the experimental values here were with j3cub-yasim because c172-yasim gives a solution failure for elevator. I have some local changes, but nothing in YASim or anything that I think could affect it - just in the JSBSim engine, sound handling, joystick, etc. For all this, my original aim was just to get simple things like a realistic cranking speed of about 100 RPM, and some rotation sound while the engine is spinning down after being switched off! - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
Andy Ross wrote:
Jim Wilson wrote:
Anyway, what I now remember is this: the camera position as configured
for the chase view is always in relation to the FDM location. And in
the case of Yasim that location is always the nose.
Oh, good point. This will create problems for view direction too --
the viewer will expect to rotate around the center of the aircraft
instead of the nose.
But there are other places in the code that make assumptions about the
location of the aircraft, too, and they have different requirements.
...
Or consider an ILS receiver, which really wants to use the location of
the antenna on the 747, not the cockpit, c.g., or center. (I have no
idea where this is, but I suspect it's closer to the tail, so that the
main gear are what travel down the exact glidepath). Maybe we need
separate origin offsets for all of these applications?
For some of them, definitely. The viewer (eye, camera) position for
internal view must be quite precisely positioned, not just at the centre
of the airframe. Also the altitude (AGL) of the wings for modeling
ground effect. Many other things (measuring altitude for display,
position relative to radio beacons, etc.) would be fine using any origin
that is within the airframe.
Actually, wouldn't a sane default for the view code be to *always*
pick a center point for the offset? That is, just pick the center of
a bounding box computed from the model (or the FDM). This will match
more closely to what the user expects in all cases I can think of.
That would be suitable for the external views. The centre of gravity
would also be fine. Use whichever is more conveniently available; there
are already enough origins to choose from so don't calculate another
unless it is necessary.
It seems clear what ought to be done. Whenever a point on the aircraft
is used for some calculation, it should specify exactly what point is
required. The apparent obstacles to doing this are:
+ the required information is not available
+ concern about the run-time cost of additional calculation
+ the effort of thinking about what is required and implementing it
These can be tackled separately. For the first point, write stubs for
the missing information so that it can be easily added later. Instead
of this:
// Calc additional lift due to ground effect.
// Not sure exactly what FDM-getLocation() is supposed to return but it
// is about 1.2m below the C172's wings.
// Need to generalise this for other aircraft.
lift += calcGroundEffect(getTAS(), FDM-getLocation().height + 1.2);
write this:
// Calc additional lift due to ground effect.
lift += calcGroundEffect(getTAS(), getCentreOfLift().height);
Search for other bits of code that might already need the same
information. If there are none, make a stub function at the top of the
file (or somewhere more appropriate if you can):
// Stubs for missing information
vec3 getCentreOfLift() { return FDM-getLocationEmptyCofG() + 1.2 /*
this is for C172 */; }
If there are already one or more uses, share the function.
For the second point, consider the run-time cost it in context. If it
is expensive and the exact position is unimportant, make the stub do
nothing, with a comment saying why.
Surely each aircraft geometry definition should be obliged to specify
the position of the things we are interested in:
+ eye position of an average pilot (for internal view)
+ centre of lift (for ground effect)
+ nose, tail, wing tips (for crash detection, and for placing the model
not overhanging the end of a runway)
+ landing gear when fully extended, and its compression behaviour (for
ground handling)
+ centre of gravity when empty, and location of variable masses (fuel,
people, baggage)
The definition file would specify these things relative to its own
origin. If we cannot or do not wish to require all of these to be
specified, the Flight Gear class that reads the model definitions could
be made to guess reasonable values for the ones that are missing.
These statically specified offsets are all constant relative to the
rigid airframe. At run time, we can provide variable ones as well:
class AircraftGeometry {
// Get location of various points as an offset relative to some
arbitrary origin.
// User doesn't need to know what the arbitrary origin is; only
differences between
// these offsets are meaningful.
vec3 getOffsetPilotEye(); // constant
vec3 getOffsetCentreOfLift(); // constant in simple models; may be
variable
vec3 getOffsetNoseTip(); // constant
vec3 getOffsetLeft/RightWing/Tail/etc.();
vec3 getOffsetNoseGearExtended(); // constant
vec3 getOffsetNoseGearCurrent(); // variable
vec3 getOffsetEmptyCentreOfGravity(); // constant
vec3 getOffsetCurrentCentreOfGravity(); // variable
// and/or
vec3 getOffsetContactPoint(int n);
vec3 getOffsetVariableLoad(int n);
float getMassOfVariableLoad(int n);
// etc. as required.
}
Actually,
[Flightgear-devel] SimGear patches for GCC 3.2: memrchr and typename
I had to remove a declaration of memrchr from simgear/metar/Local.h to
compile under gcc 3.2 (SuSE Linux 8.1). There are lots of semi-standard
functions declared there that probably shouldn't be.
To fix some warnings I added typename into some typedef lines. I am
not sure about the correctness or the portability of these - especially
the typename additions. Can anyone evaluate these?
These were the errors:
c++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../..
-I/usr/X11R6/include -O1 -finline-limit-256 -finline-functions -Wall
-pedantic -Wpointer-arith -D_REENTRANT -c -o Charcmp.o `test -f
'Charcmp.cpp' || echo './'`Charcmp.cpp
In file included from Charcmp.cpp:1:
Local.h:1118: declaration of `void* memrchr(const void*, int, unsigned
int)' throws different exceptions
/usr/include/string.h:72: than previous declaration `void* memrchr(const
void*, int, unsigned int) throw ()'
and warnings:
SkyBVTree.hpp:217: warning: `typename SkyBaseBVTreeObject,
BoundingVolume::BV' is implicitly a typename
SkyBVTree.hpp:217: warning: implicit typename is deprecated, please see
the documentation for details
(etc.)
- Julian
Index: simgear/metar/Local.h
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/metar/Local.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -d -r1.1.1.1 Local.h
--- simgear/metar/Local.h 7 Sep 2002 02:58:19 - 1.1.1.1
+++ simgear/metar/Local.h 10 Nov 2002 19:28:47 -
-1115,7 +1115,7 int stregion(int);
int ccregion(char *);
char *rgnname(int);
-void *memrchr(const void *, int, size_t);
+//void *memrchr(const void *, int, size_t);
bool sysmonms(char *, char *, ...);
bool sysmoncl(char *);
Index: simgear/sky/clouds3d/SkyBVTree.hpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sky/clouds3d/SkyBVTree.hpp,v
retrieving revision 1.2
diff -u -3 -p -d -r1.2 SkyBVTree.hpp
--- simgear/sky/clouds3d/SkyBVTree.hpp 14 Sep 2002 16:03:39 - 1.2
+++ simgear/sky/clouds3d/SkyBVTree.hpp 10 Nov 2002 19:28:49 -
-214,9 +214,9 class SkyBVTree : public SkyBaseBVTreeO
{
public:
typedef SkyBaseBVTreeObject, BoundingVolume BaseTree;
- typedef BaseTree::BV BV;
- typedef BaseTree::NodeObject NodeObject;
- typedef BaseTree::Node Node;
+ typedef typename BaseTree::BV BV;
+ typedef typename BaseTree::NodeObject NodeObject;
+ typedef typename BaseTree::Node Node;
void Clear()
{
Index: simgear/sky/clouds3d/SkyBVTreeSplitter.hpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sky/clouds3d/SkyBVTreeSplitter.hpp,v
retrieving revision 1.2
diff -u -3 -p -d -r1.2 SkyBVTreeSplitter.hpp
--- simgear/sky/clouds3d/SkyBVTreeSplitter.hpp 14 Sep 2002 16:03:39 - 1.2
+++ simgear/sky/clouds3d/SkyBVTreeSplitter.hpp 10 Nov 2002 19:28:50 -
-52,7 +52,7 templateclass Object
class SkyBoundingBoxSplitter
{
public:
- typedef SkyBaseBVTreeObject, SkyMinMaxBox::NodeObject NodeObjectBox;
+ typedef typename SkyBaseBVTreeObject, SkyMinMaxBox::NodeObject NodeObjectBox;
//typedef SkyBaseBVTreeObject, SkyBoundingSphere::NodeObject
NodeObjectSphere;
#if _MSC_VER == 1200
-183,7 +183,7 class SkyAABBTreeSplitter
{
public:
typedef SkyMinMaxBox BV;
- typedef SkyBaseBVTreeObject, BV::NodeObject NodeObject;
+ typedef typename SkyBaseBVTreeObject, BV::NodeObject NodeObject;
SkyAABBTreeSplitter(const NodeObject* pObjs, unsigned int iNumObjs) :
_splitter(pObjs, iNumObjs) {}
[Flightgear-devel] Keyboard braking power
It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? Personally I do the same for my joystick configuration, but since we've got so many joystick config files, we really need to separate the joystick configurations from the commands that they control in order to be able to change things like this consistently. - Julian Index: keyboard.xml === RCS file: /home/cvsroot/FlightGear/FlightGear/keyboard.xml,v retrieving revision 1.37 diff -u -3 -p -d -r1.37 keyboard.xml --- keyboard.xml2002/11/07 16:30:39 1.37 +++ keyboard.xml2002/11/10 04:29:52 -276,7 +276,7 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[0]/property - value type=double1.0/value + value type=double0.7/value /binding mod-up binding -303,7 +303,7 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[1]/property - value type=double1.0/value + value type=double0.7/value /binding mod-up binding -678,17 +678,17 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[0]/property - value type=double1.0/value + value type=double0.5/value /binding binding commandproperty-assign/command property/controls/brakes[1]/property - value type=double1.0/value + value type=double0.5/value /binding binding commandproperty-assign/command property/controls/brakes[2]/property - value type=double1.0/value + value type=double0.5/value /binding mod-up descRelease all brakes./desc
Re: [Flightgear-devel] Keyboard braking power
Andy Ross wrote: Julian Foad wrote: It seems silly to have the brake key slam on full braking power, if ... This issue came up about a year ago. There really isn't any good resolution. ... My favorite hack, FWIW, was to have the on/off input affect the braking power slowly -- over a second or two. That way you could ... Yes, you're right. That's quite a nice hack - but I see your point. I'm going through my differences from CVS trying to get rid of them by seeing how many would be wanted in CVS. It looks like this is one local modification that I'll just have to keep or delete. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Radio frequency range: min/max/wrap
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. freq. 0 to 140; this should be 118 to 140. But while playing with that I noticed that the wrapping is a bit unpredictable. With (min=118, max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK Pooley's Flight Guide confirms that the range is 108.00 to 117.95 inclusive. But the current implementation that specifies (min=108.00, max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, 108.00, 108.05) skipping 117.95. There is a problem with the way min and max work when wrap is on and discrete steps are being used. Wrap is designed for analogue values to go round in a circle where min and max are regarded as equivalent. On things like our radio frequency controls, it is down to luck (due to floating-point precision) whether (min=118, max=140, step=1) cycles through (139, 140, 119) or (139, 118, 119). Some of the directional instrument controls are specified as (min=0, max=359, wrap=true). These should, I think, all be specified as (min=0, max=360, wrap=true), so that it doesn't skip 359, because in this case the min/max are the end points of an analogue range (not a set of discrete valid values). It doesn't matter whether it reads 360 or 0 for North. So: - Can anyone confirm the min. and max. settable com. frequencies on radios of this general type? I'm fairly convinced now that it must be 118.00 to 139.975 inclusive (or 139.95 on old models with 50 kHz spacing). - Do they wrap from one end of the range to the other? If not, it is easy to model properly. If they do, we need to look more carefully at the way the wrapping handles discrete steps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sound vol/pitch transforms are like panel x/y/r transforms
Fg_sound.cxx implements a way to control the volume and pitch of a sound specified in an XML config file. The optional steps in the volume control group are (and the pitch group is the same): - A variable value: one of A named property An internal special value (e.g. time since the sound started) - Transformed by a function: one of Inverse Absolute Square root Logarithm - Scaled by a (constant) factor - Clamped to (constant) max and min - Added to a (constant) offset These all have sensible (no-change) defaults (except for anomaly 1 below). This group can be repeated; the results are multiplied together except for the offsets which are all added afterwards. Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. The instrument panel transformations (x-offset, y-offset, rotation) have these optional steps: - A variable value: A named property - Transformed by: An interpolation table - Clamped to (constant) max and min - Scaled by a (constant) factor - Added to a (constant) offset These all have sensible (no-change) defaults. This group cannot be repeated. Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: - Leave the handling of the internal special values in the sound module, or find a way to present them as properties. - Add the Interpolate option to the list of functions (Inverse etc.). - Swap the order of Scaling and Clamping in (probably) the sound module (because there are fewer uses there). - Lose the pitch offset bug and the negative scaling factor hack. - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is needed, a general expression evaluator would be better than providing one specific way to combine sub-expressions. For example, I would like to be able to use property values for the things that currently have to be constants. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS gripes
David Luff wrote: On 11/11/02 at 9:38 PM Matthew Law wrote: I've been having problems updating Simgear for a few days. I've tried everything - including moving the lot and starting again but it continually gets stuck at: cvs server: Updating src-libs U src-libs/.cvsignore U src-libs/Makefile.am U src-libs/metakit-2.4.3-33.tar.gz U src-libs/zlib-1.1.4.tar.gz U src-libs/zlib.dsp and goes no further. I have no problems updating the fgfsbase or FlightGear CVS. I don't use compression on CVS (e.g. -z3 etc) as this did seem to cause some unpredictable behaviour in the past. I don't usually have any problems so I just wanted to check with you guys before looking over my box. Given that src-libs/zlib.dsp is the very last file to be updated, and that you don't really need it to be updated anyway if you've already installed zlib, I would think it would be fine simply to hit ctrl-c when it gets stuck at this point and assume that SimGear itself has updated fine. FWIW, I also sometimes see this hang-up behaviour at the end, but so far only when using compression. Yes, I find it's a compression problem too. I have compression set at the default in my ~/.cvsrc so I use cvs -z0 up to update FlightGear (source), SimGear and TerraGear (which are all on the same server and are the only projects with which I have this problem). I used to think it was CygWin-specific but it's just the same on Linux. So, if you're sure -z0 is in effect, I can confirm that hitting Ctrl-C works OK on a cvs update. However, doing a cvs diff blah.diff, Ctrl-C is not good: you lose the end of the diff file. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Erik Hofman wrote: Julian Foad wrote: ... Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. It's not. It is a hack because the behaviour of the part is totally different from the rest. By this hack you would be able to start at the offset level and then scale down according to the property value and the factor. That's why 2. isn't correct either ... Not totally different. Quite similar. Have you looked at the code? The way I read it, a negative value causes the (scaled, clamped, etc.) value to be subtracted from the offset rather than added to it. That is exactly the same as just using a negative scaling factor. The only differences are: - For negative, you want the default offset to be 1; - For positive, you might want the default offset to be 1 or 0 depending on what you are doing! - When the subtraction is done it forgets any value generated by a previous volume group, which means it's only useful in the first group (e.g. the first volume transformation of potentially several volume transformations). OK, I did not notice the need for offset=1 in subtractions. However, this should be the case for volume just the same as for pitch. You don't want the volume to be subtracted from zero either. - Lose the pitch offset bug and the negative scaling factor hack. It's not a bug. A value with a pitch of 0.0 would have a frequency of 0.0 which isn't allowed and can't be heard. It actually should be 1.0! Offset=0 doesn't necessarily mean pitch=0. For example I want pitch=(K * propeller_rpm). When RPM=0 I don't care if pitch=0; I know it doesn't make sense, but volume will be zero too. Maybe the internal sound player algorithm will have to limit the minimum pitch to something other than zero, but that shouldn't stop me from requesting it to be as near as possible to zero. - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is They are needed to add an envelope to the sound. It is for example possible to start playing a sound based on a property, and change it's behaviour based on another property (change it's pitch and/or volume). No, we could have that ability with one volume transformation and one pitch transformation per sound. (These are separate from the sound on/off property.) I'm asking whether we need more than one transformation of each type. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) Neh, better not. OK, I agree it's not as simple as I first thought. I'll think more carefully. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Luff wrote: On 11/10/02 at 4:02 AM Julian Foad wrote: Ah yes, starting, I seem to recall a lot of hacking and kludging to get everything to work :-) There's a number of problems currently: ... Have fun :-) Ah, glad you're there. If you're interested and have time to look, my current attempt is at http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff but, as I said, not finished. (Well, it will never be finished. I mean not completely satisfactory as a patch yet.) It removes some of the arbitrary bits - especially the non-linear bits like if RPM N then ... - and makes starting and idling nicer (especially at throttle less than the minimum allowed idle setting - it was fun running it below 500 RPM, on the unstable side of its power curve, after I put the friction always present but before I put the idle adjust constant in there). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Luff wrote: It looks to me like you've got 2 too many curly brackets in doEnginePower, although I could be misunderstanding what you're doing there. Yes, I have got too many. This is the friction that was applied only when starting; I was making it permanent but haven't finished with it. Do you agree that it should be permanently in? Does a constant torque sound about right? That sounds more likely than constant power (which means decreasing torque), to me. Conventional friction would give constant torque; I'm not sure how oil and air viscosity behave, but I'd expect the torque to increase at higher speeds rather than decrease. I don't understand how it could have worked with no resistance implemented. A propeller hardly provides any resistance at low speeds, so I would have thought you would have needed to tweak the developed power down to almost zero at idle. What I am concerned about is the throttle minimum being set to 0.2. ... Ah, thank you for explaining this. I had not understood the mapping onto manifold pressure and the power correlation. It certainly sounds like the power correlation is the thing to un-tweak instead! This puzzled me: the manifold pressure seems to be modelled as (for a given throttle position) independent of speed. When a real engine is running fast and you cut the throttle, the fast air flow will cause a very low manifold pressure which will then rise to its new steady value as the engine slows down. Without this effect, throttle changes will not take effect as quickly as they should and the speed variation with load changes will not be right. Maybe the effect is too small to be important? I might be attempting too much here; I know how car engines work but don't have data to work from (or a lab), and I don't have experience of modelling them either. I will tread carefully and check with you again when I make some more progress. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Code
Jon Berndt wrote: Is there a way to determine which methods/attributes in a class are unused by anybody? I'm thinking maybe there's a utility out there somewhere or a link directive. This would assist in code streamlining/cleanup. Other than grep :-) You can browse through lists of references, looking for empty lists, in a source browser like the ones in MS Visual C++ and Source Navigator (formerly by Red Hat, now a SourceForge project). In MSVC you can only browse, as far as I know, but Source Navigator is open-source and uses Perl or Python scripts to do much of its user interface, so it's probably not hard to get it to output the list of unreferenced symbols. Others IDEs like KDevelop list definitions and declarations but not references. Getting the linker to tell you is an interesting idea that I haven't looked into. Perhaps you could do this manually by listing the public symbols in each library first, and then in the linked application, and comparing the two lists. Or perhaps you can make one list of all the exported symbols from the application and its libraries, and another list of all the imported symbols, and compare those. The unix utilities nm and objdump can list symbols in object files and libraries. I haven't come across a utility specifically for doing this, but I'd be interested. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Megginson wrote: Julian Foad writes: Ah, glad you're there. If you're interested and have time to look, my current attempt is at http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff What's the current status of these? They're only ideas in progress, and are not right. Please don't put them in CVS as they are. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
