Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
Gerard Robin wrote: It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. Well, If you want Atlas to work with the kates data you will need to fix it, don't you? I've fixed several other programs which I find useful, and so can you. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
Jon Berndt wrote: IIRC, sprintf was a problem for some. Is that still the case? I've compiled under Cygwin, Borland C++, and I think I've also compiled code that uses sprintf under IRIX. The real problem was snprintf(...) which isn't availble under Winodws: #if defined(_WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Jon Berndt wrote: IIRC, sprintf was a problem for some. Is that still the case? I've compiled under Cygwin, Borland C++, and I think I've also compiled code that uses sprintf under IRIX. sprintf is C standard - and very unsafe due to possible buffer overflows. It shouldn't be used. The inofficial (i.e. there's no standard yet AFAIK) C solution is snprintf: The real problem was snprintf(...) which isn't availble under Winodws: #if defined(_WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif The real cross platform soultion would be the C++ std::string CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC5fY9lhWtxOxWNFcRAn5KAJ4/ymkStSRQcOrUbIUpqdRy6D11rACgsHYs iveF3b6qmM5Yz393cHfX5gs= =q0Yi -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
Christian Mayer wrote: The real cross platform soultion would be the C++ std::string No, you can't format (the f in printf) the string using the default C++ string class). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman schrieb: Christian Mayer wrote: The real cross platform soultion would be the C++ std::string No, you can't format (the f in printf) the string using the default C++ string class). You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.) like std::setprecision(). Compared to the fast printf syntax they are too annoying to write and not that flexible, but they are more readable and they can be combined to your own user defined I/O manipulators. So you can write easily very readable code without the need to retype everything. CU, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC5gE/lhWtxOxWNFcRAguhAKCmz+gYRTu9b+vBoJuLNDm6VJs+rQCfSznC v0iykSBU97YqOiobZru7qFE= =eMKQ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 17:13, Andy Ross wrote: Steve Hosgood wrote: Solving where the planet is in its orbit for any given calendar time is tricky. This is just the equal area thing, right? Yes. If nothing else, we can certainly solve it by brute-force integrating it for +/- a few hundred years and storing the table. :-) It's not *that* tricky! Tricky for pre-computer-era people to solve with log tables and slide-rules maybe, but it's just an iterative algorithm where you plug a suggested value of 'x' into a formula and it gives you a better approximation. Repeat until the new approximate 'x' is within an allowable tolerance of the original. Trivial on any modern computer. The hard part is finding the calendar time given a phenomenum (like, say 'sunset'). I outlined that one in my previous post. Right, but the point was we don't give a hoot about sunset. That's a derived quantity specified in euler space... Yeah, quite right. I think the discussion just went off a bit sideways there. So we're just down to the problem that the sun position code is possibly not GPL-able. I've dug out my own code that I'm quite happy to donate. Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk Johnson's 'xearth' anyway, and even he attributes it all to the legendary Practical Astronomy with your Pocket Calculator book by Peter Duffett-Smith. I think the interface routines to FlightGear (all starting with 'fg') are not Johnson's anyway, but I'm not totally sure. Durk Talsma may know better - his name is on some of the comments in those 'fg' routines. If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. Can someone confirm that doing this will fix the issue, or is there more? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. We got routines for thee julian date and GST dated already in SimGear/simgear/timing/sg_time.[ch]xx Can someone confirm that doing this will fix the issue, or is there more? To prevent any problems in the future I would like to see that file removed and the functions added to tmp.[ch]xx But what is really needed is a way to get sun_angle() working in sunsolver.cxx which is done by replacing fgSunPositionGST() with a new version (or by writing a new function that can calculate the sun_angle any time of day at any location) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tue, 2005-07-26 at 10:37, Erik Hofman wrote: To prevent any problems in the future I would like to see that file removed and the functions added to tmp.[ch]xx Remove sunpos.[ch]xx completely? OK. But what is really needed is a way to get sun_angle() working in sunsolver.cxx which is done by replacing fgSunPositionGST() with a new version (or by writing a new function that can calculate the sun_angle any time of day at any location) Funnily enough, I was just having a cup of tea and reading that very file just as your email came in (you're in Europe I presume?). fgSunPositionGST seems to be derived from Johnson's 'xearth' code, but it calculates where on earth the sun is directly overhead. That makes sense for 'xearth' where one of the options is to display the planet from the sun's point of view (so to speak). I can't work out what that routine is doing in FlightGear! It's only used in 'sunsolver.cxx' which was written by Curtis anyway, and is GPL of course. But why is called at all? The rest of Curtis's code does what I'd expect - which is to find the time of day when the sun is at a given angle (so you can specify flying at dusk, or noon or whatever). Give me a bit longer to disentangle it all! I can't work on it right now, (I'm at work) but I can take a quick look at lunchtime, and do more this evening. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] sprintf
No, you can't format (the f in printf) the string using the default C++ string class). You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.) like std::setprecision(). The string class cannot create a string representation of a floating point number as far as I can tell. The next best thing (IMHO) is sprintf(). I wish we could do this: string myString= double myValue=3.1415; myString = The value of pi is: + string(myValue) + \n; I've had enough trouble with stringstreams that I don't want to go that path. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Debian Installation
Hi, I have been trying to install the FGFS on my PC but I am having problem to configure the DEBIAN packages on the proper order before I start the FGFS packages installation. Is there a quick setup that I could use? I am doing the installation thru network, I downloaded the newest Minimal Debian CD and there are not many options. I use a Nvidia board and it was recognized by the LINUX. Regards, FS - This mail sent through IMP: http://horde.org/imp/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
Le mardi 26 juillet 2005 à 09:46 +0200, Erik Hofman a écrit : Gerard Robin wrote: It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. Well, If you want Atlas to work with the kates data you will need to fix it, don't you? I've fixed several other programs which I find useful, and so can you. Erik Probably NO, i don't usually practise C language. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le lundi 25 juillet 2005 à 23:55 +0200, Gerard Robin a écrit : Le lundi 25 juillet 2005 à 23:02 +0200, Roy Vegard Ovesen a écrit : AFAICT there hasn't been any significant changes to Instrumentation/gps..*xx or Airports/simple.*xx. There has been alot of improvements to the gui system lately, so maybe my dialog has become broken. Could you try to trigger the Get Nearest Airport from the property browser? Go to /instrumentation/gps/wp/wp[1] and set get-nearest-airport to true. I'm not able to run FG right now because of some freeglut issue (I believe) so I can't test this myself :-( sorry It has not any effect. We get nothing :=( Looking at the guy dialog it is the old usual nasal command. it should work. I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
Christian Mayer wrote: You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.) like std::setprecision(). Compared to the fast printf syntax they are too annoying to write and not that flexible, but they are more readable and they can be combined to your own user defined I/O manipulators. So you can write easily very readable code without the need to retype everything. Just to add fuel to the fire, I will point out that this is a theoretical result. I've never once seen a complex iostream usage that I considered readable. Formatting text is a solved problem; programmers know what they want, and they want printf. C++ tried to get fancy, and failed. Much of the same can be said for the STL; 90% of developers are never going to care about pluggable algorithms, but 100% of them want a simple hash table. Guess which they got? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport an WP : Not Working
Le mardi 26 juillet 2005 à 15:16 +0200, Gerard Robin a écrit : Le lundi 25 juillet 2005 à 23:55 +0200, Gerard Robin a écrit : Le lundi 25 juillet 2005 à 23:02 +0200, Roy Vegard Ovesen a écrit : AFAICT there hasn't been any significant changes to Instrumentation/gps..*xx or Airports/simple.*xx. There has been alot of improvements to the gui system lately, so maybe my dialog has become broken. Could you try to trigger the Get Nearest Airport from the property browser? Go to /instrumentation/gps/wp/wp[1] and set get-nearest-airport to true.. I'm not able to run FG right now because of some freeglut issue (I believe) so I can't test this myself :-( sorry It has not any effect. We get nothing :=( Looking at the guy dialog it is the old usual nasal command. it should work. I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) The situation is really bad. None of the Menu-Instruments-GPS-WayPoints functions are working -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
On Tuesday 26 July 2005 00:02, Gerard Robin wrote: Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit : Markus Morawitz wrote: Please can anyone help me by teaching me some history about the Airport and NavAids file formats. Where is the current file format being described? FlightGear started out by using a native file format for airport data but recently switched to the file format also used by X-Plane. Everything (including the file format) can be found here: http://x-plane.org/home/robinp/ Erik It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. I seem to remember that the CVS version of Atlas is compatible with the new airport format. Try that! -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
Le mardi 26 juillet 2005 à 16:40 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 00:02, Gerard Robin wrote: Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit : Markus Morawitz wrote: Please can anyone help me by teaching me some history about the Airport and NavAids file formats. Where is the current file format being described? FlightGear started out by using a native file format for airport data but recently switched to the file format also used by X-Plane. Everything (including the file format) can be found here: http://x-plane.org/home/robinp/ Erik It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. I seem to remember that the CVS version of Atlas is compatible with the new airport format. Try that! Thanks You are right it is working. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le mardi 26 juillet 2005 à 17:04 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 15:16, Gerard Robin wrote: I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). ??? Do you keep every July CVS release for the past couple of years? Have none of your CVS updates this July worked for you? Ouaf Ouaf I am not enough crazy to keep only every old times July from every years := BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) That could be the cause. If you again use the property browser to look at /instrumentation/gps/***. Here you should see longitude and latitude values changing as you move. If not then the gps might not be getting power. We get nothing but Zero in /instrumentation/gps/*** Who is able to tell what must be done to solve it ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le mardi 26 juillet 2005 à 18:05 +0200, Gerard Robin a écrit : Le mardi 26 juillet 2005 à 17:04 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 15:16, Gerard Robin wrote: I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). ??? Do you keep every July CVS release for the past couple of years? Have none of your CVS updates this July worked for you? Ouaf Ouaf I am not enough crazy to keep only every old times July from every years := BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) That could be the cause. If you again use the property browser to look at /instrumentation/gps/***. Here you should see longitude and latitude values changing as you move. If not then the gps might not be getting power. We get nothing but Zero in /instrumentation/gps/*** Who is able to tell what must be done to solve it ? Hi Roy I have got the answer the electrical nasal file must include the short term patch 28 = 60 ideal volts with rpm_source : /engines/engine [0]/rpm you suggested it before about turn indicator -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
From: Roy Vegard Ovesen On Tuesday 26 July 2005 00:02, Gerard Robin wrote: Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit : Markus Morawitz wrote: Please can anyone help me by teaching me some history about the Airport and NavAids file formats. Where is the current file format being described? FlightGear started out by using a native file format for airport data but recently switched to the file format also used by X-Plane. Everything (including the file format) can be found here: http://x-plane.org/home/robinp/ Erik It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. I seem to remember that the CVS version of Atlas is compatible with the new airport format. Try that! That is true. The cvs log from last Dec 23: Support the X-Plane airport data format by default since this is what FlightGear now uses from v0.9.8 onwards Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: Funnily enough, I was just having a cup of tea and reading that very file just as your email came in (you're in Europe I presume?). Yep. fgSunPositionGST seems to be derived from Johnson's 'xearth' code, but it calculates where on earth the sun is directly overhead. That makes sense for 'xearth' where one of the options is to display the planet from the sun's point of view (so to speak). I can't work out what that routine is doing in FlightGear! It's only used in 'sunsolver.cxx' which was written by Curtis anyway, and is GPL of course. But why is called at all? The rest of Curtis's code does what I'd expect - which is to find the time of day when the sun is at a given angle (so you can specify flying at dusk, or noon or whatever). Yes, and that's all it does, give an angle to display the pretty colors properly. Give me a bit longer to disentangle it all! I can't work on it right now, (I'm at work) but I can take a quick look at lunchtime, and do more this evening. I can imagine, I had trouble finding out what's going on also :-\ Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
On Tuesday 26 July 2005 18:25, Gerard Robin wrote: Hi Roy I have got the answer the electrical nasal file must include the short term patch 28 = 60 ideal volts with rpm_source : /engines/engine [0]/rpm In theory this hould not make any dfference because the gps is not as demanding as the turn indicator. The gps should work with any electrical input larger than 0. So it should work just as well on 28 as on 60. But hey, if you say it's working now, then who am I to dispute that? ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le mardi 26 juillet 2005 à 18:45 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 18:25, Gerard Robin wrote: Hi Roy I have got the answer the electrical nasal file must include the short term patch 28 = 60 ideal volts with rpm_source : /engines/engine [0]/rpm In theory this hould not make any dfference because the gps is not as demanding as the turn indicator. The gps should work with any electrical input larger than 0. So it should work just as well on 28 as on 60. But hey, if you say it's working now, then who am I to dispute that? ;-) You should be right. On my side i don't understand as well. The fact is 28 - not working 60 - working. When your FG will be on, you will probably give a good explaination. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
... This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? I've got a hunch. Dave Culp may have an idea. I'll take a look, too. Sorry. I haven't been following the FG CVS logs. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
In theory this hould not make any dfference because the gps is not as demanding as the turn indicator. The gps should work with any electrical input larger than 0. So it should work just as well on 28 as on 60. But hey, if you say it's working now, then who am I to dispute that? ;-) You should be right. On my side i don't understand as well. The fact is 28 - not working 60 - working. When your FG will be on, you will probably give a good explaination. If we look at /systems/electrical/outputs/ we get gps to null when volt=28 we get gps to 60 when volt=60 in gps.cxx we find Line 102 _electrical_node = fgGetNode(/systems/electrical/outputs/gps, true); I am far be expert, it seems that gps needs a good electrical value, is it right ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
On Tuesday 26 July 2005 19:20, Gerard Robin wrote: If we look at /systems/electrical/outputs/ we get gps to null when volt=28 we get gps to 60 when volt=60 in gps.cxx we find Line 102 _electrical_node = fgGetNode(/systems/electrical/outputs/gps, true); That's the initialization of the property. This is where it gets created. I am far be expert, it seems that gps needs a good electrical value, is it right ? That's right. At line 215 that property needs to be true (that is not zero/null) for the gps to update. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tuesday 26 July 2005 11:30, Steve Hosgood wrote: So we're just down to the problem that the sun position code is possibly not GPL-able. I've dug out my own code that I'm quite happy to donate. Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk Johnson's 'xearth' anyway, and even he attributes it all to the legendary Practical Astronomy with your Pocket Calculator book by Peter Duffett-Smith. I think the interface routines to FlightGear (all starting with 'fg') are not Johnson's anyway, but I'm not totally sure. Durk Talsma may know better - his name is on some of the comments in those 'fg' routines. Just looking through the sunpos.cxx file, I'm actually wondering how much code is part of the original Kirk Johnson code and how much was changed to adapt the code to our needs. I really think I would have to look at the original file to find out. As far as I remember though, the functions starting with the fg prefix were adaptations from the original Johnson code, but specifically adapted to our needs. Erik, having a look at your patch is next on my list. I'll how much I can find out. Cheers, Durk If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. Can someone confirm that doing this will fix the issue, or is there more? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Dave Perry wrote: This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? Regards, Dave Perry I have started to investigate that problem but not found anything atm. I can reproduce the bug in the same situation as you. FG is *not* freezed. All (?) is working correctly except the screen is not refreshed for some strange reason. The main loop is executed, the render code is executed, you can do a clean exit with escape + enter. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
On Sunday 24 Jul 2005 17:30, Erik Hofman wrote: Lee Elliott wrote: p.s. Erik: someone on the user list wants to stop the YASim legacy engine definition message from your pa28. I can have a look at it if you want but I know it's really your baby:) Eh, no, It's David Meggison's model. I have not yet created an airplane with a YASim FDM. Erik Oops - pardon me. Hmm... the last posting from Mr M that I have was way back in January when he said he was taking a break from FG for a while. As he also said he wanted to devote some time to the Warrior (and J3) I guess he'll sort it out at some point. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Debian Installation
On Tuesday 26 Jul 2005 12:43, [EMAIL PROTECTED] wrote: Hi, I have been trying to install the FGFS on my PC but I am having problem to configure the DEBIAN packages on the proper order before I start the FGFS packages installation. Is there a quick setup that I could use? I am doing the installation thru network, I downloaded the newest Minimal Debian CD and there are not many options. I use a Nvidia board and it was recognized by the LINUX. Regards, FS Are you trying to install the debian packages for PLib, Simgear FlightGear or do you want to use the cvs versions? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Hi, sorry for the late reaction. Turns out to be a bad interaction between jsbsims crash detection and my past initialization changes. The attached patch fixes this by moving crash detection out of the initialization phase of jsbsim. Erik, Can you apply that please to flightgears cvs. I will care for JSBsim's cvs. Thanks and sorry Mathias On Dienstag 26 Juli 2005 03:38, Dave Perry wrote: I have posted this issue twice before. This is with plib, SimGear, fg, and data all from recent cvs. I have fgfs from cvs up-to-date on my desktop and notebook, both running Linux FC3 and both have this bug after updates from about 10 days ago. I don't know if there are others that use fgfs from front range locations in Colorado, but I use it to practice instrument approaches in this my home area and my two favorite aircraft for this are the c172p and c310, both jsbsim models. _The yasim aircraft still work fine with this scenery._ By the way, I downloaded both w110n30.tgz and w110n40.tgz and reinstalled both with no change to this bug. I have not seen this issue with airports not from these scenery files. I used --log-level=info to try and figure out what the issue is and here is the beginning and end of that log. [EMAIL PROTECTED] data]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --log-level=info --airport=2V2 --aircraft=c172 Finished command line arguments Initializing splash screen GeForce FX 5600 Ultra/AGP/SSE/3DNOW! Max texture size = 4096 Depth buffer bits = 24 Loading Airport Database ... Data file version = 715 [FINISHED LOADING] Loading Navaid Databases Standardising rwy number from B to 0B Fixes Attempting to set starting position for 2V2:28R Failed to find runway 28R at airport 2V2 Attempting to set starting position from airport code 2V2 heading 270 runway = -105.164, 40.1644 length = 1459.99 heading = 122.75 Position for 2V2 is (-105.156, 40.1609) new heading is 302.75 Searching for airport code = 2V2 Position for 2V2 is (-105.164, 40.1638) Initializing Time Current greenwich mean time = Tue Jul 26 01:12:53 2005 Current local time = Mon Jul 25 19:12:53 2005 Reading timezone info from: /usr/local/FlightGear/Timezone/zone.tab Using zonename = /usr/local/FlightGear/Timezone/America/Denver First time, doing precise gst General Initialization === == ... Ltoken = OBJECT_BASE name = 1237121.btg token = OBJECT name = CO82.btg token = OBJECT name = 7CO3.btg token = OBJECT name = K18V.btg token = OBJECT name = K18V.btg token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.604, 40.1208 elevation = 1459 heading = 0 token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.742, 40.0566 elevation = 1488 heading = 0 token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.747, 40.0555 elevation = 1497.8 heading = 0 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Ltoken = OBJECT_BASE name = 1237129.btg token = OBJECT name = 03CO.btg token = OBJECT name = 03CO.btg prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Loading tile /usr/local/Scenery-0.9.8/w110n40/w105n40/1237137 token = OBJECT_BASE name = 1237137.btg token = OBJECT name = K11V.btg token = OBJECT name = K11V.btg token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.706, 40.2614 elevation = 1407.8 heading = 0 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Loading tile /usr/local/Scenery-0.9.8/w110n40/w105n40/1237145 token = OBJECT_BASE name = 1237145.btg token = OBJECT name = KGXY.btg token = OBJECT_SHARED name = Models/Airport/beacon.xml pos = -104.636, 40.4291 elevation = 1418 heading = 0 token = OBJECT name = CO70.btg token = OBJECT name = CO70.btg token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.724, 40.4375 elevation = 1328 heading = 0 token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.724, 40.4378 elevation = 1328.3 heading = 0 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Loading tile /usr/local/Scenery-0.9.8/w110n40/w105n40/1237153 token = OBJECT_BASE name = 1237153.btg token = OBJECT name = CO48.btg token = OBJECT name = CO48.btg prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
Erik,
Can you apply that please to flightgears cvs.
I will care for JSBsim's cvs.
Thanks and sorry
Mathias
Or only comment, in order to come back to the good old process.
// crashed (altitude AGL 0)
//if (get_Altitude_AGL() 0.0) {
// crash_message = Attempted to fly under ground.;
// crash_handler();
// }
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
