Re: [Flightgear-devel] Further FGRunway work
* James Turner -- 8/20/2008 1:44 PM: But, doing this, I wondered - there's these displaced threshold and stopway values in Robin's data, which we are parsing, storing in memory, and which are never used by any C++ code - they do get passed to Nasal, but I'd bet some money no one on that sides uses them either. I just made all internal runway data available in the Nasal query function, without considering any possible use case. So far I only used those elements that I needed for finding the touchdown point ($FG_ROOT/Nasal/glide_slope_tunnel.nas). Generally, the more information is available, the better. One never knows what clever stuff people come up with, given even obscure data. But then again, we certainly don't need any of the runway details from an airport that's thousands of kilometers away. I'd be fine with having some pieces of information in a file that's automatically(?) loaded with the tile, and can additionally get loaded via Nasal IO on demand, even for very distant airports. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further FGRunway work
On 25 Aug 2008, at 07:31, Melchior FRANZ wrote: I just made all internal runway data available in the Nasal query function, without considering any possible use case. So far I only used those elements that I needed for finding the touchdown point ($FG_ROOT/Nasal/glide_slope_tunnel.nas). Generally, the more information is available, the better. One never knows what clever stuff people come up with, given even obscure data. Ah, thanks for the pointer to the nasal file, and the explanation of the code. Absolutely agreed that making as much data as possible available is valuable - as you say, I'm always amazed by the neat things people do in nasal scripts. But then again, we certainly don't need any of the runway details from an airport that's thousands of kilometers away. I'd be fine with having some pieces of information in a file that's automatically(?) loaded with the tile, and can additionally get loaded via Nasal IO on demand, even for very distant airports. Yep, I'm still thinking on different ways to make the core datasets a bit more 'lazy'. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On 25 Aug 2008, at 03:25, Curtis Olson wrote: Hi James, I think this was all done intentionally because it's quite common to want to start a flight simulator on a 5 or 7 or 10 mile approach so you can practice ILS landing. The start-offset-m value I believe was added later to account for the difference in aircraft size. A starting position that works well to place the C172 at the end of the runway, might put the back half of the 747 off the end of the runway. Understood on both counts, but that means I think there is a bug in the glideslope code: On Sun, Aug 24, 2008 at 3:53 PM, James Turner wrote: Anyway, what makes me wonder if there's a bug here is the glideslope logic. In the case where a glideslope angle is specified, and also a preset altitude, we encounter the code at line 976 of fg_init.cxx. Now, the crucial observation is that this code does multiply the final distance by -1. As a result, the calculated offset-distance-nm would place the start position well down the runway - possibly some way beyond it, in fact. Hence my feeling that something isn't quite right - I understand why the 'polarity' of start-offset-m and offset-distance-nm are they way there are, but then it does seem as if the glideslope calculation will place the point in a silly place. From testing with the code, that does indeed seem to be the case. The fix would be as trivial as removing the '-1' term from that line, of course. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Carrier with Aircraft, and the last JSBSim version
Hello, ... In order to get these data into the JSB FDM, the crude solution could be, to include the yasim calculation part into JSBSim. I feel that won't be the more elegant solution, and i am not sure that Jon would agree on it. :) Though, i am not aware, about the FG source organisation, i dare that question: Won't it be possible to calculate and to give on request ( when we are close to a Carrier ) these data. I mean, the cats and wires positions ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ As posted by Dave in the JSBSim mailing list, I firmly agree: determining carrier location and orientation should not be an FDM specific function. This needs to be more configurable from the FlightGear side, so any FDM can take that information and do with it what it needs to do cat/hook ops. Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Another OpenSource FlightSim based on OSG
Hi, Just a quick note: Today I found another OpenSource FlightSim which uses OSG. It is under GPL-licence, and has as features like: Carrier landing mission. Motion blur (-motion-blur). Sky dome. Sound effects (PLIB) Particle-system (improved explosions). Collision-detection. Can download satellite imagery and render spherical Earth using OSSIM. It uses our aircrafts, and looks quite nice. Maybe the source codes there are interesting for further developing of FlightGear? Look at: http://www.palomino3d.org/ Cheers HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On 08/24/2008 01:53 PM, James Turner wrote: Doing this, I came across something which seems counter-intuitive to me: I agree, it's counterintuitive, to say the least. default azimuth to offset by is the *reciprocal* runway heading. This means to start 10nm 'out' from the threshold, one can use a positive value of 10 - I expected this to require a negative value. Good catch. I agree, there are many good reasons why a negative value would be appropriate here. I wonder if this is intentional, since it's the more common case that starting 'ahead' of the threshold, but equally it might be a bug - the azimuth is inverted to move from the runway centre 'back' to the threshold. Long-ago discussions indicate that it is intentional. But it is still a Bad Idea. The problem is, starting ahead of the threshold is only one use-case among many. It is not even remotely the most common case chez moi. It is a Bad Idea to simplify this one case at the cost of logic and consistency among the many other cases, such as positioning relative to enroute waypoints. On a tangentially related note, it appears that James Turner is wise enough to live by the dictum, principles and concepts first; terminology second. I mention this because previous discussions of this topic quickly degenerated into pedantic emphasis on the definition of distance (which is necessarily positive) to the exclusion of more usable concepts such as location-vectors and position-vectors along the number line. For years, the _Sport Model_ has represented offsets in the logical way, such that negative offsets are on the upstream side of the reference point, while positive offsets are on the downstream. side. Anyway, what makes me wonder if there's a bug here is the glideslope logic. In the case where a glideslope angle is specified, and also a preset altitude, we encounter the code at line 976 of fg_init.cxx. Now, the crucial observation is that this code does multiply the final distance by -1. As a result, the calculated offset-distance-nm would place the start position well down the runway - possibly some way beyond it, in fact. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On Mon, Aug 25, 2008 at 3:12 AM, James Turner wrote: On 25 Aug 2008, at 03:25, Curtis Olson wrote: Hi James, I think this was all done intentionally because it's quite common to want to start a flight simulator on a 5 or 7 or 10 mile approach so you can practice ILS landing. The start-offset-m value I believe was added later to account for the difference in aircraft size. A starting position that works well to place the C172 at the end of the runway, might put the back half of the 747 off the end of the runway. Understood on both counts, but that means I think there is a bug in the glideslope code: Can you further explain what the bug involves? In my experience, placing the aircraft on the glide slope several miles out and flying the glide slope all works fine, or am I missing something here? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Jsbsim-devel] AI Carrier with Aircraft, and the last JSBSim version
On lun 25 août 2008, Jon S. Berndt wrote: Hi Gerard, I think the ultimate solution would be for FlightGear to move this code out of the FDM's and into the FDM interface class. Dave I firmly agree: determining carrier location and orientation should not be an FDM specific function. This needs to be more configurable from the FlightGear side, so any FDM can take that information and do with it what it needs to to do cat/hook ops. Jon YES, the problem won't be technical, but mainly a policy problem. Since that feature is included into YASim , I fear the answer (again, i got it..), for model which want carrier features, YASim answer the request :). I hope that the prize to do it, will not be too high. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
On 08/25/2008 02:45 PM, Curtis Olson wrote: Can you further explain what the bug involves? In my experience, placing the aircraft on the glide slope several miles out and flying the glide slope all works fine, or am I missing something here? In my experience, the glideslope initialization feature has never worked. Not even once. I've tried it maybe 50 times on 10 occasions over the past two years. I tried it again just now. Details vary: *) If I specify distance and slope, a negative absolute altitude is one of the common results, *) If I specify altitude and slope, a wildly incorrect position is one of the common results. *) If I try it more than once, without exiting and restarting fgfs, NaN position with NaN altitude is one of the common results. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup position offsets (fg_init)
Hmmm, ok I suppose that is possible. I have done this with an external FAA certified flight dynamics model, but I am letting the flightgear code compute the final longitude and latitude and altitude and just passing that over. This has worked as recently as 2 weeks ago. I don't know that I've tried this with any internal FDM's recently though. Can you give me an example that fails? This initial position code is a bit complicated since it perhaps tries too hard to decide what you *want* based on limited or missing inputs, but as far as I know it does work correctly. Regards, Curt. On Mon, Aug 25, 2008 at 5:33 PM, John Denker [EMAIL PROTECTED] wrote: On 08/25/2008 02:45 PM, Curtis Olson wrote: Can you further explain what the bug involves? In my experience, placing the aircraft on the glide slope several miles out and flying the glide slope all works fine, or am I missing something here? In my experience, the glideslope initialization feature has never worked. Not even once. I've tried it maybe 50 times on 10 occasions over the past two years. I tried it again just now. Details vary: *) If I specify distance and slope, a negative absolute altitude is one of the common results, *) If I specify altitude and slope, a wildly incorrect position is one of the common results. *) If I try it more than once, without exiting and restarting fgfs, NaN position with NaN altitude is one of the common results. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] UNC, Argentina:JSBsim Compilation
Hello, My name is Gonzalo Rubio, i`m a studing Aeronautics Engineering at the National University of Cordoba (UNC) in Argentina. We are developing a project in wich we will use Flight Gear with JSBsim as the equations solver for simulating an airplane that was developed and design on the university, at the same time another team is building the plane in scale, with a wing span of 7 m. The objetive of the project is to fly both the real plane and the simulator at the same time and together with and adquisition data system compare both reality and virtual performance. I`m in charge of investigating diferent Numerical Methods for solving the equations. The reason i`m writing is because i dont have experience in C++ code compilation, i`ve downloaded the source code, but still have problems to achieve a correct compilation. Could anyone please explain me how you are doing to do this and guide me trough the process? so i can focus on the numerical methods and being able to check the results¿? Thank you very much. Have a great day Gonzalo _ Ingresá ya a MSN Deportes y enterate de las últimas novedades del mundo deportivo. http://msn.foxsports.com/fslasc/- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
