Re: [Flightgear-devel] segfault at LFPG
On Sun, Aug 24, 2008 at 04:38:36AM +0200, Csaba Halász wrote: At least 3 of us get immediate segfault most of the time if starting at LFPG. I got various backtraces, mostly from OSG. Me too , i have many segfaults . My context : - Phenom 9750 Quad-Core / GeForce 8800 GT - linux 2.6.25 ( x86_64 ) - OpenSceneGraph-2.6.0 - plib-svn - SimGear-cvs - Flightgear-cvs Some times I can not play , because i segfault always . -- Erwan MAS - 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] Changes in sound positioning and orientation
Erik Hofman wrote: Erik Hofman wrote: +X = down, -X = up Shoot, this should be: -X = down, +X = up This is getting embarrassing .. forget about it, it was described properly (just like in the README file). It's getting worse, there were local changes in my SimGear tree that caused this :-( I've updated the README files once again. I' m really sorry for the confusion. Erik - 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] B-1B update
Hi all! Would someone please be so kind and apply the snapshot below? Thanks in advance. http://homepage.univie.ac.at/markus.zojer/fgfs/B-1B.tar.gz In folder B-1B/Models please delete the following files: bone.rgb cp.rgb Updates are: - Cockpit/WSO cabin improvements (pilots and seats captured from f-14;)) - Cockpit access ladder - Fire warning/extinguish system - Rear landing gear doors / gear with animation - Forward and Intermediate and Aft Weapon Bay - Refuel system serviceable - Engine start sequence available - OSO panel and display - Functional weapon system (only unguided GBU31 at the moment) - Impact model relies on the vulcan-b2 installed - Tank locations updated - NUC panel in cockpit now shows time/nm to waypoint Thanks, Markus - 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] B-1B update
Hi Markus, Markus Zojer wrote: http://homepage.univie.ac.at/markus.zojer/fgfs/B-1B.tar.gz Nice - but two texture files are missing :-) The 'Models/pilot_b1b.ac' requires 'white-black-gradient-stripes.rgb' and 'Models/seat.ac' requires 'grey-blue-flood.rgb' - would you add these two files ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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] AI Carrier with Aircraft, and the last JSBSim version
Hello, There is, into the recent FDM JSBSim update, a new huge feature with is the External_Forces, this gives us, a lot of new facilities for model development, like mooring rope, chutes, catapults, hook, mules and so on. Each external_force can be defined BODY or LOCAL. Working on an Aircraft (Crusader) with Carrier (Foch) I am looking for the right solution to get the positions of the Carrier with its components catapults and wires. Into FG source, we can find some code which gives, regarding the AI, the positions., global x-y-z, and lat lon. I have found it for Carrier and Tankers (very useful for refuel), and probably there for any AI models. However there is nothing regarding the Carriers components, catapults and wires positions. Into YASim the positions of each component, catapults and wires positions are calculated. 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 ? I guess, if we had these values it should possible to process them into JSBsim in order to get an achieved Carrier Landing/takeOFF simulation. At least , easier for Jon to include that simulation into JSBSim. I can be wrong, it could be many other better approach 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] B-1B update
Ah sorry, forgot them when copying the files over from the f-14. Now they are included within the downloadable file or get them at: Aircraft/F-14/f-14b/Models/Cockpit Thanks for your work, Markus Martin Spott wrote: Hi Markus, Markus Zojer wrote: http://homepage.univie.ac.at/markus.zojer/fgfs/B-1B.tar.gz Nice - but two texture files are missing :-) The 'Models/pilot_b1b.ac' requires 'white-black-gradient-stripes.rgb' and 'Models/seat.ac' requires 'grey-blue-flood.rgb' - would you add these two files ? Cheers, Martin. - 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] [Jsbsim-devel] AI Carrier with Aircraft, and the last JSBSim version
Hello, There is, into the recent FDM JSBSim update, a new huge feature with is the External_Forces, this gives us, a lot of new facilities for model development, like mooring rope, chutes, catapults, hook, mules and so on. Each external_force can be defined BODY or LOCAL. Working on an Aircraft (Crusader) with Carrier (Foch) I am looking for the right solution to get the positions of the Carrier with its components catapults and wires. Into FG source, we can find some code which gives, regarding the AI, the positions., global x-y-z, and lat lon. I have found it for Carrier and Tankers (very useful for refuel), and probably there for any AI models. However there is nothing regarding the Carriers components, catapults and wires positions. Into YASim the positions of each component, catapults and wires positions are calculated. 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 ? I guess, if we had these values it should be possible to process them into JSBsim in order to get an achieved Carrier Landing/takeOFF simulation. At least , easier for Jon to include that simulation into JSBSim. I can be wrong, it could be many other better approach 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=/ ___ Jsbsim-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___ The JSBSim Flight Dynamics Model project http://www.JSBSim.org ___ - 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] Error in HUD
Hi, Some time ago I was in need to display altitude in meters on HUD. I have copied desired HUD to airplane folder and check it working. Then I change disp_scaling to 0.3048 and got strange altitude scale. As I understand we got foot scale with meter markers. After studying sources I desided that instr_item::get_value() have to return scaled value. With this I got normal altitude scales but broken roll scale. New study made it clear that problem is in the file hud_dnst.cxx. In call to instr_item() parameter data_scaling is missed: instr_item(x, y, width, height, chn1_source, options, working), Problem was fixed by changing it to : instr_item(x, y, width, height, chn1_source, 1, options, working), Can somebody fix this in CVS. PS At July I was asked for some of mine changes for FG. May be it will be usefull for somebody else. Descriptions and links for downloading are at http://buz6919.newmail.ru/FlightGear.html. They will stay here till September or October. If You got problems with downloading (there may be pages on Russian), feel free to ask archives via e-mail. With respect, Alex - 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] Error in HUD
Alex Buzin a écrit : ... Can somebody fix this in CVS. Done, thanks -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - 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] Startup position offsets (fg_init)
I'm writing some automated testing code for pieces of FG, so that I can experiment with changes to various internal bits of code with more confidence that I haven't broken anything. These aren't quite unit- tests (they test multiple areas of the code at once) and they're pretty crude, but any testing is better than none (and quicker than manual testing). Initially I've focused on the various things done by fgInitPosition, since this indirectly uses the Navaids and airports data, and potentially the environment code. Doing this, I came across something which seems counter-intuitive to me: There's a /sim/presets/offset-distance-nm property, which allows (logically enough) to offset the start position relative to, for example, a runway. What I've found is that for a runway, where the / sim/presets/heading-deg is initialised from the runway heading, the 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. Line 771 of fg_init.cxx (double azimuth = heading + 180.0;) is the relevant piece of logic. 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. Note there's also /sim/airport/runways/start-offset-m, which *is* 'forwards' from the threshold. 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. Anyway, that's my analysis, I'd love someone to check my logic and see if they concur or disagree. Regards, 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)
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. Regards, Curt. On Sun, Aug 24, 2008 at 3:53 PM, James Turner wrote: I'm writing some automated testing code for pieces of FG, so that I can experiment with changes to various internal bits of code with more confidence that I haven't broken anything. These aren't quite unit- tests (they test multiple areas of the code at once) and they're pretty crude, but any testing is better than none (and quicker than manual testing). Initially I've focused on the various things done by fgInitPosition, since this indirectly uses the Navaids and airports data, and potentially the environment code. Doing this, I came across something which seems counter-intuitive to me: There's a /sim/presets/offset-distance-nm property, which allows (logically enough) to offset the start position relative to, for example, a runway. What I've found is that for a runway, where the / sim/presets/heading-deg is initialised from the runway heading, the 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. Line 771 of fg_init.cxx (double azimuth = heading + 180.0;) is the relevant piece of logic. 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. Note there's also /sim/airport/runways/start-offset-m, which *is* 'forwards' from the threshold. 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. Anyway, that's my analysis, I'd love someone to check my logic and see if they concur or disagree. Regards, 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 -- 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
