Re: [Flightgear-devel] Time for a new release?
Stuart Buchanan a écrit : Hi All, It hasn't been discussed for at least a couple of months, so I thought I'd bring up that old chestnut, when are we going to have a new release?. From the website, here are the pervious release dates: 0.9.5 - 2004/07 0.9.6 - 2004/10 0.9.8 - 2005/01 0.9.9 - 2005/11 0.9.10 - 2006/04 Despite Mathias' hard work, I think it is unlikely that OSG is going to be complete enough to provide graphical improvements over plib in the next 3-6 months. That means an OSG release is not going to be a realistic prospect until the autumn - a year and a half after the last release. I think there have been huge improvements in the software over 0.9.10, not to mention an explosion in the number of aircraft, to warrant a release of the PRE_OSG_PLIB_WHATEVER branch that Melchior has been keeping up to date for just such an occassion. We could call it 0.9.11 Curt - traditionally this has been your call, as it has been a major drain on your time. How's your schedule looking :), and would it be possible to delegate more of the work ? -Stuart Hi Stuart, In my point of view (a simple gamer), it could be a good thing because it's a bit hard to compile everything from cvs... Regards, Cyprien - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time for a new release?
On Fri 30 March 2007 17:43, Stuart Buchanan wrote: Hi All, It hasn't been discussed for at least a couple of months, so I thought I'd bring up that old chestnut, when are we going to have a new release?. From the website, here are the pervious release dates: 0.9.5 - 2004/07 0.9.6 - 2004/10 0.9.8 - 2005/01 0.9.9 - 2005/11 0.9.10 - 2006/04 Despite Mathias' hard work, I think it is unlikely that OSG is going to be complete enough to provide graphical improvements over plib in the next 3-6 months. That means an OSG release is not going to be a realistic prospect until the autumn - a year and a half after the last release. I think there have been huge improvements in the software over 0.9.10, not to mention an explosion in the number of aircraft, to warrant a release of the PRE_OSG_PLIB_WHATEVER branch that Melchior has been keeping up to date for just such an occassion. We could call it 0.9.11 Curt - traditionally this has been your call, as it has been a major drain on your time. How's your schedule looking :), and would it be possible to delegate more of the work ? -Stuart That is a nice idea mainly if it could include the carrier functions within JSBSim (part of External Forces develepoment) :) Regards -- Gérard - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time for a new release?
That is a nice idea mainly if it could include the carrier functions within JSBSim (part of External Forces develepoment) :) Regards -- Gérard I'm still working on it! :-) Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] KNID: New Airport layout ant buildings
Melchior FRANZ a écrit : * alexis bory -- Saturday 31 March 2007: I've modelled KNID (China Lake Naval Air Weapons Station, CA.) buildings and taxiways layout. http://croo.murgl.org/fgfs/scenery/ That must be the nicest airport available for fgfs (though I haven't seen most of the German airports). That make me think that there is no common process to make new airports available (like CVS or such kind of system), so it's rather difficult for people using the 9.10 Scenery to fetch patches here and there (excepted the Object database). May be an updated list of available patches for aiports (like the German ones) on the wiki could be a starting point. It needs some 'advertising' too. I hope there will be an explosion of new airport Scenery before the next release. An updated/uniformized/simplified Scenery (TerragaGear) documentation would be a great help as it's still a struggle to get the good data sets and manage to have airports at the good altitude ;) Alexis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another problem with fgfs-build
Nick Warne a crit: On Sunday 01 April 2007 14:30:09 Ralf Gerlich wrote: Hi, cyprien wrote: Hi again ! After compiling everything successefully with a make all, i've launch ./install/bin/fgfs, but i've this error : [EMAIL PROTECTED]:~/fgfs-builder-20070222$ ./install/bin/fgfs ./install/bin/fgfs: error while loading shared libraries: libosgUtil.so: cannot open shared object file: No such file or directory i've tried a sudo make install but i've the same error... Try setting your LD_LIBRARY_PATH to include your ./install/lib and ./install/lib/osgPlugins directory. You shouldn't really use LD_LIBRARY_PATH at all - see here (and no offence meant): http://linuxmafia.com/faq/Admin/ld-lib-path.html Cyprien: Run 'ldconfig' as root (or sudo) after building FG and associated code: sudo /sbin/ldconfig This will update the libs cache. Nick OK, thanx for the tip... everything works fine now expect... when i launch ./bin/fgfs : Base package check failed ... Found version [none] at: /home/cyprien/fgfs-builder-20070222/install/share/FlightGear Please upgrade to version: 0.9.10 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash with route manager dialog
Should be fixed now. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
On Mon, 2007-04-02 at 13:45 +0100, Nick Warne wrote: Hi all, Helping Vivian today on the Spitfire model, the gear warning (stall) klaxon wasn't working for me [again] although Vivian had fixed the previous issue why it failed sometimes. After investigation, it turns out one of the conditions required for the stall warning to go off is: equals propertycontrols/engines/engine/throttle/property value0/value /equals It turns out I calibrated my JS using JSCAL, and the throttle axis ran from -32766 - 32767. Thus, when my throttle was off, FG actually reports it as (similar): 1.598490389232043e -5 so it isn't '0', and therefore klaxon criteria wasn't met. Hand 'tweaking' my jscal file, I have now got my JS to report -32767 - 32767 on all axis, and now FG does show throttle to be 1 - 0 at the ends of the range. So, how accurate does the throttle need to be? Surely not 1.5e -5? Nick You probably should change the condition to not depend on a perfectly rigged joystick. Testing for equal is not a great idea any time you are using floating point math... This is the gear warning out of the c182rg: gear-horn namegear-horn/name modelooped/mode pathAircraft/c182rg/Sounds/stall-600-chopped.wav/path condition and less-than propertycontrols/engines/engine/throttle/property value0.3/value /less-than equals propertycontrols/gear/gear-handle-down/property value0/value /equals /and /condition /gear-horn As you can see, it only needs the throttle to be less than 30%. Try something like this for the spitfire: condition and less-than propertycontrols/engines/engine/throttle/property value0.2/value /less-than equals propertycontrols/gear/gear-down/property value0/value /equals equals propertysim/alarms/gear-warn/property value0/value /equals /and /condition Ron - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
Hi Ron, On Monday 02 April 2007 14:19:17 Ron Jensen wrote: So, how accurate does the throttle need to be? Surely not 1.5e -5? Nick You probably should change the condition to not depend on a perfectly rigged joystick. Testing for equal is not a great idea any time you are using floating point math... This is the gear warning out of the c182rg: As you can see, it only needs the throttle to be less than 30%. Try something like this for the spitfire: less-than propertycontrols/engines/engine/throttle/property value0.2/value /less-than Yes, as discussed in IRC today, this solution came up, but why on earth are the throttle values measured with so much accuracy? Surely 1.5e -5 is way over the top? Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
[throttle precision] * Nick Warne -- Monday 02 April 2007: Surely 1.5e -5 is way over the top? Depending on the js quality, joysticks can return different number ranges. If I turn off the cooked joystick mode in Linux for my 6 axes Saitek Cyborg-Gold-3D-USB: $ jscal -s 6,0,0,0,0,0,0,0,0,0,0,0,0 /dev/input/js0 then I get pretty poor results: $ jstest /dev/input/js0 Axes: [...] 3: 168 [...] [...] Axes: [...] 3: 12 [...] Only a range of 12..168. Maybe I could get a few notches out of it by recalibrating, but that's it. As every joystick can return different values, depending on brand, type, age, etc., it's the kernel's job to normalize that into a standardized range. After calibrating it maps the 12..168 to -32767..32767. And because that's still not very usable for apps like fgfs, plib normalizes that again to -1.0 .. 1.0, which is most useful to scale other values (such as throttle input to the FDM). By applying factors and offsets, turning the integer range into a floating point number range creates the illusion of high precision. But the resolution hasn't become any better. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
On Mon, 2007-04-02 at 14:43 +0100, Nick Warne wrote: Hi Ron, On Monday 02 April 2007 14:19:17 Ron Jensen wrote: So, how accurate does the throttle need to be? Surely not 1.5e -5? Nick You probably should change the condition to not depend on a perfectly rigged joystick. Testing for equal is not a great idea any time you are using floating point math... This is the gear warning out of the c182rg: As you can see, it only needs the throttle to be less than 30%. Try something like this for the spitfire: less-than propertycontrols/engines/engine/throttle/property value0.2/value /less-than Yes, as discussed in IRC today, this solution came up, but why on earth are the throttle values measured with so much accuracy? Surely 1.5e -5 is way over the top? Nick In computer science integer land you can use 8-bits (-127 to 128 or 0 to 255 ) or 16-bits (-32767 to 32768 or 0 to 65536) there isn't any in between solution and 8-bit isn't accurate enough, so all the axises are 16-bit. 1.5e -5 equals 1/65536. The question is, why do you expect the throttle axis to exactly hit its low stop? I don't have the reference handy for the c182rg, but the 30% setting we used is based on real numbers for the plane. Ron - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
On 04/02/2007 09:43 AM, Nick Warne wrote: Yes, as discussed in IRC today, this solution came up, but why on earth are the throttle values measured with so much accuracy? Surely 1.5e -5 is way over the top? What's the alternative? If we're not going to use floating point, what are we supposed to use instead? I'm guessing that the implied alternative is to quantize the throttle settings using some fairly coarse step-size. That is a Bad Idea for numerous reasons. The most obvious is that it is unrealistic; on most real aircraft over most of the range, the throttle motion is smooth and unquantized. What's worse, in cases where the hardware throttle simulator happens to be quantized, there would be conflict between the HW quantization and the SW quantization, which would cause all sorts of weird behavior. If somebody has a better alternative, please explain. Furthermore, I haven't seen the slightest evidence that floating-point throttle positions cause a problem when modeling realistic or even quasi-realistic aircraft behavior. I am not aware of any carburetor, gear warning horn, or other appliance where the functionality depends on the position of anything being equal to the position of anything else. Such an equality check would be bad design. A floating-point representation of a bad design is still a bad design; no surprise there. So my suggestion is to figure out the /real/ throttle behavior of interest, and model that. If floating-point is even the slightest obstacle to building a realistic model, please explain. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
Hi John, On Monday 02 April 2007 15:31:43 John Denker wrote: So my suggestion is to figure out the /real/ throttle behavior of interest, and model that. If floating-point is even the slightest obstacle to building a realistic model, please explain. I wasn't complaining here, just raising this issue. By my reckoning, if a throttle is OFF, then it is OFF, and not 0.15 ON. Sure, use a floating point, but does it really have to be that accurate that a very slightly out-of-calibration JS by 1 point out of 65535 makes it wrong? Surely 0.001 is reasonable enough step? BTW, this was only an observation working with Vivian today - it isn't my aircraft to make the changes to. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
On Monday 02 April 2007 16:17:31 Nick Warne wrote: Hi John, On Monday 02 April 2007 15:31:43 John Denker wrote: So my suggestion is to figure out the /real/ throttle behavior of interest, and model that. If floating-point is even the slightest obstacle to building a realistic model, please explain. I wasn't complaining here, just raising this issue. By my reckoning, if a throttle is OFF, then it is OFF, and not 0.15 ON. Sure, use a floating point, but does it really have to be that accurate that a very slightly out-of-calibration JS by 1 point out of 65535 makes it wrong? Surely 0.001 is reasonable enough step? BTW, this was only an observation working with Vivian today - it isn't my aircraft to make the changes to. OK, to put this to bed, Vivian has fixed up the code so that a 'less than' condition is used rather than an exact figure. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possibly joystick bug condition
On 04/02/2007 11:17 AM, Nick Warne wrote: By my reckoning, if a throttle is OFF, then it is OFF, and not 0.15 ON. I beseech you to change your reckoning. 1) As previously mentioned, real aircraft don't work that way. In real aircraft, this is even more noticeable with respect to the full-on position than w.r.t the full-off position. Try shoving the throttle all the way forward in a typical GA aircraft sometime, and then look at the position of the control. It does *not* go all the way forward to the firewall. There is, by design, some relief between the max position and the fully-forward position. (The same is true of the mixture control and a wide class of other controls.) Aircraft designers have arranged that proper operation of the control does not depend on the control cable length being equal to the ideal length. Almost any design that requires one thing to be equal to another is an unsound design, and should be *instantly* recognized as such. I cannot imagine any good reason for checking for throttle 0.00 *or* throttle 0.15 ON, either one. If you have a good reason, please explain. In contrast, as Ron pointed out, a real C182rg has a real microswitch that tests for throttle less than 30% open ... and the FG C182rg faithfully models this. No test for equality. No problem. 2) More generally, as a matter of standard good practice, testing real-world data for floating-point equality is almost always unsound, and should be *instantly* recognized as such. Floating point has been around for a long time, and people have learned how to test for equality ... which usually means /avoiding/ testing real-world data for floating-point equality. http://www.google.com/search?q=floating-point+equality - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
