Re: [Flightgear-devel] Re: Airport of Hell?
On Samstag 26 November 2005 21:40, Melchior FRANZ wrote: * Mathias Fröhlich -- Saturday 26 November 2005 20:59: On Samstag 26 November 2005 19:47, Joacim Persson wrote: fgfs --airport=EGLL --aircraft=ufo So, since I do not see that problem: Do you have any modifications in your local tree? Doesn't work for me either. This works ... $ fgfs --aircraft=ufo --airport=EGLL --offset-distance=0.0134 and this doesn't: $ fgfs --aircraft=ufo --airport=EGLL --offset-distance=0.0133 only grey soup. And this point seems to be exactly the airport boundary. I'm just not aware of any recent changes that could have this effect. :-| Both work for me. What scenery do you use? Is this the 0.9.9 I am currently downloading? :) ... I still use the 0.9.8 normally. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
Josh Babcock wrote: Good point. I also do this, but because this model has knees (not sure what to call them) instead of oleos, I skipped it. Still, it should be Hinges I believe. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Download/Install App
Arthur Wiebe wrote: But as it seems to be a bad idea, I guess we can forget this thread. Why do you think that? I've not seen any negative responses. It's like everything else, a good idea is always welcome but like you, others might not have time to develop it (right away). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On Thu, 2005-11-24 at 10:06 +0100, Stefan Seifert wrote: I just wanted to note, that when it is clear, that it's a bug in ATI's drivers, someone should post a bugreport in the ATI driver Bugzilla: http://ati.cchtml.com/ This is actually a place where driver developers are watching and a good chance that such bugs get fixed. Before posting, you should read the instructions at: http://www.rage3d.com/board/showthread.php?t=33799828 which is btw. a thread in _the_ most useful forum for Linux using ATI card owners: http://www.rage3d.com/board/forumdisplay.php?f=88 I don't think it's ATI's binary driver fault. I have Ubuntu 5.10 with open-source radeon driver for ATI Radeon 9250 SE. After compiling 0.9.9 and SimGear 0.3.9 the following messages are printed after fgfs startup: [EMAIL PROTECTED] iso]$ /opt/fgfs/bin/fgfs opening file: /opt/fgfs/share/FlightGear/Navaids/carrier_nav.dat /opt/fgfs/share/FlightGear/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 Timo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Alpha problems with 2.5D panel on C310 and aft Center of Gravity
Hi All, I'm currently updating the civilian C310 with an improved 3D cockpit (moving yokes, pedals, flaps, quadrant). I'm hoping to have it finished real-soon-now, but have hit two issues I'd like to resolve before offering it as a patch. For the panel, I've placed used a normal panel with a transparent background in the appropriate place - I guess that counts as a 2.5D cockpit. :) However, there is a small graphical glitch where the edges of most of the round instruments show the terrain through the aircraft. It is only noticable when you're going over runway markings, as the edge turns alternatively gray then white. I guess that the problem is there is an alpha component to the instruments but FG/OpenGL is never seeing the rest of the aircraft. I'd prefer not to put a background on the panel, as it would cause problems where some of the 3D instruments intersected it (the panel is drawn last, so would overlap some of the components). Anyone else seen this and have a solution? Secondly, the C of G for the C310 seems very far back - if you switch off the engines you can easily turn it into a tail-dragger ;) I noticed in the JSBSim file (c310.xml) definitions for pilot, copilot, rear passengers and baggage. It all seems to be in the main cabin (i.e. no baggage in the nose compartment). To lighten the load I'm going to remove the rear pax. Will this automagically bring the CofG forward, or do I need to modify something else? Regards, -Stuart ___ WIN ONE OF THREE YAHOO! VESPAS - Enter now! - http://uk.cars.yahoo.com/features/competitions/vespa.html ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Alpha problems with 2.5D panel on C310 and aftCenter of Gravity
I noticed in the JSBSim file (c310.xml) definitions for pilot, copilot, rear passengers and baggage. It all seems to be in the main cabin (i.e. no baggage in the nose compartment). To lighten the load I'm going to remove the rear pax. Will this automagically bring the CofG forward, or do I need to modify something else? Yes, it will. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Airport of Hell?
On Sun, 27 Nov 2005, Mathias Fröhlich wrote: Both work for me. What scenery do you use? Is this the 0.9.9 I am currently downloading? :) ... I still use the 0.9.8 normally. Don't know about Melchior, but I'm using terrasync -- whichever version it's feeding me with, I simply don't know. Ask Curt. =) (just did a fresh reload of the tile in question too check if terrasync is syncing properly -- same result. Now getting a steaming fresh 0.9.9 tile for comparison.) I didn't even know the 0.9.9 scenery was released already. The links on the download page still points at 0.9.8. If we have the same source code version, and the same scenery version, the difference could lie in how our respective computer memory has been used lately, i.e. smells like a case of unitialised memory use (or prematurely freed mem). ...which a mem debugger ought to catch. (last time I had a go with valgrind and efence on fgfs, I ran out on swap. :P Have added some more swap since then. The good news is that this bug is suitable for hunting down in a batch run with a mem debugger -- doesn't need any user input.)___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] drifting bearings (magvar/hid-offset mismatch)
(tested with c172p, ufo, and other modelss with same result. Airplane standing still on the ground.) Compare the properties: /instrumentation/heading-indicator/offset-deg and /environment/magnetic-variation-deg[0] The former is drifting (decreasing). Is this some reality-feature about airplane heading-indicators I didn't know about? (The only gyro-compasses I'm familiar with are those used for geodetical surveying, and they rather swing back and forth slowly than drift to one side.) I also noted in some model (forgot which) that true heading was calculated from magnetic heading and magvar, rather than grabbing true heading directly from SG. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] drifting bearings (magvar/hid-offset mismatch)
OK forget it. Did my homework now. ;) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] drifting bearings (magvar/hid-offset mismatch)
Joacim Persson wrote: Compare the properties: /instrumentation/heading-indicator/offset-deg and /environment/magnetic-variation-deg[0] The former is drifting (decreasing). The gyro actually _does_ have a drift, on ground as well as in flight. Especially in flight you have to re-adjust it from time to time which requires level and steady flight, because otherwise the magnetic compass doesn't show a valid heading, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
[EMAIL PROTECTED] iso]$ /opt/fgfs/bin/fgfs opening file: /opt/fgfs/share/FlightGear/Navaids/carrier_nav.dat /opt/fgfs/share/FlightGear/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Airport of Hell?
Joacim Persson schrieb: On Sun, 27 Nov 2005, Mathias Fröhlich wrote: Both work for me. What scenery do you use? Is this the 0.9.9 I am currently downloading? :) ... I still use the 0.9.8 normally. Don't know about Melchior, but I'm using terrasync -- whichever version it's feeding me with, I simply don't know. Ask Curt. =) (just did a fresh reload of the tile in question too check if terrasync is syncing properly -- same result. Now getting a steaming fresh 0.9.9 tile for comparison.) I didn't even know the 0.9.9 scenery was released already. The links on the download page still points at 0.9.8. If we have the same source code version, and the same scenery version, the difference could lie in how our respective computer memory has been used lately, i.e. smells like a case of unitialised memory use (or prematurely freed mem). ...which a mem debugger ought to catch. (last time I had a go with valgrind and efence on fgfs, I ran out on swap. :P Have added some more swap since then. The good news is that this bug is suitable for hunting down in a batch run with a mem debugger -- doesn't need any user input.) Hi, I was curious about this problem and did some tests: Only *one* scenery-folder in [FGCVS]\data\.. 3 FG installs FG 0.9.8 windows binary FG 0.9.9 windows binary FG 0.9.x cygwin CVS (only 2 days old) Parameters (set via FGTools V1.3.4), example for FG 0.9.9 windows binary: --fg-scenery=C:\cygwin\fg-cvs\data\scenery --fg-root=H:\FlightGear99\data --enable-fullscreen --bpp=24 --prop:sim/current-gui=1 --airport=EGLL Results: 1. FG 0.9.8 windows binary works without problems 2. FG 0.9.9 windows binary and FG 0.9.x cygwin CVS either freezes in a black hole or crashes This might be an OpenAL problem as I could copy these outputs from a) 0.9.9 binaries b) Cygwin CVS Regards Georg EDDW - a) Windows 0.9.9 binaries latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 18.0925 sea level radius = 1.76081e-264 latitude = 7.60387e-316 longitude= 1.79954e-307 OpenAL error (AL_INVALID_VALUE): set_pitch --- b) Cygwin CVS: OpenAL error (AL_INVALID_VALUE): set_pitch OpenAL error (AL_INVALID_VALUE): set_pitch OpenAL error (AL_INVALID_VALUE): set_pitch Failed to open file OpenAL error (AL_INVALID_VALUE): set_pitch Failed to open file OpenAL error (AL_INVALID_VALUE): set_pitch Failed to open file OpenAL error (AL_INVALID_VALUE): set_pitch Failed to open file OpenAL error (AL_INVALID_VALUE): set_pitch Initializing Nasal Electrical System OpenAL error (AL_INVALID_VALUE): set_pitch OpenAL error (AL_INVALID_VALUE): set_volume altitude = 1.45429e-231 sea level radius = 1.13021e-317 latitude = 9.93823e-315 longitude= 1.13009e-317 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 1.45429e-231 sea level radius = 1.13021e-317 latitude = 9.93823e-315 longitude= 1.13009e-317 OpenAL error (AL_INVALID_VALUE): set_pitch altitude = 1.45429e-231 sea
Re: [Flightgear-devel] Aircraft Download/Install App
Why do you think that? I've not seen any negative responses. It's like everything else, a good idea is always welcome but like you, others might not have time to develop it (right away). Erik Well it may be a good idea, but just not worth the development time for most people. But if anyone ever wants to go at it, let me know. I'd be able to help a little, but just not enough to do everything. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On Sonntag 27 November 2005 13:14, Frederic Bouvier wrote: Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? Well, ist this possible? I was very excited about that idea, but found in the documentation that the error handler needs to call exit otherwise the calling function of the error handler will call exit past return of the error handler ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Airport of Hell?
On Sonntag 27 November 2005 11:55, Joacim Persson wrote: If we have the same source code version, and the same scenery version, the difference could lie in how our respective computer memory has been used lately, i.e. smells like a case of unitialised memory use (or prematurely freed mem). ...which a mem debugger ought to catch. (last time I had a go with valgrind and efence on fgfs, I ran out on swap. :P Have added some more swap since then. The good news is that this bug is suitable for hunting down in a batch run with a mem debugger -- doesn't need any user input.) Hmm, I run valgrind occasionally. Nothing from that so far ... I also have the feeling that memory management might be a problem. Even if that probme smells like something different. That vertical plane exactly at this place where the ufo is placed in my case might cause some problem - just a guess. What compiler do you use? That extendent precision on intels cpu's covers and uncovers some problems unpredictable - depending on some compile flags and compiler implementations ... Do you use some aliasing dependent compiler flags? Hmm ... Still thinking ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Selon Mathias Fröhlich [EMAIL PROTECTED]: On Sonntag 27 November 2005 13:14, Frederic Bouvier wrote: Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? Well, ist this possible? I was very excited about that idea, but found in the documentation that the error handler needs to call exit otherwise the calling function of the error handler will call exit past return of the error handler ... This is true only if the error is a fatal I/O that would trigger the handler installed by XSetIOErrorHandler ( http://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html ). This is not if the error triggers the handler installed by XSetErrorHandler ( http://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetErrorHandler.html ). -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] terrasync source for Scenery-0.9.9
I notice that 0.9.9 scenery is available from several mirrors. Is there an rsync capable site for Scenery-0.9.9? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
On 11/23/05, pmaclean [EMAIL PROTECTED] wrote: Well I got flight gear (version 0.9.8) to compile thanks to the posting by Erik Hofman. http://mail.flightgear.org/pipermail/simgear-cvslogs/2005-January/001011.html I am using Visual Studio dotnet (7.1) on Win2K. The only reason I have had any success building this environment is due to the following article: http://www.geoffmclane.com/fg/fgmsvc7.htm Now I am having an issue running the compiled code as freeglut.dll is not accessible. I'm sure it's a path issue... I am still interested in knowing the format of latitude, longitude and altitude with respect to flightgear's net FDM format. Does anyone know the 64bit description of these fields? Paul __ Is your .com Auracom? Best access rates on the web http://exclusive.auracom.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d hmm... I think I was able to read latitude and longitude properly over net fdm. Let me check and get back to you. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Airport of Hell?
On Sun, 27 Nov 2005, Mathias Fröhlich wrote: What compiler do you use? gcc 3.3.6 That extendent precision on intels cpu's covers and uncovers some problems unpredictable - depending on some compile flags and compiler implementations ... AMD here, if that matters. Do you use some aliasing dependent compiler flags? Er, well I don't know ;)... the flags ./configure set it to. See nothing fancy during a make run I didn't find that tile (w010n50) in the 0.9.9 scenery btw, lestways not on the mirror I got contact with. (Was the one in Poland) It's not ready yet. But I made another interesting discovery today: I can set the alitutde in the properties and -- abrakadabra! -- I'm back from Hell to Heathrow with normal scenery. So the ground cache is indeed filled. It's just that some other part of FG thinks it isn't, and sends the plane to hell instead. (better remember that escape trick for my afterlife. ;)___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
bass pumped wrote: On 11/23/05, pmaclean [EMAIL PROTECTED] wrote: Well I got flight gear (version 0.9.8) to compile thanks to the posting by Erik Hofman. http://mail.flightgear.org/pipermail/simgear-cvslogs/2005-January/001011.html I am using Visual Studio dotnet (7.1) on Win2K. The only reason I have had any success building this environment is due to the following article: http://www.geoffmclane.com/fg/fgmsvc7.htm Now I am having an issue running the compiled code as freeglut.dll is not accessible. I'm sure it's a path issue... I am still interested in knowing the format of latitude, longitude and altitude with respect to flightgear's net FDM format. Does anyone know the 64bit description of these fields? Paul __ Is your .com Auracom? Best access rates on the web http://exclusive.auracom.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d hmm... I think I was able to read latitude and longitude properly over net fdm. Let me check and get back to you. look in net_fdm.hxx for the variable type and units, as in radians and meters ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On Sun, 2005-11-27 at 13:14 +0100, Frederic Bouvier wrote: [EMAIL PROTECTED] iso]$ /opt/fgfs/bin/fgfs opening file: /opt/fgfs/share/FlightGear/Navaids/carrier_nav.dat /opt/fgfs/share/FlightGear/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? How do I install an X11 error handler? This is completely new concept for me. Quick googling didn't help much. Is there a command line option or should I modify FlightGear source or even X11 source? Timo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Selon Timo Saarinen [EMAIL PROTECTED]: On Sun, 2005-11-27 at 13:14 +0100, Frederic Bouvier wrote: [EMAIL PROTECTED] iso]$ /opt/fgfs/bin/fgfs opening file: /opt/fgfs/share/FlightGear/Navaids/carrier_nav.dat /opt/fgfs/share/FlightGear/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? How do I install an X11 error handler? This is completely new concept for me. Quick googling didn't help much. Is there a command line option or should I modify FlightGear source or even X11 source? A X11 error handler is a C/C++ function that is registered through the call of XSetErrorHandler or XSetIOErrorHandler functions. This is a developer task who needs to modify the existing SimGear code to do something that is not the default X11 behavior. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS and PLIB
Is there some kind of problem going on with downloading PLIB from CVS? Seems there's been a partial outage in progress on SF.net for weeks. I can't get plib from CVS, though ... :-( Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and PLIB
Jon Berndt wrote: Is there some kind of problem going on with downloading PLIB from CVS? Seems there's been a partial outage in progress on SF.net for weeks. I can't get plib from CVS, though ... I made a copy of the latest CVS available: ftp://ftp.uni-duisburg.de/FlightGear/Devel/plib-20051127.tar.gz Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS and PLIB
* Jon Berndt -- Sunday 27 November 2005 19:26: Is there some kind of problem going on with downloading PLIB from CVS? Notoriously, but not necessary in this case. :-) Seems there's been a partial outage in progress on SF.net for weeks. I can't get plib from CVS, though ... I have just tried and updating worked, just like yesterday. Check your cvs root: $ cat CVS/Root :pserver:[EMAIL PROTECTED]:/cvsroot/plib Sometimes the funny guys at sf.net change it. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Lockheed1049/Models In directory baron:/tmp/cvs-serv7950/Models Modified Files: Lockheed1049_twa.xml Log Message: Thierry: Sets correctly the VRP at the nose : Yep, the VRP appears actually to be located at the nose, but the offset to the CG is still missing :-) Have a try, look at the aircraft from an outside view (chase view w/o yaw), activate the HUD and see where the center of the HUD points at: It points at the nose whereas it _should_ point at somewhere near the wing root, actually at the CG. Currently the FDM still 'thinks' the CG is at the nose. Don't get me wrong, I don't want to hurt anyone, I just want to remind that the issue hasn't been solved yet. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Lockheed1049/Models
On Sunday 27 November 2005 05:19 pm, Martin Spott wrote: Sets correctly the VRP at the nose : Yep, the VRP appears actually to be located at the nose, but the offset to the CG is still missing :-) Have a try, look at the aircraft from an outside view (chase view w/o yaw), activate the HUD and see where the center of the HUD points at: It points at the nose whereas it _should_ point at somewhere near the wing root, actually at the CG. Currently the FDM still 'thinks' the CG is at the nose. One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
On 11/27/05, John Wojnaroski [EMAIL PROTECTED] wrote: bass pumped wrote: On 11/23/05, pmaclean [EMAIL PROTECTED] wrote: Well I got flight gear (version 0.9.8) to compile thanks to the posting by Erik Hofman. http://mail.flightgear.org/pipermail/simgear-cvslogs/2005-January/001011.html I am using Visual Studio dotnet (7.1) on Win2K. The only reason I have had any success building this environment is due to the following article: http://www.geoffmclane.com/fg/fgmsvc7.htm Now I am having an issue running the compiled code as freeglut.dll is not accessible. I'm sure it's a path issue... I am still interested in knowing the format of latitude, longitude and altitude with respect to flightgear's net FDM format. Does anyone know the 64bit description of these fields? Paul __ Is your .com Auracom? Best access rates on the web http://exclusive.auracom.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d hmm... I think I was able to read latitude and longitude properly over net fdm. Let me check and get back to you. look in net_fdm.hxx for the variable type and units, as in radians and meters ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hi, I had a look at the net_fdm output data. I am seeing fluctations in the data they look quite strange. I am running the model at 120 hz and the data rate is at 10 hz. There seems to be a fluctuation which I cannot account for from the code. I put in a printf statement and got the following for the vcas output speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 I did a prinf for the vcas just befor the htonf function call, and the data it was reading was right. Is there a bug? This is FG 0.9.9. Regards, ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
On 11/27/05, bass pumped [EMAIL PROTECTED] wrote: On 11/27/05, John Wojnaroski [EMAIL PROTECTED] wrote: bass pumped wrote: On 11/23/05, pmaclean [EMAIL PROTECTED] wrote: Well I got flight gear (version 0.9.8) to compile thanks to the posting by Erik Hofman. http://mail.flightgear.org/pipermail/simgear-cvslogs/2005-January/001011.html I am using Visual Studio dotnet (7.1) on Win2K. The only reason I have had any success building this environment is due to the following article: http://www.geoffmclane.com/fg/fgmsvc7.htm Now I am having an issue running the compiled code as freeglut.dll is not accessible. I'm sure it's a path issue... I am still interested in knowing the format of latitude, longitude and altitude with respect to flightgear's net FDM format. Does anyone know the 64bit description of these fields? Paul __ Is your .com Auracom? Best access rates on the web http://exclusive.auracom.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d hmm... I think I was able to read latitude and longitude properly over net fdm. Let me check and get back to you. look in net_fdm.hxx for the variable type and units, as in radians and meters ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hi, I had a look at the net_fdm output data. I am seeing fluctations in the data they look quite strange. I am running the model at 120 hz and the data rate is at 10 hz. There seems to be a fluctuation which I cannot account for from the code. I put in a printf statement and got the following for the vcas output speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 speed=-398976952544137610.00 speed=2.588009 I did a prinf for the vcas just befor the htonf function call, and the data it was reading was right. Is there a bug? This is FG 0.9.9. Regards, oops... disregard the above ouput. I found an error in what I had done. Right now I can only confirm that the data being put on the network is wrong. I have matlab running on another computer reading the output as -398976952544137610.00 insead of 2.58802. I know my matlab code is working... it worked perfectly with 0.9.8. I'll keep everyone updated ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
bass pumped wrote: oops... disregard the above ouput. I found an error in what I had done. Right now I can only confirm that the data being put on the network is wrong. I have matlab running on another computer reading the output as -398976952544137610.00 insead of 2.58802. I know my matlab code is working... it worked perfectly with 0.9.8. I'll keep everyone updated Note that there are FGNetFDM structure changes between v0.9.8 and v0.9.9. I have instances of FG talking to other copies of FG as well as an external FDM talking to FG using the same structure. There can be packing differences between compilers, but we were pretty careful with the current structure (all values are 4 or 8 bytes) and we don't know of any compilers that pack the structure differently from any other compilers. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data/Aircraft/Lockheed1049/Models
One thing that may be confusing is that the VRP setting given by aeromatic is wrong. In the JSBSim configuration file If the CG location is X, Y, Z, then the VRP location is -X, -Y, -Z.I had thought that AC_VRP defines the location of the VRP, however it actually defines the location of the VRP *from* the CG (?). I never noticed it in the T-38 and other smaller airplanes because the effect is hard to see. In a big airplane like the 1049 you can see it. The above may seem authoritative, but I'm really only 90% sure it's correct :) I know you have all been waiting impatiently for another VRP thread. Dave No. The VRP defines the location of an agreed-upon reference point in structural coordinates. The CG, eyepoint, gear locations, etc. are all defined (in JSBSim) in structural frame. By convention, we've agreed that the nose is typically a good reference point, because it is (or should be obvious) to both the 3D model designer and the FDM designer. The CG generally cannot be used, because it moves - sometimes that movement could be profound. Think of it this way: the structural frame is a fixed, solid, coordinate frame that permeates the aircraft structure. The structural frame we use MUST have X positive out the back, and Y out the right wing. The Z axis completes the right-handed system positive upwards. The _origin_ is what is usually found to be confusing. Often, the origin is located by having the X axis be coincident with the fuselage centerline, with X=0 at the tip of the nose - but THAT IS NOT A REQUIREMENT. If the origin is 200 inches in front of the nose, then the VRP could be defined as (200, 0, 0). If the 3D model designer understands that, the aircraft model can be placed with the nose at the location pointed to by JSBSim. The VRP is the registration mark that relates what is reported by JSBSim and what part of the 3D model is placed at what location in the 3D world. Within JSBSim, the equations of motion are all done relative to the CG. However, JSBSim can send to FlightGear the lat/lon/alt of ANY desired point on the aircraft, at any time, in any orientation (it's not hard). We just have to agree on WHICH point is being sent. That's what the VRP is all about. I pray to God that explains it for the last time! :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
On 11/27/05, Curtis L. Olson [EMAIL PROTECTED] wrote: bass pumped wrote: oops... disregard the above ouput. I found an error in what I had done. Right now I can only confirm that the data being put on the network is wrong. I have matlab running on another computer reading the output as -398976952544137610.00 insead of 2.58802. I know my matlab code is working... it worked perfectly with 0.9.8. I'll keep everyone updated Note that there are FGNetFDM structure changes between v0.9.8 and v0.9.9. I have instances of FG talking to other copies of FG as well as an external FDM talking to FG using the same structure. There can be packing differences between compilers, but we were pretty careful with the current structure (all values are 4 or 8 bytes) and we don't know of any compilers that pack the structure differently from any other compilers. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hi Curt, Thank you for your reply. I've got the packet structure all clear. Its just the htonf, htond (and maybe other) function that seems to be doing something strange (as strange as it sounds). I haven't had enough time to completely work on it. I will come back as soon as I have a clearer idea. Thanks, ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
On 11/27/05, bass pumped [EMAIL PROTECTED] wrote: On 11/27/05, Curtis L. Olson [EMAIL PROTECTED] wrote: bass pumped wrote: oops... disregard the above ouput. I found an error in what I had done. Right now I can only confirm that the data being put on the network is wrong. I have matlab running on another computer reading the output as -398976952544137610.00 insead of 2.58802. I know my matlab code is working... it worked perfectly with 0.9.8. I'll keep everyone updated Note that there are FGNetFDM structure changes between v0.9.8 and v0.9.9. I have instances of FG talking to other copies of FG as well as an external FDM talking to FG using the same structure. There can be packing differences between compilers, but we were pretty careful with the current structure (all values are 4 or 8 bytes) and we don't know of any compilers that pack the structure differently from any other compilers. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hi Curt, Thank you for your reply. I've got the packet structure all clear. Its just the htonf, htond (and maybe other) function that seems to be doing something strange (as strange as it sounds). I haven't had enough time to completely work on it. I will come back as soon as I have a clearer idea. Thanks, uhhh and please don't anyone flame me for saying a standard c function is doing something wrong... I'm probably wrong and need verify it properly. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 0.9.9 Build problems
In file included from /usr/local/FG-0.9.9/include/plib/ul.h:41, from /usr/local/FG-0.9.9/include/plib/sg.h:29, from /usr/local/FG-0.9.9/include/plib/fnt.h:29, from /usr/local/FG-0.9.9/include/plib/pu.h:28, from fg_os.cxx:14: /usr/include/stdlib.h:612: error: declaration of `void exit(int) throw ()' throws different exceptions /usr/X11R6/include/GL/glut.h:163: error: than previous declaration `void exit(int)' make[2]: *** [fg_os.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear-0.9.9/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.9/src' make: *** [all-recursive] Error 1 Using gcc-3.3.5, automake-1.8.5 on a Debian system Just finished upgrade to 3.3.5, did I forget something regards the libraries? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
