Re: [Flightgear-devel] New joystick definition for: Speedlink SL-6640 Black Widow (bugfix)
Hi All, unfortunately there is a nasty error in my definition file (... type=string... was not correct due to copy and paste). Thanks to Jester who pointed me to this. Cheers Mike ?xml version=1.0? !-- Joystick Definition for Speed-Link SL-6640 Black Widow http://www.speed-link.com/?p=2cat=313pid=1533paus=1 4-Axis, 8 Buttons, 8-way Coolie-Hat, Force-Feedback-Vibration (not in FG yet) My definitions: type W# U# M# assign ## Axis 0 0 ? ailerons Axis 1 1 ? elevator Axis 2 2 ? throttle Axis 3 3 ? rudder Axis 6 4 ? horizantal view direction Axis 7 5 ? vertical view direction Btn 0 0 ? Reset View Btn 1 1 ? Gear Up/Down Btn 2 2 ? Flaps Up Btn 3 3 ? Flaps Down Btn 4 4 ? Thrust Reverser Btn 5 5 ? Speed Brakes Btn 6 6 ? Elevator Trim Backward Btn 7 7 ? Elevator Trim Forward Notes, Todo and Addendum: - Pressing a button will bring up the gui.popupTip for the representing function - Addionally Buttons 2 and 3 (Flaps Up/Down) and Buttons 6 and 7 (Elevator Trim Up/Down) returns a value on screen telling the actual chosen settings - Button- and Axis-assignment respect the use of civil planes. e.g. Button 0 (aka Fire Trigger is resetting actual view instead of fiering off a weapon) and Button 1 is reprensenting Gear Up/Down instead of alternate weapon - Numbering of axes and buttons for Apple mac not verified - Numbering of Buttons 6 and 7 respect how Windows Vista x64 (german) sees the Stick. In Ubuntu (9.04) Buttons 6 and 7 must be renumbered to 4 and 5. - Created and (mainly) tested in MS Windows Vista Home premium x64 (german) - Name-entries respect the lack of Vista (german) to present the correct joystick-name as desired for FGFS - Representing also the jostick-name as provided in Windows-internal registry entry - Actually only wheel[0] (most times the nose wheel) is checked for pressure / ground contact (=./gear/gear[0]/wow). In this case retraction of gear is not allowed So technically on aircraft with multiple axis (e.g. nose wheel plus wing wheels) can retract the gear as soon as the nose wheel is up but wing wheels are still on ground ;) - Feel free to remove the lines starting with gui.popupTip... if you are annoyed by the messages within FG ;) Brought to you by Mike (Callsign: D-SKY1) (c) 2009 This file is released under the GPL license v2 or later. $Id: black-widow.xml,v 1.1 2009/09/24 00:50:00 d-sky1 Exp $ -- PropertyList name type=stringMicrosoft-PC-Joysticktreiber/name name type=stringMega World USB Game Controllers/name name type=stringSpeedLink SL-6640 Black Widow Flight Stick/name axis desc type=stringAileron/desc number windows0/windows mac0/mac unix0/unix /number binding commandproperty-scale/command property/controls/flight/aileron/property offset type=double0.0/offset factor type=double1.0/factor dead-band type=double0.02/dead-band /binding /axis axis desc type=stringElevator/desc number windows1/windows mac1/mac unix1/unix /number binding commandproperty-scale/command property/controls/flight/elevator/property offset type=double0.0/offset factor type=double-1.0/factor dead-band type=double0.02/dead-band /binding /axis axis desc type=stringThrottle/desc number windows2/windows mac2/mac unix2/unix /number binding commandnasal/command scriptcontrols.throttleAxis()/script /binding /axis axis desc type=stringRudder/desc number windows3/windows mac3/mac unix3/unix /number binding commandproperty-scale/command property/controls/flight/rudder/property offset type=double0.0/offset factor type=double1.0/factor dead-band type=double0.02/dead-band /binding /axis axis desc type=stringView Direction/desc number windows6/windows mac6/mac unix6/unix /number low repeatable type=booltrue/repeatable binding commandnasal/command script ![CDATA[ view.panViewDir(1); ]] /script /binding /low high repeatable type=booltrue/repeatable binding commandnasal/command script ![CDATA[ view.panViewDir(-1); ]] /script /binding /high /axis axis desc type=stringView Elevation/desc number windows7/windows mac7/mac unix7/unix /number low repeatable type=booltrue/repeatable binding commandnasal/command script ![CDATA[ view.panViewPitch(-1); ]] /script /binding /low high repeatable type=booltrue/repeatable binding commandnasal/command script ![CDATA[ view.panViewPitch(1); ]] /script /binding /high /axis button n=0 desc type=stringReset View/desc binding commandnasal/command script ![CDATA[ view.resetView(); gui.popupTip(View Reset!); ]] /script /binding /button button n=1 desc type=stringGear/desc binding commandnasal/command script ![CDATA[ var wowprop = getprop(/gear/gear[0]/wow); var gearprop =
[Flightgear-devel] Hardware bottleneck for building scenery
Hey gang. I'm working on a high resolution version of the scenery for my home, Newfoundland. It's coming along VERY well, but I'm running into limitations of what my computer can handle building. Essentially, I've cut the fgfs-construct commands into the theoretically smallest allowable sizes: I'm running the command around 4000 times, each time doing a 0.0625 by 0.125 degree piece of scenery. Even while cutting the job up into such small pieces, the process gets killed sometimes. However, the resulting scenery looks fantastic, and runs fine. But I know that somewhere out there are places where there will be strange artifact from a build that died pre-maturely. My question is this: what is the hardware bottleneck here? As far as I can tell, the system isn't running out of ram, as my monitored usage stays around 200MB. I'm using a dual core processor, and for each build, it runs one processor at 100% while the other idles around 5-10%. Each time it starts work on a new piece, the processors switch workload. What needs to be improved to keep a really complicated scenery build from being killed? -cullam __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hardware bottleneck for building scenery
Just a real quick reply here ... there is some code setup so the process will kill itself if it runs longer than some period or consumes too much memory. This was setup because some data cases would blow up and lead to infinite loops and infinite memory expansion (within some of our external libraries.) You may want to eliminate this code or expand the thresholds. Regards, Curt. On Thu, Sep 24, 2009 at 10:47 AM, cullam Bruce-Lockhart wrote: Hey gang. I'm working on a high resolution version of the scenery for my home, Newfoundland. It's coming along VERY well, but I'm running into limitations of what my computer can handle building. Essentially, I've cut the fgfs-construct commands into the theoretically smallest allowable sizes: I'm running the command around 4000 times, each time doing a 0.0625 by 0.125 degree piece of scenery. Even while cutting the job up into such small pieces, the process gets killed sometimes. However, the resulting scenery looks fantastic, and runs fine. But I know that somewhere out there are places where there will be strange artifact from a build that died pre-maturely. My question is this: what is the hardware bottleneck here? As far as I can tell, the system isn't running out of ram, as my monitored usage stays around 200MB. I'm using a dual core processor, and for each build, it runs one processor at 100% while the other idles around 5-10%. Each time it starts work on a new piece, the processors switch workload. What needs to be improved to keep a really complicated scenery build from being killed? -cullam __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Is ther any MSVC example code to send/receive data to FG over an internet connection?
I am testing a new Primary Flight Display with a tunnel in the sky. It will run on a separate computer and I need FlightGear for it's flight dynamics. I'ld like the PFD to receive Lat, lon, altitude, heading, pitch, roll, alpha and beta from FG and also I'ld like to tell FG to put out the gear and flaps when the altitude first goes below 1000 ft. Curt Olson says that I could do it with an internet connection, to gather variables and send commands. Is there any example code written in MSVC I could look at to make the internet connection on the PFD end? Thanks, Randy Green -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi, Sorry for my late contribution to this topic: I am late catching up with my mails since my last holidays. Let me tell you from my personal experiences some weeks ago with git and hg an linux and Windows. Windows Implementations: git can be tedious to use on Windows: I had big problems working on a project mixing up git repositories on linux pushed and pulled by a windows git via samba. git at some point complained about non existing differences: Somehow line ending issues emerged, or the object store got corrupted. I had no chance to look deeper into details. The stable git command on Windows needs cygwin, which is not a minimal invasive installation. (I wouldn't recommend the msys/mingw installation at this point.) The hg (mercurial) Implementation of Windows is very lean, because no POSIX emulation layer is needed. I (luckily?) had no problems with respect to line endings with hg. Branch Handling: IMHO the git remote repository handling is complex and error prone. We would need a fine manual to instruct developers how to lay out their branches, because their are trillions of chances to mess up a repository. (Something like http://wiki.samba.org/index.php/Using_Git_for_Samba_Development ) Hg is quite easy (some say limited) with respect to this aspects. You can simply push your changes where you have got them, no need to mess with bare repositories. In a nutshell, IMHO hg is easier to use for a random user wanting a quick look at the source code. Git gives the power user the opportunity to implement even the unthinkable while being is a little bit beasty if you do not have a clean checkout. Greetings, Olaf -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi Olaf, Olaf Flebbe wrote: [...] I had no chance to look deeper into details. The stable git command on Windows needs cygwin, which is not a minimal invasive installation. (I wouldn't recommend the msys/mingw installation at this point.) People to whom I've talked happily recommended this one: http://code.google.com/p/msysgit/ and I'd be happy to learn about your dislike. Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
Erik, I would like to see an option to disable sound at all. Did you know that the sound system eats up to 30% of CPU time, depending on hardware? This even with --disable-sound on the command line. I found it while profiling fgfs on my eeepc with ubuntu, which is largely affected because of its low end hardware. Enabling OpenAL starts a thread which is constantly eating up CPU cycles. 30% of CPU. (pulseaudio _is_ disabled BTW) [ I was able to improve FPS rate from 1 FPS to 15 FPS with disabling OpenAL altogether and further quirks. But fgfs still is barely useable on the eeepc ] Greetings, Olaf -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On Thu, Sep 24, 2009 at 5:38 PM, Olaf Flebbe f...@oflebbe.de wrote: Erik, I would like to see an option to disable sound at all. Did you know that the sound system eats up to 30% of CPU time, depending on hardware? This even with --disable-sound on the command line. I found it while profiling fgfs on my eeepc with ubuntu, which is largely affected because of its low end hardware. Enabling OpenAL starts a thread which is constantly eating up CPU cycles. 30% of CPU. (pulseaudio _is_ disabled BTW) Which version of OpenAL? There were recently (over a month ago?) some improvements in that respect, still, OpenAL shouldn't be using any processing at all. I'm at work and leaving in a few minutes, so I'll check once I get home. [ I was able to improve FPS rate from 1 FPS to 15 FPS with disabling OpenAL altogether and further quirks. But fgfs still is barely useable on the eeepc ] I would say something about fgfs on the EeePC, but I would like to run it on an N900 as soon as I get my hands on one, so... ;-) Cheers, Matt D. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi Martim, People to whom I've talked happily recommended this one: http://code.google.com/p/msysgit/ and I'd be happy to learn about your dislike. 1) From the Installation Manual: http://code.google.com/p/msysgit/wiki/InstallMSysGit ... Note: Git for Windows is not as stable as Git for anything else. There are more issues with the Windows API than there are developers working on them. ... 2) From the homepage: So you do not want to help? Then there is nothing to see here, please move along. this is not friendly for the casual user of some kind of middleware when I have other options. Greetings, Olaf -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
Hi, Which version of OpenAL? There were recently (over a month ago?) some improvements in that respect, still, OpenAL shouldn't be using any processing at all. I'm at work and leaving in a few minutes, so I'll check once I get home. The version from ubuntu jaunty is 1.4.272 Olaf -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi Olaf, Olaf Flebbe wrote: [...] this is not friendly for the casual user of some kind of middleware when I have other options. Well, they're providing installer packages and people are using it in real-world development for a while already. Therefore I was under the assumption that it's probably not that bad. Did you actually have the chance to try it out ? Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
