Re: [Flightgear-devel] GUI Improvements was: Things to do to improveFlightgear
On Saturday, 18 December 2004 04:32, Ampere K. Hardraade wrote: > I agree. If there is room for improvement with the current GUI, then we > should continue to use it. This is a big issue for me at the moment. It is VERY hard to do anything to the FG menu system without stepping on a least three people's toes at the same time. Half the problem I face is that the current XML system is useless for anything beyond the trivial combo box, checkbox type stuff. For instance how can I load a combo box with new contents when something in another combo box is selected? i.e. Dynamic content. Also some of the stuff I want to do requires a bit of OpenGL work which is not possible with the current XML driven menu system. I would love to get everything into FG but separate launchers are so much easier to code since you don't have to please everyone and explain your motivation and reasoning for every single line of code. Coding a better interface is the easy part - it's getting everyone to agree on the changes that is the show stopper. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Video card recommendations
Curtis L. Olson writes: > > I am involved with a project where we are going to setup a multi-channel > visual system running flightgear. (3 PC's, 3 monitors.) We can budget > about $150-200 for the graphics cards, but the landscape has changed so > much since I last shopped I'm not sure what to do. We are committed to > buying something nvidia/GeForce based. The new 6800 cards are still way > out of our price range. The 5900/5950 cards are probably a bit high > right now too. But I see there area 5200's, 5500's, 5700's. and you can > still find the older ti4600/4800 cards floating around too. I know that > some of these varients were designed more as low end/cheap consumer > cards, and I'd like to get something with the best > capability/performance I can within our budget. Does anyone have any > recommendations? If you have PCI motherboards this looks like it will deliver the most bang for the buck http://www.anandtech.com/video/showdoc.aspx?i=2300 Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Double-clicking the icon isn't the problem. In many cases, getting the .fgfsrc file properly installed was the problem. For my next release, I was going to include a python script that would set up the file and modify the default resource file. Many Mac users that subscribe to the Users mailing list are not UNIX literate. This is a problem for me since I am use to dealing with UNIX types and don't know how to write for a person who isn't. It really is a change in thinking. Jonathan Polley On Dec 17, 2004, at 6:09 PM, Arthur Wiebe wrote: lol, How many different ways can you explain to somebody how to double click an icon. On Fri, 17 Dec 2004 18:07:26 -0600, Jonathan Polley <[EMAIL PROTECTED]> wrote: That is not necessarily the case. I have had a heck of a time explaining to users how to get the application to run. On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: It's a single application in a disk image. No instructions included. I figured anyone downloading FlightGear would know what to do with it. By the way Curt, it's done uploading. On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley <[EMAIL PROTECTED]> wrote: Arthur, Considering the problems some people have been having in running the Mac version, have you added instructions to the .dmg file? I was able to host the previous version (0.9.6) on my .mac account, but it was less than 125 MB (which is my limit). 0.9.6 is the current version is it not? My package is built from CVS 2004-12-17 so I named the version 0.9.6+. Jonathan Polley On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe <[EMAIL PROTECTED]> wrote: I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Would you mind repeating your original intention, Jon? > > Ampere I started out with the question: "Can anyone recommend a good digital camcorder?" and it went downhill from there. ;-) Here was my original question: "I'd like to remove the code that normalizes angular measurement, but I am told that FlightGear requires normalized angular measurement, which seems, on the surface, ridiculous. At the very least, I'd like to move the normalization code out of our flight controls code (JSBSim) and into the flightgear interface code, since it appears to be a requirement of FlightGear only." There is some normalization code in our flight controls code that exists really only for the benefit of FlightGear modelers. As such, I wanted to remove it from JSBSim, and into the FGInterface (FGJSBSim) class. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Would you mind repeating your original intention, Jon? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Would you mind repeating your original intention? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GUI Improvements was: Things to do to improveFlightgear
On December 17, 2004 06:28 am, Matthew Law wrote: > Personally, I'd prefer to see a nice OpenGL based GUI like some of the > other simulators and, dare I say it, games. With this method you can > throw out native look and feel and just have a very nice looking > functional user interface that works on any platform with OpenGL > support. > > > All the best, > > Matthew. I agree. If there is room for improvement with the current GUI, then we should continue to use it. On December 17, 2004 10:33 am, Oliver C. wrote: > > Several commercial games use it for their GUI jsut for the reasons > > you described including at least one EA title > > What commercial games use PUI? > > Best Regards, > Oliver C. Simcity 4? Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Video card recommendations
On Saturday 18 Dec 2004 00:46, Arnt Karlsen wrote: > ..these are Nvidia clones, which chip? They are not clones, in fact they are Nvidia produced PCBs (the only card they ever contracted for self manufacture. The only components the OEMs were allowed to alter were the back-planes and coolers (although most retained the Nvidia FlowFX). The chip is an Nvidia NV30. AGP 8x Core: 500Mhz Pipes: 4 TMU/Pipe: 2 Transitors: 125Million in 0.13µm die. Memory: 500Mhz 128bit DDR II (1000Mhz over 2 banks). Bandwidth: 16~48GB/s The card was not a commercial success since Nvidia controlled the production, hence they're now cheap and the NV3x series is all OEM produced. (Not to mention the huge copper heatsink/pipe, 2xpci backplane and ducted rear intake/exhaust (loud) fan housing. Through extensive testing we have proven the performance to be equal with a 5900U at standard clocks. :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
On Sat, 18 Dec 2004 01:43:04 +0100, Arnt Karlsen <[EMAIL PROTECTED]> wrote: > On Fri, 17 Dec 2004 16:55:26 -0500, Arthur wrote in message > <[EMAIL PROTECTED]>: > > > I have built an application bundle of FlightGear for Mac OS X. It's a > > rather large application because it includes everything such as the > > base data, fgfs, etc. Compressed it's a total of 132 MB. > > > > I have no place to host such large files > > ...so sign up with SourceForge or somesuch: > http://sourceforge.net/account/newuser_emailverify.php > > .AFAICTF > http://sourceforge.net/docman/display_doc.php?group_id=1&docid=6048 > your bundle is acceptable at SourceForge.net. I'm an active SF.net user and administrator of two projects there. I didn't think simply a package of another product would be worth a new project though, there is GIMP-App > > -- > ..med vennlig hilsen = with Kind Regards from Arnt... ;-) > ...with a number of polar bear hunters in his ancestry... > Scenarios always come in sets of three: > best case, worst case, and just in case. > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Video card recommendations
On Sat, 18 Dec 2004 00:13:59 +, Dave wrote in message <[EMAIL PROTECTED]>: > May I suggest looking out for GeForce FX5800Us. > > Myself and a friend managed to pick an unused pair up a few months ago > for very little money and they are quite frankly 'storming' cards. > > They have a 500Mhz GPU and 1000Mhz (DDR) memory on 128bit bus and > manage to keep up with the higher-spec 5900/U's by using sheer > brute-force clocks rather than wider memory busses. > > The catch with the card is the FlowFX system which is *fairly* noisy > but not louder than a modern air-cooled high-performance PC. > > Plus they run a treat with Linux and are fully supported by the Nvidia > driver set including temp sensing etc. ..these are Nvidia clones, which chip? > > On Friday 17 Dec 2004 23:36, Curtis L. Olson wrote: > > I hope this isn't too off topic ... > > > > I am involved with a project where we are going to setup a > > multi-channel visual system running flightgear. (3 PC's, 3 > > monitors.) We can budget about $150-200 for the graphics cards, but > > the landscape has changed so much since I last shopped I'm not sure > > what to do. We are committed to buying something nvidia/GeForce > > based. The new 6800 cards are still way out of our price range. > > The 5900/5950 cards are probably a bit high right now too. But I > > see there area 5200's, 5500's, 5700's. and you can still find the > > older ti4600/4800 cards floating around too. I know that some of > > these varients were designed more as low end/cheap consumer cards, > > and I'd like to get something with the best capability/performance I > > can within our budget. Does anyone have any recommendations? > > > > Thanks, > > > > Curt. > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
On Fri, 17 Dec 2004 16:55:26 -0500, Arthur wrote in message <[EMAIL PROTECTED]>: > I have built an application bundle of FlightGear for Mac OS X. It's a > rather large application because it includes everything such as the > base data, fgfs, etc. Compressed it's a total of 132 MB. > > I have no place to host such large files ...so sign up with SourceForge or somesuch: http://sourceforge.net/account/newuser_emailverify.php .AFAICTF http://sourceforge.net/docman/display_doc.php?group_id=1&docid=6048 your bundle is acceptable at SourceForge.net. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Video card recommendations
Curt, Given the budget and assuming the prices over this side of the pond aren't too different to you, I'd go for something like this: http://makeashorterlink.com/?N69123E0A I like Gainward cards. They usually use better quality, slightly faster RAM which allows them to be clocked up a little while still remaining stable. All the best, Matthew. Curtis L. Olson wrote: I hope this isn't too off topic ... I am involved with a project where we are going to setup a multi-channel visual system running flightgear. (3 PC's, 3 monitors.) We can budget about $150-200 for the graphics cards, but the landscape has changed so much since I last shopped I'm not sure what to do. We are committed to buying something nvidia/GeForce based. The new 6800 cards are still way out of our price range. The 5900/5950 cards are probably a bit high right now too. But I see there area 5200's, 5500's, 5700's. and you can still find the older ti4600/4800 cards floating around too. I know that some of these varients were designed more as low end/cheap consumer cards, and I'd like to get something with the best capability/performance I can within our budget. Does anyone have any recommendations? Thanks, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Ok. I'll include instructions in the next version. Right now I'm trying to get fgrun going on Mac OS X and maybe include that in the next version as well if it's good. So far fgrun doesn't look like it's going to work. On Fri, 17 Dec 2004 16:13:13 -0800, Adam Dershowitz <[EMAIL PROTECTED]> wrote: > I agree. That first time was not at all clear. > It would be great to include some instructions as well, or many people just > won't get it. > > -- Adam > > > From: Jonathan Polley <[EMAIL PROTECTED]> > > Reply-To: FlightGear developers discussions > > <[EMAIL PROTECTED]> > > Date: Fri, 17 Dec 2004 18:07:26 -0600 > > To: FlightGear developers discussions <[EMAIL PROTECTED]> > > Subject: Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle > > Available > > > > That is not necessarily the case. I have had a heck of a time > > explaining to users how to get the application to run. > > > > On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: > > > >> It's a single application in a disk image. No instructions included. I > >> figured anyone downloading FlightGear would know what to do with it. > >> > >> By the way Curt, it's done uploading. > >> > >> On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley > >> <[EMAIL PROTECTED]> wrote: > >>> Arthur, > >>> > >>> Considering the problems some people have been having in running > >>> the Mac version, have you added instructions to the .dmg file? I was > >>> able to host the previous version (0.9.6) on my .mac account, but it > >>> was less than 125 MB (which is my limit). > >> > >> 0.9.6 is the current version is it not? > >> My package is built from CVS 2004-12-17 so I named the version 0.9.6+. > >> > >>> > >>> Jonathan Polley > >>> > >>> On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe > >>> <[EMAIL PROTECTED]> wrote: > >>> > I have built an application bundle of FlightGear for Mac OS X. It's a > rather large application because it includes everything such as the > base data, fgfs, etc. Compressed it's a total of 132 MB. > > I have no place to host such large files so I've made it available > via > BitTorrent. I've attached it to this email. > Hopefully we can get some more people seeding. > > Now it would be really nice if you could switch aircraft from in the > simulator! :) > -- > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > > >>> > >>> Of COURSE they can do that. They're engineers! > >>> > >>> ___ > >>> Flightgear-devel mailing list > >>> [EMAIL PROTECTED] > >>> http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >>> 2f585eeea02e2c79d7b1d8c4963bae2d > >>> > >> > >> > >> -- > >> > >> - http://artooro.blogspot.com (Weblog) > >> - http://machcms.sourceforge.net (MachCMS Project) > >> - http://acalproj.sourceforge.net (Calendar Project) > >> > >> ___ > >> Flightgear-devel mailing list > >> [EMAIL PROTECTED] > >> http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >> 2f585eeea02e2c79d7b1d8c4963bae2d > > > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > 2f585eeea02e2c79d7b1d8c4963bae2d > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
I agree. That first time was not at all clear. It would be great to include some instructions as well, or many people just won't get it. -- Adam > From: Jonathan Polley <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > Date: Fri, 17 Dec 2004 18:07:26 -0600 > To: FlightGear developers discussions <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle > Available > > That is not necessarily the case. I have had a heck of a time > explaining to users how to get the application to run. > > On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: > >> It's a single application in a disk image. No instructions included. I >> figured anyone downloading FlightGear would know what to do with it. >> >> By the way Curt, it's done uploading. >> >> On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley >> <[EMAIL PROTECTED]> wrote: >>> Arthur, >>> >>> Considering the problems some people have been having in running >>> the Mac version, have you added instructions to the .dmg file? I was >>> able to host the previous version (0.9.6) on my .mac account, but it >>> was less than 125 MB (which is my limit). >> >> 0.9.6 is the current version is it not? >> My package is built from CVS 2004-12-17 so I named the version 0.9.6+. >> >>> >>> Jonathan Polley >>> >>> On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe >>> <[EMAIL PROTECTED]> wrote: >>> I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d >>> >>> Of COURSE they can do that. They're engineers! >>> >>> ___ >>> Flightgear-devel mailing list >>> [EMAIL PROTECTED] >>> http://mail.flightgear.org/mailman/listinfo/flightgear-devel >>> 2f585eeea02e2c79d7b1d8c4963bae2d >>> >> >> >> -- >> >> - http://artooro.blogspot.com (Weblog) >> - http://machcms.sourceforge.net (MachCMS Project) >> - http://acalproj.sourceforge.net (Calendar Project) >> >> ___ >> Flightgear-devel mailing list >> [EMAIL PROTECTED] >> http://mail.flightgear.org/mailman/listinfo/flightgear-devel >> 2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
lol, How many different ways can you explain to somebody how to double click an icon. On Fri, 17 Dec 2004 18:07:26 -0600, Jonathan Polley <[EMAIL PROTECTED]> wrote: > That is not necessarily the case. I have had a heck of a time > explaining to users how to get the application to run. > > On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: > > > It's a single application in a disk image. No instructions included. I > > figured anyone downloading FlightGear would know what to do with it. > > > > By the way Curt, it's done uploading. > > > > On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley > > <[EMAIL PROTECTED]> wrote: > >> Arthur, > >> > >> Considering the problems some people have been having in running > >> the Mac version, have you added instructions to the .dmg file? I was > >> able to host the previous version (0.9.6) on my .mac account, but it > >> was less than 125 MB (which is my limit). > > > > 0.9.6 is the current version is it not? > > My package is built from CVS 2004-12-17 so I named the version 0.9.6+. > > > >> > >> Jonathan Polley > >> > >> On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe > >> <[EMAIL PROTECTED]> wrote: > >> > >>> I have built an application bundle of FlightGear for Mac OS X. It's a > >>> rather large application because it includes everything such as the > >>> base data, fgfs, etc. Compressed it's a total of 132 MB. > >>> > >>> I have no place to host such large files so I've made it available > >>> via > >>> BitTorrent. I've attached it to this email. > >>> Hopefully we can get some more people seeding. > >>> > >>> Now it would be really nice if you could switch aircraft from in the > >>> simulator! :) > >>> -- > >>> > >>> > >>> ___ > >>> Flightgear-devel mailing list > >>> [EMAIL PROTECTED] > >>> http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >>> 2f585eeea02e2c79d7b1d8c4963bae2d > >>> > >> > >> Of COURSE they can do that. They're engineers! > >> > >> ___ > >> Flightgear-devel mailing list > >> [EMAIL PROTECTED] > >> http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >> 2f585eeea02e2c79d7b1d8c4963bae2d > >> > > > > > > -- > > > > - http://artooro.blogspot.com (Weblog) > > - http://machcms.sourceforge.net (MachCMS Project) > > - http://acalproj.sourceforge.net (Calendar Project) > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > 2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
That is not necessarily the case. I have had a heck of a time explaining to users how to get the application to run. On Dec 17, 2004, at 6:04 PM, Arthur Wiebe wrote: It's a single application in a disk image. No instructions included. I figured anyone downloading FlightGear would know what to do with it. By the way Curt, it's done uploading. On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley <[EMAIL PROTECTED]> wrote: Arthur, Considering the problems some people have been having in running the Mac version, have you added instructions to the .dmg file? I was able to host the previous version (0.9.6) on my .mac account, but it was less than 125 MB (which is my limit). 0.9.6 is the current version is it not? My package is built from CVS 2004-12-17 so I named the version 0.9.6+. Jonathan Polley On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe <[EMAIL PROTECTED]> wrote: I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
It's a single application in a disk image. No instructions included. I figured anyone downloading FlightGear would know what to do with it. By the way Curt, it's done uploading. On Fri, 17 Dec 2004 17:50:23 -0600, Jonathan Polley <[EMAIL PROTECTED]> wrote: > Arthur, > > Considering the problems some people have been having in running the Mac > version, have you added instructions to the .dmg file? I was able to host > the previous version (0.9.6) on my .mac account, but it was less than 125 MB > (which is my limit). 0.9.6 is the current version is it not? My package is built from CVS 2004-12-17 so I named the version 0.9.6+. > > Jonathan Polley > > On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe <[EMAIL PROTECTED]> > wrote: > > >I have built an application bundle of FlightGear for Mac OS X. It's a > >rather large application because it includes everything such as the > >base data, fgfs, etc. Compressed it's a total of 132 MB. > > > >I have no place to host such large files so I've made it available via > >BitTorrent. I've attached it to this email. > >Hopefully we can get some more people seeding. > > > >Now it would be really nice if you could switch aircraft from in the > >simulator! :) > >-- > > > > > >___ > >Flightgear-devel mailing list > >[EMAIL PROTECTED] > >http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >2f585eeea02e2c79d7b1d8c4963bae2d > > > > Of COURSE they can do that. They're engineers! > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Mac OS X Application Bundle Available
Arthur, Considering the problems some people have been having in running the Mac version, have you added instructions to the .dmg file? I was able to host the previous version (0.9.6) on my .mac account, but it was less than 125 MB (which is my limit). Jonathan Polley On Friday, December 17, 2004, at 03:56PM, Arthur Wiebe <[EMAIL PROTECTED]> wrote: >I have built an application bundle of FlightGear for Mac OS X. It's a >rather large application because it includes everything such as the >base data, fgfs, etc. Compressed it's a total of 132 MB. > >I have no place to host such large files so I've made it available via >BitTorrent. I've attached it to this email. >Hopefully we can get some more people seeding. > >Now it would be really nice if you could switch aircraft from in the >simulator! :) >-- > > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel >2f585eeea02e2c79d7b1d8c4963bae2d > Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Video card recommendations
May I suggest looking out for GeForce FX5800Us. Myself and a friend managed to pick an unused pair up a few months ago for very little money and they are quite frankly 'storming' cards. They have a 500Mhz GPU and 1000Mhz (DDR) memory on 128bit bus and manage to keep up with the higher-spec 5900/U's by using sheer brute-force clocks rather than wider memory busses. The catch with the card is the FlowFX system which is *fairly* noisy but not louder than a modern air-cooled high-performance PC. Plus they run a treat with Linux and are fully supported by the Nvidia driver set including temp sensing etc. On Friday 17 Dec 2004 23:36, Curtis L. Olson wrote: > I hope this isn't too off topic ... > > I am involved with a project where we are going to setup a multi-channel > visual system running flightgear. (3 PC's, 3 monitors.) We can budget > about $150-200 for the graphics cards, but the landscape has changed so > much since I last shopped I'm not sure what to do. We are committed to > buying something nvidia/GeForce based. The new 6800 cards are still way > out of our price range. The 5900/5950 cards are probably a bit high > right now too. But I see there area 5200's, 5500's, 5700's. and you can > still find the older ti4600/4800 cards floating around too. I know that > some of these varients were designed more as low end/cheap consumer > cards, and I'd like to get something with the best > capability/performance I can within our budget. Does anyone have any > recommendations? > > Thanks, > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Video card recommendations
I hope this isn't too off topic ... I am involved with a project where we are going to setup a multi-channel visual system running flightgear. (3 PC's, 3 monitors.) We can budget about $150-200 for the graphics cards, but the landscape has changed so much since I last shopped I'm not sure what to do. We are committed to buying something nvidia/GeForce based. The new 6800 cards are still way out of our price range. The 5900/5950 cards are probably a bit high right now too. But I see there area 5200's, 5500's, 5700's. and you can still find the older ti4600/4800 cards floating around too. I know that some of these varients were designed more as low end/cheap consumer cards, and I'd like to get something with the best capability/performance I can within our budget. Does anyone have any recommendations? Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 22:59:35 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: Lee Elliott wrote > > [snip...] > > How do FDMs handle Fowler flaps? i.e. the first part of the > action extends the flap rearwards without any rotation, acting > only to increase wing area, then for the rest of the action > rotate downwards? > > Easy enough to 3d model with a normalized input: translation > then rotation. > > Just curious > > Vivian That's exactly one of the problems I'm trying to work out wioth the B-52. The flaps have only two settings - fully extended or fully retracted, and it took 60 sec for full traversal. IIRC, the first 60%, or so, just increases the wing area, with the remainder changing the downwash. I've no idea what YASim is doing, as far as numbers go, but it seems to be behaving close according to anecdotal evidence. Probably what we'd do for JSBSim if we were going to model this is to figure out the aero coefficient increments due to flap extension to specified points (perhaps pseudo "degrees" or in a range from 0 to 1). We might do this using DATCOM+, or using standard equations. Then we'd use a kinematic component to introduce the effects at runtime. For the next version of JSBSim we might even introduce the effects using equations, specified in the config file. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Friday 17 Dec 2004 22:27, David Megginson wrote: > Totally up to you, but my 172P POH is for the 1981 model As it happens I did a bit more research and discovered that the in-wing (landing+taxi) lights were a factory option to the end of the P's production run. So no clues there ;) However, I also discovered that the early 172s had more dihedral and a slightly different shape to the aerofoil. Comparing this the FG 172P, which has little dihedral. It looks like 'our' one is a fairly-late 172P. So, because of the panel switch for 'taxi' lights, I'm going to *try* to do the in-wing lamps without spending too many polys. (Failing that, the switch can always come out). In a productive day (today) I have: Slightly changed the nose area shape to match sillouette Slightly increased the spinner diameter and slightly shortened it. Move the outer ends of the struts inboard to the point where the taper starts. Moved the pitot tube about .5m inboard. Slightly changed the shape of the rear-screen (more rounded). Made the tail light (white) move with the rudder. Moved the lower intake (texture) Joined the maingear to the fusealage (there was a significant gap before) Reduced the size of the nosewheel tyre. Remodelled the nose strut a little. Fitted a static Oleo guide to the nose-leg (IIRC they don't rotate with the nosewheel). Made the nosewheel rotate about its own shaft (And I've been patting meself on the back all day over that ;) ) Modified the dash-shroud so it no longer protrudes outside thru the windscreen Move the VHF aerials aft to their usual position. Its not neccesarily looking that much nicer but it is more accurate now :). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Lee Elliott wrote > > > [snip...] > > > > How do FDMs handle Fowler flaps? i.e. the first part of the > > action extends the flap rearwards without any rotation, acting > > only to increase wing area, then for the rest of the action > > rotate downwards? > > > > Easy enough to 3d model with a normalized input: translation > > then rotation. > > > > Just curious > > > > Vivian > > That's exactly one of the problems I'm trying to work out wioth > the B-52. The flaps have only two settings - fully extended or > fully retracted, and it took 60 sec for full traversal. IIRC, > the first 60%, or so, just increases the wing area, with the > remainder changing the downwash. I've no idea what YASim is > doing, as far as numbers go, but it seems to be behaving close > according to anecdotal evidence. > > Perhaps flight control surfaces should be defined in terms of the > change to chord and incidence but then how do you get the data? > Andy Ross will be able to explain in detail, but as I understand it YASim handles all kinds of flaps the same. The lift and drag increase is specified in the config file, then YASIM applies a proportion of both according to how far the flap is extended. I haven't investigated the function which is applied. It might be linear, or some other. I'm not sure if lift and drag are treated equally. Given how little we know about the real numbers for the likes of the B52, I guess that's good enough. I suppose that, in fdm terms, you could regard Fowler flaps as 2 separate flaps. In principle, some function, or functions could be applied which would cater for the first part of the movement, and then the second. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On Fri, 17 Dec 2004 20:38:33 +, Dave Martin <[EMAIL PROTECTED]> wrote: > Just wondering if the C172P is supposed to represent a specific model year? Totally up to you, but my 172P POH is for the 1981 model, for what that's worth. I cannot even remember the light positions on the planes I trained on; in any case, it's worth noting that many owners have moved the lights around over the years (some people like to install wingtip landing lights so that they look like a jet coming in). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Friday 17 December 2004 21:51, Vivian Meazza wrote: > Lee Elliott wrote: > > On Thursday 16 December 2004 21:17, Jon S Berndt wrote: > > [snip...] > > > > > Also, ask yourself the question, does the normalized value > > > of, say, 0.5 really correspond to 30 degrees of flaps when > > > the total range is 0 to 60? > > > > Are you not assuming a linear transition here? It doesn't > > have to be. > > How do FDMs handle Fowler flaps? i.e. the first part of the > action extends the flap rearwards without any rotation, acting > only to increase wing area, then for the rest of the action > rotate downwards? > > Easy enough to 3d model with a normalized input: translation > then rotation. > > Just curious > > Vivian That's exactly one of the problems I'm trying to work out wioth the B-52. The flaps have only two settings - fully extended or fully retracted, and it took 60 sec for full traversal. IIRC, the first 60%, or so, just increases the wing area, with the remainder changing the downwash. I've no idea what YASim is doing, as far as numbers go, but it seems to be behaving close according to anecdotal evidence. Perhaps flight control surfaces should be defined in terms of the change to chord and incidence but then how do you get the data? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 21:51:56 - "Vivian Meazza" <[EMAIL PROTECTED]> wrote: How do FDMs handle Fowler flaps? i.e. the first part of the action extends the flap rearwards without any rotation, acting only to increase wing area, then for the rest of the action rotate downwards? Easy enough to 3d model with a normalized input: translation then rotation. Now that's a good example. I'd have to think about it a bit. I don't have an answer on that one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear Mac OS X Application Bundle Available
I have built an application bundle of FlightGear for Mac OS X. It's a rather large application because it includes everything such as the base data, fgfs, etc. Compressed it's a total of 132 MB. I have no place to host such large files so I've made it available via BitTorrent. I've attached it to this email. Hopefully we can get some more people seeding. Now it would be really nice if you could switch aircraft from in the simulator! :) -- FlightGear-0.9.6+.dmg.torrent Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Lee Elliott wrote: > > On Thursday 16 December 2004 21:17, Jon S Berndt wrote: > [snip...] > > > > Also, ask yourself the question, does the normalized value of, > > say, 0.5 really correspond to 30 degrees of flaps when the > > total range is 0 to 60? > > > > Are you not assuming a linear transition here? It doesn't have > to be. > How do FDMs handle Fowler flaps? i.e. the first part of the action extends the flap rearwards without any rotation, acting only to increase wing area, then for the rest of the action rotate downwards? Easy enough to 3d model with a normalized input: translation then rotation. Just curious Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Thomas Foerster wrote: > So giving the user a choice is probably the best way to go, i.e. using a > QT-based one on Linux, a native Windows GUI on Windows, no GUI at all in a > real simulator setting. This is the same sort of idea I had been toying with. As a newbie to fg I felt that one tool that would be very handy would be a form of Linux QT FG-launcher. It would simply generate the appropriate config file from the users selections (--aircraft etc) and then launch fg with the newly generated config. This could make fgfs suddenly more approachable to new users. > Think I'll try to prototype something this weekend. I'd be very interested in having a look at it once you get one going. I am at an early stage with QT but thought a fg frontend that would be a great way to learn. I had envisioned a tabbed widget setup where loading of different tabsets could be facilitated via links in a contents pane e.g. on the right. The different tabsets might include a document browser, aircraft browser, flight creator etc. Having a QT implementation would make it a separate entity, nicely modular and split off from the fgfs core. It would naturally be a "take it or leave it" deal. It may even be possible to modify fg envirnoment parameters in realtime which would open up the possibility of an instructor's station module Really sky's the limit. Also as far as windows licensing is concerned: From Trolltech's website: "Please note that if you make the source code for your project available and your license allows it, any holder of a commercial Qt Windows license can create binaries for your project." Thus a GPL'd QT GUI could be made available for windows users. We would just need to find a QT commercial windows customer who'd be willing to generate binaries. These could then be distributed with source code for windows users. Note also that Mac users/coders can use it or contribute to it since it is only the windows version that is not available as open source. (I'm not a licensing lawyer, but that is how I understand Trolltech's Licensing FAQ) Cheers Rich ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 22:08, Gordan Sikic wrote: [snip...] > > (about F16) > AFAIK, it has nonmoving joystick, and force transducers, and > it is "normal" for that plane to ise output from the > transduced as a input. > The original HOTAS non-moving sticks in the development a/c were changed to have a very small amount of movement in the early production a/c. I don't know if they then started using non-moving sticks again in later versions though. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 21:17, Jon S Berndt wrote: [snip...] > > Also, ask yourself the question, does the normalized value of, > say, 0.5 really correspond to 30 degrees of flaps when the > total range is 0 to 60? > Are you not assuming a linear transition here? It doesn't have to be. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
Dave Martin wrote: Just wondering if the C172P is supposed to represent a specific model year? I've come to the point of placing a landing light on the aircraft but the location is different between early 172s; in the wing with a taxi light and late 172Ps (early 80's) where it is located in the nose with no taxi light. I did notice that there is a 'taxi light' switch but which way do you think I should go? Hi Dave, In the absence of anyone with a strong opinion, I think consistency is the most important thing to focus on. In an open source project it's generally it's the people doing the work that get to make the big decisions, so if no one writes back with a compelling argument either way, go with what you think is best. Once you pick a year or a model, try your best to keep everything consistent for that year. Best regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] C172P Model Year?
Just wondering if the C172P is supposed to represent a specific model year? I've come to the point of placing a landing light on the aircraft but the location is different between early 172s; in the wing with a taxi light and late 172Ps (early 80's) where it is located in the nose with no taxi light. I did notice that there is a 'taxi light' switch but which way do you think I should go? Thanks. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Next error
Hi, back to main.cxx at line #759 in fgMainInit(...) main.cxx:759: assuming & on overloaded member function Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
On Fri, 17 Dec 2004 11:35:24 -0800 John Wojnaroski <[EMAIL PROTECTED]> wrote: That was it. The other modules explicitly call out the include directive and ifdef, but they appear to be excluded in the JSBSim files ? seems like something is missing/mis-set on my system , if others are not having this problem. At any rate, adding it in for the complaining files will work for the interim Thanks John W. Thanks for pointing this out, and thanks to Norman for pointing out the fix. It looks like this was inadvertently removed at some point - probably by me. We need to work on eliminating the need for the snprintf function if it's not portable. Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
That was it. The other modules explicitly call out the include directive and ifdef, but they appear to be excluded in the JSBSim files ? seems like something is missing/mis-set on my system , if others are not having this problem. At any rate, adding it in for the complaining files will work for the interim Thanks John W. Norman Vine wrote: #include #if defined(WIN32) && !defined(__CYGWIN__) #define snprintf _snprintf #endif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Wojnaroski Sent: Friday, December 17, 2004 11:33 AM To: FlightGear developers discussions Subject: [Flightgear-devel] CVS Error? Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear not compatible with autoconf 1.57
I just checked out the latest source from CVS and ran autogen.sh. Then when trying to run configure I got the following error: configure: error: cannot run /bin/sh ./config.sub After upgrading to autoconf 1.59 there were some warnings when running autogen.sh but at least configure works. I'm pretty sure it's version 1.57 or 1.56 of autoconf that had this problem. -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
I disagree. It is easy to say what is natural, but hard to show it. After someone has been flying for a while it sure feels natural. But when I have a new student I find that very often they "over control" the aircraft. I can get them to quite down by convincing them to "just use pressure". Maybe we are just arguing semantics, but I think that it is learned, not "natural." -- Adam > From: Gordan Sikic <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > Date: Fri, 17 Dec 2004 09:22:17 +0100 > To: FlightGear developers discussions <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] control surface normalization > > Hi, > >> Pilots are taught to think in terms of pressure on stick not displacement. >> That is part of the reason that the F-16 is built the way it is. >> > > Thats OK, I agree, with one small change: > pilots are not *taught* to think in terms in terms of pressure on stick. > It is the natural way of "sensing the aircraft". > > cheers, > Gordan > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
On Fri, 17 Dec 2004 10:49:56 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > I believe Erik just synced the flightgear tree up with the latest JSBsim > > cvs, so there could be some portability issue that has crept in. I > haven't had a chance to compile the latest cvs commits myself. It's definitely not generic: I just synced to CVS and built on linux with no problem at all. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpLNwupCPY2F.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 10:05:04 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: The FDM may choose to carry along with that abstraction (which makes sense) because you are concerned with getting the right performance when the lever is in the 30 degree position. It all works out in the end, but saying the flaps are at 30 degrees is an extreme over simplification. Yes, this is true. You're right, too, that we don't care about the _visual_ position of the flaps, but what the flaps have been commanded to and what aerodynamic properties result from that setting. But at least we have that. Saying we are at 30 degrees flaps in a range from 0 to 60 may not be concrete, but it beats simply saying that the flap setting is 0.5. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS Error?
#include #if defined(WIN32) && !defined(__CYGWIN__) #define snprintf _snprintf #endif > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of John > Wojnaroski > Sent: Friday, December 17, 2004 11:33 AM > To: FlightGear developers discussions > Subject: [Flightgear-devel] CVS Error? > > > Hi, > > I may have posted this late last night, but seems to have been lost. If > a duplicate post, my apologies > > Compiling the CVS pre-release > > error in FGNozzle.cxx complaining about snprintf as implicit declaration > at line #74 > > Currently running 0.9.5 > > Did I miss something skipping over 0.9.6? > > Regards > JW > > > > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 10:07:47 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: Jon, the problem is: how does the interface know how to normalize the control surface positions? Where does it read the maximum limits from? The FDM is really the only piece that is going to know this information. This is **exactly** one of the big concerns I have. But, it cuts both ways. Using normalized position, NIETHER the FDM NOR the animation system knows where to place the elevator, for instance, unless two pieces of information are present. This is what I've been trying to illustrate for some time. For aerosurfaces, an absolute measurement makes sense (such as degrees or radians) for most aerosurfaces because it uniquely determines orientation. It is true that the FDM usually knows what the phyisical limits are for an aerosurface, but if we normalize the elevator or rudder setting we cannot simply pass the normalized value, we have to pass the limit as well. And I'm not prepared to continue to do this in the FDM proper. The presence of all the special purpose normalization routines is really confusing. Whatever is done will have to be done in the interface. Additionally, what on earth are the animators using to turn normalized values into degrees, now? JSBSim is certainly not now passing in limit information. I suppose JSBSim defines one set of limits and - hopefully - the 3D modelers are using the same value. But, what if the limits are changed in the flight model? One thing we could do is to simply define a NORMAL_FACTOR that corresponds to a constant, say 30 degrees. Then always normalize in the interface w.r.t. that. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
John Wojnaroski wrote: Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? I believe Erik just synced the flightgear tree up with the latest JSBsim cvs, so there could be some portability issue that has crept in. I haven't had a chance to compile the latest cvs commits myself. With these sorts of errors I would do a "man snprintf" on your system. See what #includes the man page suggests. Add those to the offending file. Most likely the proper includes are not there. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS Error?
Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, in this case, I appears that I did not consider all the needs of the animation system. Neither one should have to be designed to make up for something the other doesn't do. So I think the best thing to do, as we've hit on before, is to have the interface do the translation. That's where the discussion should probably head. Jon, the problem is: how does the interface know how to normalize the control surface positions? Where does it read the maximum limits from? The FDM is really the only piece that is going to know this information. I propose that you continue to output normalized values, but in addition, output degrees. Your FCS can choose to work with the degree numbers, and the animators can choose to use which ever number/units are most appropriate and convenient for their purposes. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: No, the FDM doesn't care about anything but commanded flap position - which will be taken to actual position through the FCS, but with JSBSim actuator dynamics are not required to be modeled. Commanded and actual positions are in degrees. As I said before, does 30 degrees flaps (when the maximum travel is 60) corespond to an actuator extension of 0.5? Probably not. Does it matter for animation purposes? Probably not, I guess. Jon, The question I have is when the pilot selects "30 degrees flap" in the cockpit, for an aircraft with a complex multi-part flap mechansim ... are they really getting 30 degrees? Where is this measured, relative to what? How does this relate to how much the pieces extend as they rotate? For many aircraft, "flap degrees" is an abstraction already, and doesn't really correspond directly or linearly to actual measurable degrees. The FDM may choose to carry along with that abstraction (which makes sense) because you are concerned with getting the right performance when the lever is in the 30 degree position. It all works out in the end, but saying the flaps are at 30 degrees is an extreme over simplification. I do think you are trying to make some valid points here in this thread, but I don't think that using flaps as an example advances your argument. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 15:26:26 +0100 Gordan Sikic <[EMAIL PROTECTED]> wrote: Hi Jon, Once more, do not make general statements, based on a few examples. Jon wrote: One hundred percent of the control law diagrams ... I have seen that include pilot inputs use force. There are _many_ FCS's out there, not using input you just described. Fore examples, take a look at the "Flight control and simulation", the book with examples that are completely based on F16 dynamics. Steven's and Lewis? F-16? I don't know what Steven's and Lewis are saying (I'll take a look later today), but I *am* referring to the F-16 as _one_ example, and I was referring to the manufacturer's (General Dynamics) FCS diagrams, not a textbook interpretation. The manufacturer's diagrams show stick force as input. I don't mean to say that this is necessarily a standard, or that it is always this way, or even usually this way, but it makes sense and is easy to work with. Can you give an example of an alternative approach? I am curious. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GUI Improvements was: Things to do to improveFlightgear
On Friday 17 December 2004 14:50, Norman Vine wrote: > Matthew Law writes: > > Personally, I'd prefer to see a nice OpenGL based GUI like some of the > > other simulators and, dare I say it, games. With this method you can > > throw out native look and feel and just have a very nice looking > > functional user interface that works on any platform with OpenGL > > support. > > PUI < PLIB's GUI > can make much nicer looking interfaces then what > is currently done in FGFS. Interesting, could you show us an example screenshot of a game that uses PUI in this way? > Several commercial games use it for their GUI jsut for the reasons > you described including at least one EA title What commercial games use PUI? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi Jon, output laterally, on the pedals, and front/back on the stick. I think that's why the control law diagrams I have seen use pilot stick force as the input unit. One hundred percent of the control law diagrams I have seen that include pilot inputs use force. Once more, do not make general statements, based on a few examples. There are _many_ FCS's out there, not using input you just described. Fore examples, take a look at the "Flight control and simulation", the book with examples that are completely based on F16 dynamics. cheers, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Jon Berndt writes: > > Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, > in this > case, I appears that I did not consider all the needs of the animation > system. Neither one > should have to be designed to make up for something the other doesn't do. So > I think the > best thing to do, as we've hit on before, is to have the interface do the > translation. > That's where the discussion should probably head. As was suggested *very* early on in this thread :-) being-right-like-beauty-is-in-the-eyes-of-the-beholder'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 07:32:04 -0600, Jon wrote in message <[EMAIL PROTECTED]>: > On Behalf Of Arnt Karlsen > > > On Fri, 17 Dec 2004 09:22:17 +0100, Gordan wrote in message > > <[EMAIL PROTECTED]>: > > > > > Hi, > > > > > > > Pilots are taught to think in terms of pressure on stick not > > > > displacement. That is part of the reason that the F-16 is built > > > > the way it is. > > > > ..this used to be the doctrine in at least the 1980'ies in the > > RNoAF. > > > > > Thats OK, I agree, with one small change: > > > pilots are not *taught* to think in terms in terms of pressure on > > > stick. It is the natural way of "sensing the aircraft". > > > > ..this is the saner approach. ;-) > > When it comes down to it, there is only a voltage, or a resistance, in > a fly-by-wire system, at least. The FCS computer doesn't really care > what it gets. But it has to know the relationship between what the > pilot is saying and the voltage it is seeing. In some cases the stick > doesn't simply control elevator motion (for example), it commands a > pitch rate, or a normal force, or whatever. The one thing the pilot > can output to the stick - the single thing - is a force on it. There > are standards that state what a pilot can output laterally, on the > pedals, and front/back on the stick. I think that's why the control > law diagrams I have seen use pilot stick force as the input unit. One > hundred percent of the control law diagrams I have seen that include > pilot inputs use force. ..true, in *AF environments you also train people to deal with it, even after combat damage, and there you need these people to _act_ and _act_right_, rather than die figuring out control laws, hence the "sane shortcuts". ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Boy, do I enjoy a vigorous debate, especially when I am right. Unfortunately, in this case, I appears that I did not consider all the needs of the animation system. Neither one should have to be designed to make up for something the other doesn't do. So I think the best thing to do, as we've hit on before, is to have the interface do the translation. That's where the discussion should probably head. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Jon Berndt wrote: > good chance > > that you're not going to get exactly 30 degrees flaps. The actuator > > mechnism probably > > won't linearly extend the flaps due to the compound nature of the flap > > mechanisms. > > If that is the case the FDM should know about it more than anything else > IMHO. > > Erik No, the FDM doesn't care about anything but commanded flap position - which will be taken to actual position through the FCS, but with JSBSim actuator dynamics are not required to be modeled. Commanded and actual positions are in degrees. As I said before, does 30 degrees flaps (when the maximum travel is 60) corespond to an actuator extension of 0.5? Probably not. Does it matter for animation purposes? Probably not, I guess. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] GUI Improvements was: Things to do to improveFlightgear
Matthew Law writes: > > Personally, I'd prefer to see a nice OpenGL based GUI like some of the > other simulators and, dare I say it, games. With this method you can > throw out native look and feel and just have a very nice looking > functional user interface that works on any platform with OpenGL > support. PUI < PLIB's GUI > can make much nicer looking interfaces then what is currently done in FGFS. Several commercial games use it for their GUI jsut for the reasons you described including at least one EA title Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? It should be, if the FDM does it's thing right. Erik Not so fast. Aero tables might be indexed for flaps based on angle. If the flaps are commanded to 30 degrees the aero force and moment will be calculated based on that. What I was getting at is this: if the flap actuator extends fifty percent, there's a good chance that you're not going to get exactly 30 degrees flaps. The actuator mechnism probably won't linearly extend the flaps due to the compound nature of the flap mechanisms. If that is the case the FDM should know about it more than anything else IMHO. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Curtis L. Olson wrote: > > It doesn't probably matter too much for 3d animation if your conversion > > factor get's you close. > > There is another thing, all doors, struts and support bars are animated > based on the gear extension. While the main gear extension might be > perfectly valid in degrees, converting supports struts/bars will be a > whole lot more complicated. Like I mentioned before, landing gear extension is fine as a "0 to 1" parameter. Elevator, rudder, speedbrake, spoilers, etc. in angular measurements. Now, *IF* we are to normalize these angular parameters in the FGInterface class, WHAT is the non-dimensionalizing procedure? How do we non-dimensionalize with any degree of accuracy and compatibility? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> > Also, ask yourself the question, does the normalized value of, say, 0.5 > > really correspond to 30 degrees of flaps when the total range is 0 to 60? > > It should be, if the FDM does it's thing right. > > Erik Not so fast. Aero tables might be indexed for flaps based on angle. If the flaps are commanded to 30 degrees the aero force and moment will be calculated based on that. What I was getting at is this: if the flap actuator extends fifty percent, there's a good chance that you're not going to get exactly 30 degrees flaps. The actuator mechnism probably won't linearly extend the flaps due to the compound nature of the flap mechanisms. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon Berndt wrote: (And If you don't believe me, start to work on the gear animations of the Fokker-50 in degrees (0 - 90 degrees). If you manage to get that working we could start talking again). I think this illustrates the futility of trying to use a one-size-fits-all animation strategy. It tries to be everything to everyone and ends up completely pleasing no one. Oh, I like the normalized values. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
On Behalf Of Arnt Karlsen > On Fri, 17 Dec 2004 09:22:17 +0100, Gordan wrote in message > <[EMAIL PROTECTED]>: > > > Hi, > > > > > Pilots are taught to think in terms of pressure on stick not > > > displacement. That is part of the reason that the F-16 is built the > > > way it is. > > ..this used to be the doctrine in at least the 1980'ies in the RNoAF. > > > Thats OK, I agree, with one small change: > > pilots are not *taught* to think in terms in terms of pressure on > > stick. It is the natural way of "sensing the aircraft". > > ..this is the saner approach. ;-) When it comes down to it, there is only a voltage, or a resistance, in a fly-by-wire system, at least. The FCS computer doesn't really care what it gets. But it has to know the relationship between what the pilot is saying and the voltage it is seeing. In some cases the stick doesn't simply control elevator motion (for example), it commands a pitch rate, or a normal force, or whatever. The one thing the pilot can output to the stick - the single thing - is a force on it. There are standards that state what a pilot can output laterally, on the pedals, and front/back on the stick. I think that's why the control law diagrams I have seen use pilot stick force as the input unit. One hundred percent of the control law diagrams I have seen that include pilot inputs use force. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
> Curtis L. Olson wrote: > > Erik Hofman wrote: > > > >>> Personally, I would be in favor of using angles to describe the > >>> positions of left/right aileron, elevator, rudder and nose/tail wheel. > >> > >> Please, not for the wheels. Really. > > > > It doesn't probably matter too much for 3d animation if your conversion > > factor get's you close. > > There is another thing, all doors, struts and support bars are animated > based on the gear extension. While the main gear extension might be > perfectly valid in degrees, converting supports struts/bars will be a > whole lot more complicated. > > (And If you don't believe me, start to work on the gear animations of > the Fokker-50 in degrees (0 - 90 degrees). If you manage to get that > working we could start talking again). > > Erik I think this illustrates the futility of trying to use a one-size-fits-all animation strategy. It tries to be everything to everyone and ends up completely pleasing no one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GUI Improvements was: Things to do to improve Flightgear
* Thomas Frster <[EMAIL PROTECTED]> [2004-12-17 10:20]: > So giving the user a choice is probably the best way to go, i.e. using a > QT-based one on Linux, a native Windows GUI on Windows, no GUI at all in a > real simulator setting. IMHO, there would be just as much work involved in creating a native user interface for each platform (Remember there are many, many variations on platform and toolkit that FG runs on...). The one strength of PUI is that it is GL based. If flightgear is running, it's safe to say that the user has OpenGL :-) Personally, I'd prefer to see a nice OpenGL based GUI like some of the other simulators and, dare I say it, games. With this method you can throw out native look and feel and just have a very nice looking functional user interface that works on any platform with OpenGL support. All the best, Matthew. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Fri, 17 Dec 2004 09:22:17 +0100, Gordan wrote in message <[EMAIL PROTECTED]>: > Hi, > > > Pilots are taught to think in terms of pressure on stick not > > displacement. That is part of the reason that the F-16 is built the > > way it is. ..this used to be the doctrine in at least the 1980'ies in the RNoAF. > Thats OK, I agree, with one small change: > pilots are not *taught* to think in terms in terms of pressure on > stick. It is the natural way of "sensing the aircraft". ..this is the saner approach. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] GUI Improvements was: Things to do to improve Flightgear
Am Donnerstag 16 Dezember 2004 18:45 schrieb Christian Mayer: > ...[other GUIs besides PUI > > Well, I don't think that replacing PUI has a high priority. Thats probably right. > I doesn't look that bad (but doesn't mirror the OS style). And it get's > drawn by OpenGL with a low overhead. > > So we should improve the underlaying functionality first, bevore we > consider exchanging PUI. I see it as an opportunity for me to step in, because GUI code should be fairly trivial, i.e. independent of domain knowledge. > ...[multiple fg guis]... > This sounds like unlimited resources where you can afford the luxurity > to code a GNOME, as Qt, a Windows, a MacOS, a [...] interface... This was just the vision. The actual steps to get there might differ :-) But these toolkits provide more or less the same functionality, so translating the FG GUI to any one of them should be straight forward. I can help out with QT, maybe there are others who can do that for a GTK based solution, etc. > A Qt only interface sounds good - but Qt isn't free for Windows (you'll > only get an 30 day evaluation copy IIRC), so we can't use it :( That's the point why I opt for having multiple GUI implementations. I can't use the native Windows solution here on Linux, with QT it's the other way round. Most of the cross platform available toolkits are either ugly or hard to develop with. Going for an own GUI toolkit for plib is even more demanding. So giving the user a choice is probably the best way to go, i.e. using a QT-based one on Linux, a native Windows GUI on Windows, no GUI at all in a real simulator setting. Think I'll try to prototype something this weekend. Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PATCH: two changes to data/Aircraft/737/Instruments/pfd2.xml
Chris Metzler wrote: The first: In going from version 1.3 to 1.4, Melchior Franz noted that there was no /velocities/vertical-speed-fpm property to display, and changed the property referenced to /velocities/vertical-speed-fps, which does exist. But the display should show fpm; so a parameter is inserted to make what's displayed feet-per-minute. The second: In going from version 1.1 to 1.2, properties with '[0]' indices had the '[0]' dropped. But for some reason, a reference to property dme/indicated-distance-nm[0] got changed to dme/distance-nm. In other words, not only did [0] get dropped, but 'indicated-' got dropped from the property name. This broke DME on the 737 -- there is no 'dme/distance-nm' property. This patch fixes it back. Thanks Chris, this has been committed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon S Berndt wrote: On Thu, 16 Dec 2004 20:47:03 - "Jim Wilson" wrote: It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? It should be, if the FDM does it's thing right. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jim Wilson wrote: This is just what was going through my mind when reading this discussion. Jon's concern is quite valid, but there are problems. As I work through these concepts in my mind, I can see that although the current method sounds more complicated for the 3D animator, having to deal with the real values could be a lot worse (at least with the current architecture). It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. I second this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Curtis L. Olson wrote: Erik Hofman wrote: Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. Please, not for the wheels. Really. It doesn't probably matter too much for 3d animation if your conversion factor get's you close. There is another thing, all doors, struts and support bars are animated based on the gear extension. While the main gear extension might be perfectly valid in degrees, converting supports struts/bars will be a whole lot more complicated. (And If you don't believe me, start to work on the gear animations of the Fokker-50 in degrees (0 - 90 degrees). If you manage to get that working we could start talking again). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi, Pilots are taught to think in terms of pressure on stick not displacement. That is part of the reason that the F-16 is built the way it is. Thats OK, I agree, with one small change: pilots are not *taught* to think in terms in terms of pressure on stick. It is the natural way of "sensing the aircraft". cheers, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
