Re: [Flightgear-devel] Please remove 727-230 from CVS- Licence issues!
How about the tail texture? $ find | grep Cruz ./Models/727-230_Cruzeiro.png,v ./Models/Liveries/Cruzeiro.xml,v ./Models/727-230.tail_Cruzeiro.png,v $ find | grep Lufth ./Models/727-230_Lufthansa.png,v ./Models/727-230.tail_Lufthansa.png,v ./Models/Liveries/Lufthansa.xml,v Thanks, Curt. On Sat, Jan 23, 2010 at 3:43 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Hi, I need a file name. 727-230_Cruzeiro.png 727-230_Lufthansa.png Thanks! CGTextures.com stated on my advice now clearly that OpenSource can't use their textures. This wasn't clear enough before as several other OpenSource Projects told me. __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please remove 727-230 from CVS- Licence issues!
Please, because we are discussing permanent removal of something from the repository, I need a very clear list of exactly what needs to be removed. I found 2 additional textures (png files) with similar names to the textures you requested be removed. I asked about these. Your answer indicated that these two textures do not make use of textures which doesn't quite make sense. If you could give me an exact list of path + filename for each file you would like to see removed I can do this. I hate to guess or assume or have to string dots together to arrive at [hopefully] the right answer. Thank you in advance, Curt. On Sat, Jan 23, 2010 at 4:19 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Hi, How about the tail texture? $ find | grep Cruz./Models/727-230_Cruzeiro.png,v./Models/Liveries/Cruzeiro.xml,v./Models/727-230.tail_Cruzeiro.png,v $ find | grep Lufth./Models/727-230_Lufthansa.png,v./Models/727-230.tail_Lufthansa.png,v./Models/Liveries/Lufthansa.xml,v Thanks, Curt. They don't make use of the textures, but why not. Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please remove 727-230 from CVS- Licence issues!
Ok, thanks, just wanted to be sure. These two files are now gone. Curt. On Sat, Jan 23, 2010 at 6:28 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Please, because we are discussing permanent removal of something from the repository, I need a very clear list of exactly what needs to be removed. I found 2 additional textures (png files) with similar names to the textures you requested be removed. I asked about these. Your answer indicated that these two textures do not make use of textures which doesn't quite make sense. If you could give me an exact list of path + filename for each file you would like to see removed I can do this. I hate to guess or assume or have to string dots together to arrive at [hopefully] the right answer. Thank you in advance, Curt. Curt, I used for some parts of a not-allowed texture unknown to me for the .png-files Only the fuselage-texture were affected. I thought it was clear. To be clear: Please remove data/Aircraft/727-230/Models/727-230_Lufthansa.png data/Aircraft/727-230/Models/727-230_Cruzeiro.png as they are only affected. Sorry for the inconvience __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/santa/Models/Effects stardust.xml, NONE, 1.1
Erik, we may need to discuss Santa theology on the developers list here. Are you just making this stuff up? :-) Curt. On Sat, Jan 16, 2010 at 8:37 AM, Erik Hofman ehof...@baron.flightgear.orgwrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/santa/Models/Effects In directory baron.flightgear.org:/tmp/cvs-serv28936/santa/Models/Effects Added Files: stardust.xml Log Message: add effects --- NEW FILE stardust.xml --- ?xml version=1.0? PropertyList particlesystem namestardust/name texturestar.png/texture emissivetrue/emissive lightingfalse/lighting offsets x-m0/x-m y-m0/y-m z-m0/z-m /offsets condition greater-than-equals propertyvelocities/airspeed-kt/property value10/value /greater-than-equals /condition attachworld/attach placer typepoint/type /placer shooter theta-min-deg-5/theta-min-deg theta-max-deg5/theta-max-deg phi-min-deg-5/phi-min-deg phi-max-deg5/phi-max-deg speed-mps value0/value spread0/spread /speed-mps rotation-speed x-min-deg-sec5/x-min-deg-sec y-min-deg-sec5/y-min-deg-sec z-min-deg-sec5/z-min-deg-sec x-max-deg-sec10/x-max-deg-sec y-max-deg-sec10/y-max-deg-sec z-max-deg-sec10/z-max-deg-sec /rotation-speed /shooter counter particles-per-sec propertyvelocities/airspeed-kt/property factor0.1/factor spread1/spread /particles-per-sec /counter alignbillboard/align particle start color red value0.6/value /red green value0.8/value /green blue value1/value /blue alpha value0.12/value /alpha /color size value0.8/value /size /start end color red value0.6/value /red green value0.8/value /green blue value1/value /blue alpha value0.008/value /alpha /color size value8/value /size /end life-sec value5.0/value /life-sec mass-kg0.1/mass-kg radius-m0.015/radius-m /particle program fluidair/fluid gravity type=boolfalse/gravity wind type=booltrue/wind /program /particlesystem /PropertyList -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-cvslogs mailing list flightgear-cvsl...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-cvslogs -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --disable-sound
James, for whatever it's worth, I have a machine here that I upgraded from Fedora 10 - 11 and then from Fedora 11 to Fedora 12 and sound was a nightmare and never worked right or at all with FlightGear after those upgrades. Then I finally blew everything away and installed Fedora 12 from scratch. It turns out (my best interpretation anyway) that the earlier version of Fedora used some random snapshot of openal. At some point Fedora switched over to openal-soft, but the upgrade never installed openal-soft because the package name is different and at least in this case, it just did it's best to find a newer version of the existing packages. So I had an old crappy openal on my system which didn't seem to work right or at all with FlightGear and Fedora 12. This got sorted out properly with a fresh install. Now going back I could have probably just removed the old openal, installed openal-soft and probably been happy, but it's too late for me to try that now. Regards, Curt. On Sat, Jan 9, 2010 at 3:31 AM, James Sleeman wrote: Is there a reason that --disable-sound doesn't totally disable sound? Is there a way to totally disable sound? --help --verbose doesn't give any further clue that I noticed. I am still having major problems getting FG to work with pulseaudio (and I don't want to (nor really can) kill off pulseaudio). In summary: Sometimes everything is perfect with the c172, sometimes it hangs before the splash screen goes away, there is no rhyme nor reason, I suspect there is a race condition of some description. I don't think I've successfully got any other aircraft to work, they always hang before the splash goes away, again probably a race condition I suspect which other aircraft trigger more readily than the 172. Even with --disable-sound, we get the same hang, the backtrace of which follows, so I can't even fly soundless :-( Talk about frustrating, havn't been able to FG properly in ages, withdrawl symptoms! Here is a --disable-sound backtrace which shoes that it's still trying to use openal (and thus pulseaudio) even with no sound. Starting program: /usr/local/builds/fg-auto/install/fgfs/bin/fgfs --fg-root=/usr/local/builds/fg-auto/install/fgfs/bin/../data/ --aircraft=dc2 --disable-sound [Thread debugging using libthread_db enabled] [New Thread 0x7fffed970910 (LWP 5534)] ^C ### I broke in here after it has hung ### Program received signal SIGINT, Interrupt. pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261 261../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S Current language: auto The current source language is auto; currently asm. (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261 #1 0x7107642b in pa_threaded_mainloop_wait () from /usr/lib/libpulse.so.0 #2 0x75af12a9 in pulse_open (device=0xaf45d00, device_name=0x75af6cf0 PulseAudio Software) at /usr/local/builds/flightgear/openal-soft-1.10.622/Alc/pulseaudio.c:391 #3 0x75af2153 in pulse_open_playback (device=0xaf45d00, device_name=0x75af6cf0 PulseAudio Software) at /usr/local/builds/flightgear/openal-soft-1.10.622/Alc/pulseaudio.c:452 #4 0x75ad9200 in alcOpenDevice (deviceName=0x0) at /usr/local/builds/flightgear/openal-soft-1.10.622/Alc/ALc.c:1587 #5 0x008e3653 in SGSoundMgr::init (this=0xe11540, devname=value optimized out) at soundmgr_openal.cxx:105 #6 0x00448220 in fgInitSubsystems () at fg_init.cxx:1476 #7 0x0042ccb4 in fgIdleFunction () at main.cxx:774 #8 0x00477ac2 in fgOSMainLoop () at fg_os_osgviewer.cxx:172 #9 0x0042d509 in fgMainInit (argc=4, argv=0x7fffe7b8) at main.cxx:920 #10 0x0042b40e in main (argc=4, argv=0x7fffe7b8) at bootstrap.cxx:229 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon
Re: [Flightgear-devel] Laptop Recommentations
For what it's worth, I ended up with a refurb compaq (now hp?) presario laptop with nvidia graphics hardware. It has a dual 64-bit AMD processor and so far I have been really happy with it. Everything (sound, video, wireless network, etc.) is well supported under Linux. And it performs pretty decently. I got it from a place called MEI (Micro Center) which is a pretty interesting place if you have one in your town and haven't checked it out yet. For myself, the key thing is nvidia hardware. I can live without sound, and I can plug in an external wireless device if I have to, but for me, fast, solid 3d video (for FlightGear) is the most important factor. I should point out that with Fedora 12, working around the neauvou open-source video drivers which get hardwired in at a very low level was a trick to figure out. I actually needed to add a kernel boot parameter to disable them because they actually get pulled in at the start of the boot, before the kernel even loads I think so that the system can do fancy boot graphics ... looks pretty but then they prevent the real nvidia kernel module from loading/working later. Regards, Curt. On Fri, Jan 8, 2010 at 8:08 AM, Jon Stockill wrote: Stuart Buchanan wrote: Hi All, The graphics card on my FG PC has just died, and as the PC is now quite old and was already on it's second graphics card, I'm looking to buy a laptop to replace it with. Does anyone have a recommendation for laptops, or particular things I should look out for. So far, my requirements list is as follows: * 17 screen * NVidia graphics card (non-integrated) * Ubuntu support * Plenty of USB sockets for joystick/pedals. The HP Pavillion range is probably worth looking at - a lot of them appear to have nvidia 100 and 200 series graphics now. Jon -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Request to distribute Aircraft/ATC zip file
Hi Toshi,
I will update the script, thanks for noticing this. Originally this
exception was to avoid cluttering the aircraft download page with some
personal files, but then one of our developers created an aircraft called
ATC so I moved my own files to a new directory to avoid a conflict, but
never updated this script. It should be fixed now.
Best regards,
Curt.
On Tue, Jan 5, 2010 at 9:48 AM, YOSHIMATSU Toshihide
qzt04...@nifty.ne.jpwrote:
Hi Curt,
I sincerely hope that you distribute Aircraft/ATC zip file via ftp
mirrors in next release timing unless it causes some kind of problem.
At this time, I guess your local /admin/make-aircraft-pkgs.pl file
will prevent to generate ATC_mmdd.zip file.
/admin/make-aircraft-pkgs.pl:
if ( $dir eq ATC || $dir eq CVS || $dir eq c172x ) {
next;
Cheers,
Toshi
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards the new Release
On Tue, Jan 5, 2010 at 1:11 PM, Durk Talsma wrote: Hi Folks, Well, if some of you might have noticed, the release process is going somewhat slower than we had all hoped for I would just like to give a quick heads up though. First of all, there are two major reasons that are holding us back. 1) There are still a few bugs to be checked, in addition to investigating the possibilities of setting up a proper bug tracking system for FlightGear. Secondly, and as importantly, there is currently a considerable uncertainty with regards to the windows build. In the last couple of years, we've been able to distribute a very nice windows build, including a nice installer and a launcher, provided by Frederic Bouvier. Unfortunately, we've been unable to get a hold of Fred in recent months. I certainly hope that everything is okay with him, but in the mean time, we have to consider how to do a windows build. In particular, it would be very nice to have a similar version as what we had before. We have a very large windows users base, so I believe that this is important. So, I would like to explore some possibilities on how to do this. I have succesfully compiled FlightGear on windows in the past, but this was nowhere as advanced as the setup that Fred was able to provide. I know that a few people have experience in building on windows (Vivian Meazza, Olad Flebbe). So hopefully we can come up with a good windows equivalent. Hi Durk, For earlier releases I was involved in creating the windows install package. I think Fred just took my packaging script and updated the version number for the new version. I think I could get back up to speed on windows packaging pretty quickly. What I would need is a good clean efficient windows exe (noting that historically there has been some significant variation in performance and robustness in different windows exe's depending on the individual developers build system and various choices.) Fred always built a solid fast executable. The other piece I'm less familiar with is the fgrun front end launcher. But given good exe's for everything, I think I can package them up reasonably well into a nice windows setup.exe. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Committing conditional compile patch for ATCDCL
On Wed, Dec 23, 2009 at 1:53 AM, Durk Talsma d.tal...@xs4all.nl wrote: Hi All, As we've discussed before, I'm working on merging the old ATC/AI code from David Luff (ATCDCL) with our AIModels system. As part of the rewrite, I have added a new --disable-atcdcl option to my configure script. The default behavior is that ATCDCL will be enabled. Disabling the build of this library currently results in a broken compile, because the alternate code isn't ready yet. Since the default behavior doesn't really affect the compile process, I'm wondering whether there would be any objections to committing it to CVS. I'm asking, because I recently saw some patches being applied to ATCDCL, and I don't want my development tree to get out of sync too much. I don't see any obvious negative side effects, but this seems to my a case of better being safe than sorry. :-) Probably the biggest thing to worry about is if you introduce a new #define is the folks doing windows builds. Configure takes care of keeping everything consistent for unix builds, but depending on how this is done it could cause weird breakage for windows builds if the developers aren't aware they need to add a new define to their build environment. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic autopilot issues
On Tue, Dec 22, 2009 at 8:10 AM, James Turner wrote: What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. With the old route manager, the first way point is where I want to go for my first destination, because I just put it in there with that specific goal in mind. The 2nd waypoint is also where I want my second destination to be, again, because I just put it there. Same for all the other way points. Another nice feature we used to have in the original route manager was the ability to insert and delete waypoints from the middle of the route, allow us to update and change the route in mid-flight if we changed or mind (or something like weather changed it for us.) What I liked about the old route manager is I could decide I want to fly to A then B then C then D, I added those waypoints and off I go. I feel like I have to fight the new system to get it to do something like that, and then every time I open up the dialog box, I'm never sure if it's going to change the route on me or add the original airport back in again (even if it might already be there.) I haven't tried using the route manager in a few weeks now, so perhaps some of these things were bugs that are now resolved. I think there was a simplicity and a determinism in the original system (as unrealistic as that was) and I struggle with the new system trying to understand how to get it to work and not make unexpected changes or additions to the route. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. Ok, for the original route manager when you specified an airport as a waypoint, you got this computed center point (average or runway center points.) For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. Right ... I've always flown with the mindset of the route manager getting me to the airport and then at some point I'll break off the route and setup the approach to my own chosen runway and land manually. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS - autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? The alphajet has it's own autopilot configuration. I wouldn't characterize it as generic since it is specific for this aircraft. Perhaps some of the gains could be tweaked, but it behaves pretty well for me. One thing to note is that many YASim jet aircraft can be over speeded at lower altitudes and if you do that, you can get really weird negative stall type effects ... especially if you have flaps deployed. This has always been a gripe of mine with the YAsim flight dynamics engine. Generic autopilots are difficult. Different aircraft have wildly different systems and capabilities. Different types of sensors, actuators, etc. A generic autopilot would be about as realistic as our original route manager. :-) And then stuffing in about 50-60 tunable parameters into a generic structure also sounds pretty messy. I've always preferred the autopilot to be defined on a per-aircraft basis, and if the aircraft author wants to copy a config file from another similar aircraft as a starting point, that's fine. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 11:17 AM, James Turner wrote: For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. This would only have been the case if there were any pending waypoints in the route manager. If all waypoints had been reached, or no waypoints have been entered, then the 'old' route manager should not have touched the true-heading-target value. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 12:43 PM, James Turner zakal...@mac.com wrote: It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Hi James, The one aircraft I enjoy flying is the Alphajet ... that uses the generic autopilot/route manager system. My one comment with the new route manager is that I've had some variability in the results of building a route. Maybe I'm not understanding the interface correctly, but sometimes my starting airport gets added, even when I'm in the air. Sometimes it gets in there twice. After creating a route, I always need to go in and manually clean up extraneous stuff before I get what I hoped for. (Sorry for using the word always, maybe I should say I feel like I always have to go fix the route manually.) :-P Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 12:48 PM, James Turner wrote: I thought I'd fixed that back at the start of October, soon after the initial commit - Curt complained that h couldn't start a route 'in-air' so I removed the need for departure/destination airports. Ah, I get it - you're specifying a departure airport, but then not activating the route until airborne. Hmm. I'm not sure that's actually a bug. Activating a route starts a leg to the first waypoint ... regardless of wether that's 'behind' you in the route or anything. In real-life I'd activate the route, then select the enroute waypoint I wanted to 'start' from, and 'DTO' on it, to head straight there - that's exactly how I fly departures where ATC vector me, then clear me to a SID waypoint. What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. Conceptually, including the starting point in the route seems like it could always be problematic.The airport location is some random point on the airport grounds (probably the average of the center points of the runways.) Even if you haven't taken off yet, it would be possible in some circumstances to not fly close to the center of the airport on take off. Then you would get routed back to the starting point before you could continue on to the next way point. I think we are just getting lucky when we fly close enough to the center of the airport in most situations for most runways to satisfy the route manager and it clicks on to the next waypoint. The KSFO airport layout is very friendly in this regards, but other airports like DFW and DEN are more sprawling. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
On Mon, Dec 21, 2009 at 1:00 PM, Bob Faulkner wrote: Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. Change makers to distributors I believe flight sim pro may be using a distributor/partner sales model, so distributor might be the most appropriate term here? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
On Mon, Dec 21, 2009 at 1:30 PM, Curtis Olson wrote: On Mon, Dec 21, 2009 at 1:00 PM, Bob Faulkner wrote: Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. Change makers to distributors I believe flight sim pro may be using a distributor/partner sales model, so distributor might be the most appropriate term here? Affiliate is the word I was looking for ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, Dec 21, 2009 at 3:21 PM, Heiko Schulz wrote: Did you try to turn on/off jaw damper? Hah, I tried that on my wife and it didn't work ... :-) (jaw being a bone in the mouth, yaw being side to side motion.) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, Dec 21, 2009 at 9:54 PM, Ron Jensen wrote: In my view --enable-auto-coordination is a game feature, and usable for people without a rudder axis control. A group you seem to have completely overlooked. Yup, it's never been intended to be more than a simple work around for people without rudder pedals or a twist grip on their joystick. A game feature is a good description I think. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Fri, Dec 18, 2009 at 4:33 PM, Peter Brown pe...@smoothwatersports.comwrote: Worrying about GS service volume seems off-scale unimportant relative to other issues. For starters, Stansted has a reversible ILS. The code to handle reversible ILSs in FG has been broken for years, and actually got worse recently. The code to make it possible to fly at airports with reversible ILSs has been available for a long time. From a user's point of view, and don't this wrong for I'm not sure of the long term goals, but if success includes attracting users and retaining them then the little details such as this will enhance that aspect more than some other things. Realistic flight performance, including operations within the airport radius are typically high in value to a user. This isn't to take the side of someone complaining about not getting the glideslope at full volume until 7 miles, he should be well on his way with a standard decent rate out of the turn point. I think the 10 mile minimum should work fine, until it gets enhanced to extend to a trickle out point, which is the ideal. (And often 20 miles) Is there a published list somewhere of the major issues that the developers contributors are striving to correct, enhance, add, etc? In this particular case we are building a twin turbo prop simulator (Beech 1900) with a full cockpit, dual controls, and wrap around visual system (based largely on FlightGear.) Glide slope range is something the customer commented on, so that pushes it up my priority queue a bit. There are times when it makes sense to debate the customer's perceptions (gently show them why they are incorrect) but in this case I think 10nm is borderline, although upon further discussion, there were other aspects of what was going on that were indeed more important. So no, this isn't a drop dead issue, but at some point if we boost the default service volumes up by a few percent hopefully people won't get too bent out of shape? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Curt's airfield with dual view fron the rascal camera pictures on flightprosim !!!
On Wed, Dec 16, 2009 at 5:31 PM, Alexis Bory - xiii wrote: Yes he dares ! http://flightprosim.com/screenshots/SNAG-0281.jpg Now I'm winding! (Picture my right arm making a reverse windmill motion) :-) I bet he didn't get permission from google to post/use google map imagery (like we did on that project.) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Glide slope (ILS) range
I had a squawk here from a (real) King Air pilot because on an ILS approach, our glideslope indicator doesn't become active/in-range until about 7-8 miles out. Beyond this range the indicator just stays centered at zero. With a standard 3 degree glide slope, 7 miles out equates to about 2000' AGL, outside of this range the FlightGear glideslope does nothing. I see our database lists the GS ranges at 10nm usually. However, our code seems to be clamping the range to something significantly less than that. I've been poking around in navdb.cxx and navradio.cxx but haven't been able to connect all the dots yet. I don't have personal knowledge of what is correct, but this change to glideslope range impacts our ability to practice ILS approaches and I have a current King Air pilot complaining about the behavior. Pulling out some old approach plates for KMSP here I see a 14nm distance and 5000' MSL entry altitude (4000'+ AGL) referenced in the approach to 30R. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
On Thu, Dec 17, 2009 at 1:25 PM, James Turner wrote: On 17 Dec 2009, at 18:44, Curtis Olson wrote: I don't have personal knowledge of what is correct, but this change to glideslope range impacts our ability to practice ILS approaches and I have a current King Air pilot complaining about the behavior. Pulling out some old approach plates for KMSP here I see a 14nm distance and 5000' MSL entry altitude (4000'+ AGL) referenced in the approach to 30R. Is 7-8 miles a realistic range for the glide slope? Is my King Air pilot contact smoking something? Personally, I agree our ranges are very short, however, I *believe* the navradio code is respecting the range specified in nav.dat (often 10nm as you point out). If the code isn't respecting the published range, that's a bug, almost certainly mine, and I'll fix it ASAP. There is a separate issue about whether the GS receiver ought to receive a signal beyond the published range, eg a 20% or 30% margin above what is published. There are arguments against doing that, and arguments for it, and personally I'm not sure. When you look at many approach plates, the GS volume is often quite short. Hi James (Hi John), I will try to get a more detailed bug report. As I've been looking more closely here, I am seeing the glide slope come alive right at 10nm on the two approaches I have tested, which would mean that the code appears to be doing what we ask of it, since most of the glide slope transmitters are marked as 10nm range. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Model animation help?
Hi, I'm looking for a developer who can help me get over the hump with animating and AC3d model. This model is of a human figure. It is a very basic/simple model, but unfortunately I don't have permission to openly share it. I can send someone a private copy though if there is someone willing to help me out. (Again, the model is nothing special, you guys would look at it and say we have better figures already in FlightGear, I just haven't been given permission to post it on the world wide web.) I'm getting hung up trying to find the correct x,y,z locations for limb animation. In flightgear, are the coordinates we specify as the center point of rotation global (i.e. relative to the whole model?) Or are they relative to the local coordinate system of the sub-component? Since this is a simple human figure, there is some cascading / grouping I want to maintain ... i.e. a shoulder rotation and then an elbow rotation. I looked at the Osprey and see that some really amazing cascading animations are definitely possible in FlightGear, I just haven't quite sorted out coordinate systems. Is there anyone with ac3d model animation experience who'd be willing to take a quick look at this and help nudge me in the right direction? Thanks in advance, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Model animation help?
Hi Ron, Can I send you a copy of the model? I'd really like to make some good forward progress this week, but it's not a drop everything and get it done today sort of thing. Hey, I really owe you a flightgear t-shirt or mug and if you help out on this, then doubly so ... I did make an attempt to extract the coordinate of the center of rotation using ac3d (I have a licensed copy here, not that I can do much with it) but what I read out of ac3d was clearly wrong when I tried to do an actual animation. Curt. On Tue, Dec 15, 2009 at 11:19 AM, Ron Jensen w...@jentronics.com wrote: On Tue, 2009-12-15 at 16:53 +, Ron Jensen wrote: Coordinates are in ac3d units centered about the origin of the model. Oh, and the coordinate system is slightly altered between ac3d and fg, too: AC3D FG X X (fwd/aft) Y Z (up/down) Z-Y (side) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear
On Sat, Dec 12, 2009 at 1:59 PM, syd adams adams@gmail.com wrote: Hi guys , Ive started some scenery developement ,have learned a fair bit in the last few days , but have more questions than answers at the moment. Ive been using the original hgt files for the Vancouver area , Im more interested in fixing the materials , roads, streams , coastline , etc. I did discover that fgfs-construct's lon , lat is the center of the work area . not bottom left like i assumed , and you need to delete the AirportArea and AirportObj folders before regenerating the airport again or you end up with holes ... Can the order of material clipping be controlled , or is that hardcoded somewhere ? I believe the clipping order is hard coded in the polygon.[ch]xx (or is it names.[ch]xx) file off the top of my head. I use the Mapserver shapefiles , and modify them with Qgis , but two different types of vector layers dont seem to snap together , so I get a fair bit of overlap . I think I might have ask this one before , but... why a single texture assigned to several material names ? Just a shortage of textures , or is there a limit to the amount of textures that can be used ? A part of it is to limit the amount of texture used for scenery (although we've never had a formal texture budget for different parts of the program.) And part of it could be that no one as developed a nice looking texture for that material type. I also see that one material can have several texures assigned . Are they selected randomly at startup ? This I believe was added so that you could do some randomization and reduce the problem with repeating artifacts in the land cover ... the downside is that this randomization doesn't blend well at the borders like you can do with a single tiling texture ... but there are always trade offs to everything I guess. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Understanding scenery archatecture
On Fri, Dec 11, 2009 at 9:58 AM, cullam Bruce-Lockhart culla...@yahoo.comwrote: Hey gang. I've just started putting together some visual aids in understanding what happens in a scenery build process. That's well and good, but I'm having an issue with terrafit. I've recently discovered that my understanding of how terrafit works is wrong. I'd always assumed it took a grid of elevations, calculated planes of best fit, using the max error threshold, then adjusted all the heights in the grid. It turns out that it actually leaves the heights unchanged, but deletes any that aren't deemed significant. I've been reading through terrafit.cc, but I can't figure out anything about what it does to determine significance. Could anyone explain to me how terragear uses the error threshold to determine what the list of points to be included is? It's actually pretty straightforward and a cool algorithm. I'll try to briefly explain it here. Imagine two piles of grid/elevation points. (1) The pile of points that are available to use in the final fit (but haven't been selected yet) and (2) the pile of points that we have used for the final fit. We start out with all the grid elevation points in the available pile and an empty used pile. Step 1 is to select the 4 corners and move them from the available pile to the used pile. Now we triangulate the used pile of points (which should be two triangles at the start because we have 4 points.) We then look at all the available points and find the point that is furthest away from these triangular planes. This point gets moved from the available pile to the used pile. Next we triangulate the used pile of points again (now with 5 points which will yield 3 triangle surfaces.) We look at all the remaining available points and find the point that is furthest away from the new surface and add that to the used pile. Now we triangulate the used points again (6 points, 4 triangles) find the available point that is furthest from this surface, add it to the set of used points, and keep repeating. We repeat this process, incrementally improving our fitted surface, until one of two conditions is met. (A) we hit a maximum number of final points (to keep final scenery complexity under control) or (B) none of the remaining points are outside our error threshold (i.e. if our error threshold was 10m, then all the remaining available points are within 10m of the fitted surface.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs compile error, today's cvs
I'm not sure the best way to handle this but if you start at the top and run ./autogen.sh followed by ./configure --options I think the error will be cleaned up. Switching files from abc.c to abc.cxx confuses the dependency tracking of automake. Curt. On Wed, Dec 9, 2009 at 7:33 PM, dave perry skida...@mindspring.com wrote: I am getting the following error compiling fgfs from cvs today on two different systems. $ make Making all in tests make[1]: Entering directory `/home/dad/source-osg/source-fgfs/tests' make[1]: *** No rule to make target `est-epsilon.c', needed by `est-epsilon.o'. Stop. make[1]: Leaving directory `/home/dad/source-osg/source-fgfs/tests' make: *** [all-recursive] Error 1 $ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
On Wed, Dec 2, 2009 at 12:57 AM, Tim Moore wrote: Just to be clear, are you running with CullThreadPerCameraDrawThreadPerContext, or what? How many of each? Hi Tim, I was running with AutomaticSelection and only had a single display enabled: --prop:/sim/rendering/multithreading-mode=AutomaticSelection I've checked in a fix that should prevent the GUI drawing code from running at the same time as code that might manipulate its state; give it a try. After removing the above option from my .fgfsrc file I haven't seen a crash with the dialog boxes. You're not trying to do something weird like run the GUI on more than one screen, are you? No, not yet, but that would be a great feature request. Also being able run additional 2d panels on extra displays, but that's a very low priority for me at the moment, devices like the matrox triplehead to go and nvidia-twinview help reduce the need for a software solution. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Model diffuse and ambient colors
I've been playing around with the Rascal aircraft model, but it appears that it's never had it's materials updated and thus looks very dark on the non-illuminated sides. Is there a howto posted somewhere that explains how to fix this? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Frequent segfaults in latest flightgear
I've been observer quite frequent segfaults in the most recent version of FlightGear. I've started running under gdb and so far the trend seems to be that the crash is inside the pui code and as a result of clicking ok or cancel on a dialog box. Here's an example backtrace (the build is without -g though). Anyone else seeing this? I'm using plib-1.8.5 and OSG-2.9.5. Boost is 1.37. #0 0x07a12606 in main_arena () from /lib/libc.so.6 #1 0x0862bb91 in puGroup::draw(int, int) () #2 0x0862bb21 in puGroup::draw(int, int) () #3 0x0862bb21 in puGroup::draw(int, int) () #4 0x0862bb21 in puGroup::draw(int, int) () #5 0x0862bb21 in puGroup::draw(int, int) () #6 0x08628c0d in puDisplay() () #7 0x08070371 in SGPuDrawable::drawImplementation(osg::RenderInfo) const () #8 0x00a931a7 in osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #9 0x00a8c7b2 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #10 0x00a8c43e in osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #11 0x00a8c7f4 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #12 0x00a9584e in osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #13 0x00a8c43e in osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #14 0x00a973a0 in osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) () from /usr/local/lib/libosgUtil.so.60 #15 0x00a9ab93 in osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLe---Type return to continue, or q return to quit--- af*) () from /usr/local/lib/libosgUtil.so.60 #16 0x00aa26c2 in osgUtil::SceneView::draw() () from /usr/local/lib/libosgUtil.so.60 #17 0x00282fed in osgViewer::Renderer::draw() () from /usr/local/lib/libosgViewer.so.60 #18 0x00280697 in osgViewer::Renderer::operator()(osg::GraphicsContext*) () from /usr/local/lib/libosgViewer.so.60 #19 0x00f78963 in osg::GraphicsContext::runOperations() () from /usr/local/lib/libosg.so.60 #20 0x00f7e1dd in osg::RunOperations::operator()(osg::GraphicsContext*) () from /usr/local/lib/libosg.so.60 #21 0x00f7e467 in osg::GraphicsOperation::operator()(osg::Object*) () from /usr/local/lib/libosg.so.60 #22 0x00fceedd in osg::OperationThread::run() () from /usr/local/lib/libosg.so.60 #23 0x00f7e4f9 in osg::GraphicsThread::run() () from /usr/local/lib/libosg.so.60 #24 0x00cdde89 in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /usr/local/lib/libOpenThreads.so.11 #25 0x006a5935 in start_thread () from /lib/libpthread.so.0 #26 0x0798294e in clone () from /lib/libc.so.6 Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
On Tue, Dec 1, 2009 at 11:06 AM, James Turner zakal...@mac.com wrote: On 1 Dec 2009, at 16:59, Curtis Olson wrote: I've been observer quite frequent segfaults in the most recent version of FlightGear. I've started running under gdb and so far the trend seems to be that the crash is inside the pui code and as a result of clicking ok or cancel on a dialog box. Here's an example backtrace (the build is without -g though). Anyone else seeing this? Not seeing that here - I assume if it was any particular dialog box, you would have mentioned that. I'll try to pay attention to which dialog box it happens with when I see it again. Right now I'm running ok and I've been able to open and close a variety of dialog boxes without any problems. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
On Tue, Dec 1, 2009 at 11:21 AM, Curtis Olson wrote: On Tue, Dec 1, 2009 at 11:06 AM, James Turner wrote: On 1 Dec 2009, at 16:59, Curtis Olson wrote: I've been observer quite frequent segfaults in the most recent version of FlightGear. I've started running under gdb and so far the trend seems to be that the crash is inside the pui code and as a result of clicking ok or cancel on a dialog box. Here's an example backtrace (the build is without -g though). Anyone else seeing this? Not seeing that here - I assume if it was any particular dialog box, you would have mentioned that. Sorry for the multiple emails ... ok it just happened again to me with the autopilot dialog box. When I clicked on the close button, I got a segmentation fault ... with a backtrace *very* similar to what I posted before. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
Here's an updated back trace with debugging symbols for plib ... the segfault is on typeinfo for puDial() which is strange. Is this RTTI related? I observe that the crash happens when the dialog box is being closed, so could we have something out of order or a race condition between the thread that creates/deletes dialog boxes and the render thread, where the dialog box is destroyed while the render thread is in the middle of drawing the scene? The random nature of the crash could fit in with the theory that it's a race condition with the render thread. How about we get some people opening and closing a lot of dialog boxes with the latest cvs version of everything to see I'm the only one seeing this? (I'm on fedora 11 with osg-2.9.5 which is the latest developer release as of a few minutes ago.) We really need to stomp out all the hangs and crashes before we can even think about another public release! Thanks, Curt. (gdb) where #0 0x086a9620 in typeinfo for puDial () #1 0x0862b68b in puGroup::draw (this=0x17d49d88, dx=0, dy=0) at puGroup.cxx:314 #2 0x0862b68b in puGroup::draw (this=0xb736e4d8, dx=0, dy=0) at puGroup.cxx:314 #3 0x086287ed in puDisplay () at pu.cxx:304 #4 0x08070371 in SGPuDrawable::drawImplementation(osg::RenderInfo) const () #5 0x007c61a7 in osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #6 0x007bf7b2 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #7 0x007bf43e in osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #8 0x007bf7f4 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #9 0x007c884e in osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #10 0x007bf43e in osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 #11 0x007ca3a0 in osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) () from /usr/local/lib/libosgUtil.so.60 #12 0x007cdb93 in osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) () from /usr/local/lib/libosgUtil.so.60 ---Type return to continue, or q return to quit--- #13 0x007d56c2 in osgUtil::SceneView::draw() () from /usr/local/lib/libosgUtil.so.60 #14 0x00afcfed in osgViewer::Renderer::draw() () from /usr/local/lib/libosgViewer.so.60 #15 0x00afa697 in osgViewer::Renderer::operator()(osg::GraphicsContext*) () from /usr/local/lib/libosgViewer.so.60 #16 0x00fa8963 in osg::GraphicsContext::runOperations() () from /usr/local/lib/libosg.so.60 #17 0x00fae1dd in osg::RunOperations::operator()(osg::GraphicsContext*) () from /usr/local/lib/libosg.so.60 #18 0x00fae467 in osg::GraphicsOperation::operator()(osg::Object*) () from /usr/local/lib/libosg.so.60 #19 0x00ffeedd in osg::OperationThread::run() () from /usr/local/lib/libosg.so.60 #20 0x00fae4f9 in osg::GraphicsThread::run() () from /usr/local/lib/libosg.so.60 #21 0x00523e89 in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /usr/local/lib/libOpenThreads.so.11 #22 0x006a5935 in start_thread () from /lib/libpthread.so.0 #23 0x02cb894e in clone () from /lib/libc.so.6 (gdb) On Tue, Dec 1, 2009 at 11:24 AM, Curtis Olson wrote: On Tue, Dec 1, 2009 at 11:21 AM, Curtis Olson wrote: On Tue, Dec 1, 2009 at 11:06 AM, James Turner wrote: On 1 Dec 2009, at 16:59, Curtis Olson wrote: I've been observer quite frequent segfaults in the most recent version of FlightGear. I've started running under gdb and so far the trend seems to be that the crash is inside the pui code and as a result of clicking ok or cancel on a dialog box. Here's an example backtrace (the build is without -g though). Anyone else seeing this? Not seeing that here - I assume if it was any particular dialog box, you would have mentioned that. Sorry for the multiple emails ... ok it just happened again to me with the autopilot dialog box. When I clicked on the close button, I got a segmentation fault ... with a backtrace *very* similar to what I posted before. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/http://baron.flightgear.org/%7Ecurt/ -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
On Tue, Dec 1, 2009 at 1:32 PM, Tim Moore timo...@redhat.com wrote: Just to be clear, are you running with CullThreadPerCameraDrawThreadPerContext, or what? How many of each? That's a good question. I had been running with: --prop:/sim/rendering/multithreading-mode=AutomaticSelection This is on a system where I often run with two monitors (although right now I'm just running in a single monitor.) Since I've removed that option, the dialog box closing crash has not occurred, although it's way to early to say that I won't yet get a similar crash (but so far so good.) OSG is past 2.9.6 now. Really? Where do they have that posted? I've been checking periodically in hopes that they would come out with a new release that recognized the '[' and '[' keys so I could have flaps back again. http://www.openscenegraph.org/projects/osg - Downloads - All recent OpenSceneGraph-2.9.x developer releases The most recent release they have posted here is 2.9.5 ... did they do a stealthy unannounced release? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frequent segfaults in latest flightgear
On Tue, Dec 1, 2009 at 3:36 PM, Tim Moore wrote: No, I meant that 2.9.6+ is in svn. Oh ok. I've been trying to live with downloadable releases, otherwise if people are pulling different snapshots out of the repository at different times we end up with something ... oh ... maybe like the openal situation where Fedora ships with a cvs snapshot of some openal variant from 2006 and that's different from the 40 or so openal implementations floating around. But that's probably not my issue anyway, it very likely was the OSG threading model selection not playing nice with plib/pui -- leading to a race condition and causing the crash. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs sound crystal clear /w pulseaudio in FC12
On Mon, Nov 30, 2009 at 10:44 AM, dave perry wrote: For any Fedora users, I recommend preupgrade to FC12. All the fgfs sounds work and are crystal clear, no crackle! This includes ATC, ATIS, vor and loc ident, marker beacons, cockpit sounds (switch clicks, flaps, etc.). Ok, I'm definitely going to have to try upgrading here ... I encountered several potential gotchas: 1. If you have an NVIDIA graphics card, before you begin, print the info from the following link: http://linuxsoftwareblog.com/blog/?p=232 2. Clean up /boot before you start preupgrade. Delete all but the most recent kernel files. If you do this, a 200 MB /boot is big enough. 3. Do a sudo yum upgrade before running preupgrade. 4. Be ready with a fedora DVD for a rescue. After preupgrade completes, and the system is rebooted, you may need to edit /etc/inittab to boot into run level 3. If you boot up and the X11 graphics fail to start (because of some degenerate combination of left over nvidia drivers and libs that didn't play well with the default X11 stuff from the upgrade.) You should be able to hit Alt-F2 to get a text login prompt. I have always installed the nvida drivers using the .sh file downloaded directly from the nvidia site, so at this point you can just login as root and sh NVIDIA.sh to install/freshen the drivers. Then you can run init 3 to kill X11 followed by init 5 to startup again. You shouldn't need the install dvd to do this. Also at the boot prompt you should be able to add the single option to boot up in single user mode with no graphics. There is also emergency mode which boots up with the root partition mounted read only ... but a good admin can quickly remount it rewrite. :-) (something like mount -o rw, remount / but it's been a while.) 5. The info from the link in #1 should allow you to get nvidia driver support. I use the driver from www.nvidia.com, so only the first item was required to allow the nouveau module to release control so the install could proceed. Hope this helps others. Thanks Erik for staying on this! Regards, Dave P. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FC12 openal and pulseaudio question
On Sat, Nov 28, 2009 at 8:31 PM, dave perry wrote: Hi, I used the preupgrade to FC12 from FC10 this Saturday on my ASUS notebook (Intel core2 duo). This installed openal-soft-1.10.622-2 openal-soft-devel-1.10.622-2 and pulseaudio-0.9.21-1 I had to use OpenSceneGraph-2.9.5 as the svn up for osg broke fgfs link. With the above I either get good frame rates (same as in FC10) and no sound or crackly sound with very low frame rates depending on how I launch fgfs. Question: What versions of openal and pulseaudio are others with FC12 using that give good sound and performance? I have a machine here where I did the upgrade from Fedora 10 to Fedora 11 and I see similar symptoms to what you report in your FC10-FC12 upgrade. For the most part, all other audio apps are just fine on this machine. I can play youtube videos, I can play mp3's and audio CD's. I hear the desktop sound effects, etc. But audio for FlightGear has been totally hosed since my upgrade. I have another machine (laptop) which I installed FC11 directly, and audio with respect to FlightGear is better. I generally hear what I should here, but there is quite a bit of static/crackling mixed in, so it is far from perfect. Erik mentioned running openal-info or alcinfo, but neither of these are installed on my machine with my version of openal or alc: $ rpm -aq openal openal-0.0.9-0.17.20060204cvs.fc11.i586 As others have pointed out, pulseaudio (despite it's imperfections) is installed by default on a lot of current distributions. It seems like we should try to find a way to work with it some how. I personally don't want to uninstall pulseaudio from my system and then have to struggle with all my other individual apps to reconfigure their audio and get them back to a working state ... right now, FlightGear seems to be the only app I have that isn't playing nice with pulseaudio. Even my virtual machine (windows XP running inside my Linux host) happily plays all it's sound effects through my linux host system. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] changes for the xml autopilot
Hi Torsten, One thing I noticed recently (but this could have been in the code for a while) is that if a reference is a hard coded value instead of a property then if the autopilot definition is reloaded (something you might do often when tuning the autopilot) the value nodes can get mismapped to other nodes. I took a brief look at the code and noticed there had been some parser changes, but didn't unwind deep enough to get to the bottom of this. As a practical explanation of what I'm seeing: let's assume the first stage of the heading controller is to drive the heading-bug-error property to zero. The reference in this case is always going to be zero since the error term is computed inside the C/C++ code. In the same autopilot xml file the altitude controller has a reference of target-altitude which is a property. Let's say that is set to 3500 and I'm flying nicely. After reloading the autopilot, these can get mixed up and all of the sudden the heading controller is trying to drive the heading-bug-error to 3500 (the altitude) and this of course can never happen so the aircraft enters a perpetual circling pattern. The problem seems to be pretty deep in the parser which seems to have been rewritten a bit with some new subobjects, but I wasn't able to unravel the problem in the time I had available to look into it. :-( Thanks, Curt. On Fri, Nov 27, 2009 at 9:24 AM, Torsten Dreyer tors...@t3r.de wrote: Hi, I have just commited some changes to the xml autopilot. Along with a tiny bugfix comes a new feature which now allows more than one autopilot definition in the aircraft's -set.xml. You may now do something like this: sim systems autopilot pathAircraft/Hansajet/Systems/Hansajet-flightdirector.xml/path /autopilot autopilot pathAircraft/Hansajet/Systems/Hansajet-autopilot.xml/path /autopilot autopilot pathAircraft/Hansajet/Systems/Hansajet-digitalfilters.xml/path /autopilot /systems /sim Each autopilot element creates a new instance of the well known FGXMLAutopilot class which is added to a newly created SGSubsystemGroup. This subsystem group is added to the subsytem manager instead of the previous single instance of the autopilot. The idea behind this change is to be able to keep sophisticated autopilot configurations maintainable. No functional changes should happen to existing autopilots. Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] atlas global tarball
Alex, Somewhere I think I still have a set of atlas maps for the world, but these were generated maybe 8-9 years ago, so there's perhaps a good chance the file format or structure or image dimensions has changed since then. I have to admit I haven't run atlas since many years ago. I think there's a snapshot of the world scenery floating around on some svn code site someplace. :-) Curt. On Sun, Nov 22, 2009 at 3:00 PM, Jari Häkkinen wrote: Map will only generate the maps downloaded by terragear and the ones in fg data CVS repository. It is not that much assuming you haven't crossed the globe a few times. Jari Alex Perry wrote: The computer isn't too slow, no. I'm just hoping to avoid having to download the entire global scenery data first. On Sun, Nov 22, 2009 at 3:53 AM, Victhor Foster victhor.fos...@gmail.com wrote: Is your computer too slow to generate them? There's an option in Map that speeds up the process, I think it's --headless-mode. Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
On Wed, Nov 18, 2009 at 6:41 AM, cullam Bruce-Lockhart culla...@yahoo.comwrote: I guess the big question is when do the textures get assigned in the first place? This is going to sound a little strange, but what gets assigned within terragear is a material name (which FlightGear resolves into a texture) and generic texture coordinates (which FlightGear resolves into specific texture coordinates.) The benefit of this approach is that the texture and the texture scale can be quickly swapped in the materials file without needing to regenerate the scenery within terragear. Another way to look at this is that a texture to be scaled properly will cover some n x n meter area. Terrain textures should be square textures are are designed to be repeating/tiling. However, if an artist designs a new texture, the imagery might be scaled to cover some different amount of area. If we don't change the texture coordinate assignments, then trees and buildings and other things cooked into the texture imagery could be too big or too small. So the materials.xml file defines the actual texture and the texture scale, and the final texture coordinates are computed when the scenery is loaded and the scene graph is built (using a combination of the generic texture coordinates assigned by terragear with a bit of code/logic on the FlightGear side.) As for the stretching issue, I'll have to think about that. But I'm thinking about cliffs as shallow as 45 degrees, so it shouldn't be such an issue there. I'm also HOPING to make it an input parameter into fgfs-construct, so that it could be added into the main terragear functionality, for anyone working on high enough resolution scenery for it to be of use. In a low detail model, You might want 75 degrees or more to be defined as cliff face. But if it was an input parameter, then the option would be there. The basic approach used by terragear makes it very difficult to change texture coordinate mapping according to any other rules. I don't know the best way forward, but a couple things come to mind. 1. you could cut out holes where the cliff polygons are situated, leaving these areas open in the final terragear result, and then place custom object models in those holes. You might be able to leverage terragear and make programming modifications to assist in this process, but it will be hard to do any kind of natural blending with the surrounding areas ... and that's hard anyway and is something terragear doesn't address very well. 2. you could do the entire terrain block as a custom model generated with some other tool set (blender, creator, etc.) There's no reason a terrain block has to be in .btg format. The .stg file could reference and place any model format that is supported by OSG. 3. It might be worth looking at the terrain shader. This kills performance for me in mountainous, high polygon count areas, but it might be adaptable to do exactly what you need at run time? Also, is there an issue I should be concerned with in terms of texture priority? I know that there's a list of what gets drawn on top of what. But there seemed to be a few places where this list came up. At the very least, my attempts at adding to this list failed completely. Anyone know off the top of their head how to change the texture list, or add my own categories to it? This is more so for my own local use, rather than for the Terragear project, as I doubt anyone else needs a texture specific to the brown rocks in Newfoundland. Off the top of my head there is a names.cxx/hxx pair that contains the definitions and priority of the areas. Note that when the tile is built, all the polygon areas for that tile are added in priority order and clipped against any areas that were placed earlier in the sequence. The end result is something like a jigsaw puzzle where the entire tile is covered in a single layer of polygons with no gaps and no overlaps. So think of this priorty scheme not as a texture priority, but as a clipping priority when assembling the jigsaw puzzle of shapes. For instance a road might have priority over a river so that the road will be shown to cross the river. A river would have priority over an urban area so that the river is shown to cut through the city. An airport area has the highest priority because that is our best and most accurate data. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cliffs
On Wed, Nov 18, 2009 at 9:29 AM, cullam Bruce-Lockhart culla...@yahoo.comwrote: Which still leaves me with the question of where in FGFS-construct is the terrain type FIRST assigned. I'd like to do the cliff assignment at that point, rather than one of the many other time in the program it looks the assignment up. I just don't know which piece of code that get's the terrain type is actually assigning it in the first place. Terrain type is defined 'first' in the original shape files. These are then chopped up against tile boundaries and saved into simplified terragear polygon files. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] November T-Shirt Contest
Voting for the November t-shirt contest is underway over at the FlightGear Forums. If you haven't voted, now is your chance! Voting will end soon!!! http://www.flightgear.org/forums/viewtopic.php?f=10t=6352 Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Automatically hide/show the menubar
On Mon, Nov 16, 2009 at 2:49 PM, Torsten Dreyer wrote: Hi, I just committed a featurette for the menubar which is disabled by default but can be enabled by setting /sim/menubar/autovisibility/enabled to true. If enabled, the menubar is invisible and pops up when the mouse in mode 0 hits the upper edge of the fgfs window. It stays visible until the mouse clicks somewhere outside the pui elements. Nothing new for x-plane users... Previous F-10 behaviour is untouched. Hope you like it. If so, it might be enabled by default in preferences.xml some day. Hi Torsten, Here's another random thought. I don't know if it would be any better or not, but might be interesting for some situations. Right now we hide the mouse pointer after 10 seconds of no mouse motion. It might be interesting to hide the menu at the same time? This may not be optimal for those who fly with the mouse, but could be useful for many other usage modes. It might make sense to make the F10 toggle work in partnership with the auto-hider feature rather than keeping the functions totally separate? If the auto-hide is turned on and the menu has become hidden, what happens when someone presses F10? Should this make the menu visible and turn off the auto-hide feature (at least for a while)? I'm worried that if auto-hide is enabled and someone presses F10 to toggle the menu off, will the menu then not appear when you move the mouse to the top of the screen? If someone inadvertently presses F10 and doesn't realize it, the menu could be lost to them. I only worry about this because I got a different keyboard about a year ago and I'm still forever missing my intended key and hitting the wrong one ... especially when I'm trying to focus on too many things at once ... like when I'm flying. :-) Thanks! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] International Runway Issue (leading zeros)
On Sun, Nov 15, 2009 at 12:28 AM, John Denker j...@av8n.com wrote: On 11/14/2009 11:36 AM, Curtis Olson wrote: I suppose we could use some heuristic such as: 4 character airport code that do not start with K or P use a leading zero, and all other airports omit the leading zero? We could setup the code logic to be extensible if we find other countries that also tend to omit the leading zero. That doesn't give us individual control over individual runways, but it might make things generally better than they are now? I missed something in my original email I see. In addition, any airport codes that are 3 characters long would be assigned to the USA. I think we use 4 character ICAO codes for everything outside the USA. On the other hand, this assumes that the USA is the only country that doesn't use leading zeros on the runways which I doubt is the case. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, Nov 14, 2009 at 11:53 AM, Ron Jensen wrote:
It would be a trivial patch to genapts to always generate leading zeros,
however it appears that all US General Aviation airports don't use the
leading zero, US Military bases are mixed, and Europe uses leading
zeros. Looking thru apt.dat it appears all runway numbers have the
leading zero so we can't use that data to algorithmically determine the
format to use... So here's the patch to always generate leading zeros,
but should it be applied everywhere?
diff --git a/src/Airports/GenAirports/rwy_common.cxx
b/src/Airports/GenAirports/rwy_common.cxx
index c5aef04..17a2ff5 100644
--- a/src/Airports/GenAirports/rwy_common.cxx
+++ b/src/Airports/GenAirports/rwy_common.cxx
@@ -52,7 +52,8 @@ void gen_number_block( const TGRunway rwy_info,
if ( num == 11 ) {
sprintf( tex1, 11 );
} else if ( num 10 ) {
- sprintf( tex1, %dc, num );
+ sprintf( tex1, %dl, 0 );
+ sprintf( tex2, %dr, num );
} else {
sprintf( tex1, %dl, num / 10 );
sprintf( tex2, %dr, num - (num / 10 * 10));
I suppose we could use some heuristic such as:
4 character airport code that do not start with K or P use a leading
zero, and all other airports omit the leading zero? We could setup the code
logic to be extensible if we find other countries that also tend to omit the
leading zero. That doesn't give us individual control over individual
runways, but it might make things generally better than they are now?
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, Nov 14, 2009 at 12:50 PM, Ron Jensen wrote: I commented on the other European-ization thread (about precision marking differences) that perhaps genapts should take a flag for European or US style rendering? Martin pointed out that for the vast portion of airports and scenery areas of the world, they are generated using hands off batch processing methods. This is the primary mode in which genapts and terragear were designed to run. So certainly a flag would be useful if a developer wants individual control over a runway or an airport, but some sort of heuristic for the rest of the airports in the world would also be useful ... or some way to enhance the data file so a per-runway-end decision could be made automatically. I.e. add a field to the database and fill it in with some heuristic, then from there on allow manual tweaking for individual airports. Then the batch processor would have the information it needs for a full world regen, then next time that is run. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear logo; Was: t-shirt give away
On Fri, Nov 13, 2009 at 1:34 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Curt Olson wrote: I think we also need a good slogan or motto ... I kind of like: FlightGear: Educate, Entertain, Inspire. On the FSweekend posters, we had printed out: Naturally flying is free. I like it ;) I think this might be a phrase that doesn't quite sounds as smooth in English as it probably does in the original Dutch. It could be my warped mind, but when I see the words naturally flying (which could be rewritten flying naturally and would mean the same thing) for some reason I think of flying while dressed as nature intended. :-) But that's not a picture I really want to communicate in our slogan. Oh, and take a look in the FG logo topic, where we had some nice ideas (altough none of them might be usefull straight away it gives a nice impression of what our users like) http://www.flightgear.org/forums/viewtopic.php?f=6t=2633 Yes, lots of good thoughts and ideas there. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgms server in Lithuania
On Thu, Nov 12, 2009 at 6:00 AM, Darius wrote: Hello, I would like to add new multiplayer server, which is located in Eastern Europe region in Vilnius, Lithuania. Computer uses 100 Mbit fiber internet. OS debian stable lenny (current stable). IP address 193.219.56.151. Open ports 5000, 5001, 8000. Do I have to provide additional information? Hi Darius, I have added your machine as mpserver11.flightgear.org Thanks! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear logo; Was: t-shirt give away
I think this design looks really great on a t-shirt or a mug, but I'm not sure how well it works as a web page header or an icon. Perhaps something could be adapted from the full logo to work in other contexts. I think we also need a good slogan or motto ... I kind of like: FlightGear: Educate, Entertain, Inspire. Curt. On Thu, Nov 12, 2009 at 5:31 PM, Martin Spott wrote: Curtis Olson wrote: Torsten's wife designed the t-shirt graphics (with some valuable input from Torsten and I.) You can see the design here: http://www.cafepress.com/fgfs Wouldn't this be a great chance to declare this design as being the new 'official' FlightGear logo ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
On Mon, Nov 9, 2009 at 4:38 PM, Durk Talsma d.tal...@xs4all.nl wrote: Hi All, Last weekend we've been organizing a booth at FSWeekend again. I'll try to write a few more elaborate set of impressions later, however, let me just say that our booth was quite large this year. :-) In the mean time, here are some pictures: http://www.xs4all.nl/~dtalsma/FSWeekend/web/index.htmlhttp://www.xs4all.nl/%7Edtalsma/FSWeekend/web/index.html I recognized Martin, Torsten, and Durk in the pictures. I assume Durk was behind the camera. I *really* like this shot: http://www.xs4all.nl/~dtalsma/FSWeekend/web/34.html These guys don't look so scary in real life: http://www.xs4all.nl/~dtalsma/FSWeekend/web/40.html I'm really impressed with the amount of hardware you guys drug in there and setup. The full panel with LCD instruments looked great ... projectors ... this has to be the most impressive display of FlightGear stuff in one spot so far to date! The t-shirts look awesome. :-) Great job guys! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tone and decorum
But be that as it may, let's continue push this discussion back towards a positive productive direction since it is all too easy to become unproductive. Ultimately we are trying to help Erik get the 3d sound straightened out... Curt. On Thu, Nov 5, 2009 at 4:40 PM, Melchior FRANZ wrote: * John Denker -- Thursday 05 November 2009: By way of pathetic non-excuse, let me remark that a few years ago I was rather authoritatively flamed for daring to put comments in FGFS code. That's rather misleading. In fact you were criticized for: - putting whole gdb stack traces(!) before several functions in a file - outdenting comments within functions, thus making it harder to see the code's logical structure - adding needlessly verbose comments, while one the other hand ... - using bad variable names in the code, like nnn, ttt, iii in just a few lines of code. Here's an example from your patch: + nnn = props.globals.getNode(/sim/presets/ ~ varname, 1); + ttt = nnn.getType(); + value = nnn.getValue(); Could have been node and type. Or just n and t. But long *and* meaningless seemed like a bad combination. You were invited to resubmit your patch with the points fixed, and you chose not to. That's all. m. PS: beware: I can back that up with links to the archive! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Maritime/Military
On Thu, Nov 5, 2009 at 6:52 PM, Tom P wrote: Hi Martin, Vivian team This is an honest question, trying to understand the direction where we can evolve FG. Currently the models in data/Models seem to serve two purposes, and I'm wondering if they can be divided (kept in different repositories) based on the purpose? 1) static objects populating the scenery, are bound to a fixed location (buildings, structures, ...). Samples are contained in these directories: - Agriculture - Airport - Boundaries - Bridges - Buildings ... 2) Models for vehicles, ships, *crafts and anything movable: - Aircraft - Maritime/Civilian (with a few exceptions) - Maritime/Military - Transport (with a few exceptions) The fact that this last group is placed statically is, forgive my simplification, an accident of history. Any of these could be under AI or user control, and could be added dynamically to the scenery (any scenery, within certain constraints). So, in other words, would it make sense to split the location where we keep the models based on the criteria whether the model is: - truly static (buildings / structures / ...), http://scenemodels.flightgear.org/modelbrowser.php - or movable (vehicles / crafts / ships) http://cvs.flightgear.org/viewvc/data/Models/ The dream is to have all the movable ones under AI or user control one day. This may sound a little strange, but there's really nothing different about 'static' models such as buildings or radio towers or smoke stacks that would prevent them from moving around ... other than it doesn't make a lot of conceptual sense to do that. But there's nothing in how a model is created, represented, etc. that limits it to non-movable versus movable. Also in either case (movable vs. non-movable) an object could have animation components. For instance a wind turbine with blades that spin and turn into the wind, a lift bridge, an airport beacon with light beams that spin at night, a smoke stack that emits smoke, etc. So it may be worth discussion an organizational structure that separates object into likely function or usage, but as far as I know, there's nothing inherent in how the model is defined and represented that would force it into one category or the other ... other than if I see buildings chasing each other around I'd probably think that was a little weird. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures oddities in hi-rez scenery
On Wed, Nov 4, 2009 at 7:50 AM, Tim Moore timo...@redhat.com wrote: 32-bit indices are slower in OpenGL than 16-bit, so it's not desirable to switch to use longer indices everywhere, if at all. It would be better to split the scenery up into chunks that can be addressed using 16 bits. I haven't looked closely at this, but I think such a .btg file would be binary compatible with older versions of FlightGear. FlightGear uses a fixed tiling scheme. Things to consider would be the tile loading and caching scheme which makes assumptions about tile sizes and layout to maintain the local scenery cache. Another thing to consider is the boundaries between tiles. It's hard to put two or more smaller tiles up next to a larger tile without introducing a chance of pixel wide cracks ... unless the larger tile is generated with a vertex layout that matches the adjoining smaller tiles. But while we're talking about .btg file changes, I'd love to get rid of triangle strips and fans and generate optimized triangle elements at scenery generation time, rather than doing it at load time... Two thoughts ... first what you propose is more of a terragear change, probably with some mimimal extension to the .btg format. 2nd, the way we define tiles is that we have a top level .stg file that defines what is included in that tile. The .btg file is just our own custom 3d file format. There's no reason we couldn't define the base terrain as an openflight or .3ds or .ac model and load it in from the .stg file. (If we were designing this from scratch today, the .stg file would probably be an xml file that supported all the same animations, selections, sub-model references, and grouping capability as any other model xml file ... hmmm ) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures oddities in hi-rez scenery
On Tue, Nov 3, 2009 at 6:58 AM, cullam Bruce-Lockhart wrote: Hello all. I've encountered some very strange artifacts in the hi-res scenery build I'm doing of Newfoundland. I've experimented a bunch, but can't find one single thing that's causing them. It just seems as though scenery of a very high complexity causes them to happen. The main one is a sort of stretching of the textures, that seems to actually break the fundamental way they are assigned. I've got a detailed description with screenshots of what's going on here: www.cullam.com/flightgear.htm If you've ever built some very fancy scenery, or know about how the architecture of texture assignment works, check it out, and I'd love to hear some suggestions as to what might be causing this! And I appologize for the terrible looking site. I literally just threw it together to ask this question. I'm hoping to eventually make it a useful resource for scenery builders. Hi Cullam, The way scenery files are structured is this: (off the top of my head) - There is a list of vertices - There is a list of normals - There is a list of texture coordinates After this there are lists of structures that link a vertex index + normal index + texture coordinate index. The problem (most likely) is that the structure size of the index is a 16 bit signed word. This means once you exceed 32767 texture coordinates, the mapping will go all goofy on you. I had a local mod here that switched to using unsigned indices which doubles your capacity, but in high res scenery, even this is easy to exceed. I think this also required a change on the FlightGear side (but it was backwards compatible.) I was exploring this about the same time that Martin and Ralf were diverging with their own scenery efforts and it was part of a last minute hack job trying to complete an internal work project at the time. So I never attempted to integrate my updates into MartinRalf's source. So essentially you are running into a fundamental/structural limitation of the FlightGear binary scenery format (at least in it's current version.) At some point we should look at increasing the texture index to a larger number of bits, but this will also increase the size of the all the scenery files, so it's not without any trade offs. Also, when you hit this limit, you are pushing a lot of triangles, so it could be argued that from a real time rendering perspective for an average PC, it might be worth trying to simplify and consolidate structures to stay within this limit. (Again, it would be better to not have this built in limit, but when you exceed it, you are starting to push into an area where your scenerey will likely bog down many of our user's computers.) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Access flight data with an external application in realtime.
2009/10/31 Ørjan Pettersen orj...@stud.cs.uit.no Hello! I was planning on using FG as a UAV test platform. The idea was to have a demo flight with takeoff and landing on about 10 minutes. And during that flight I would gather flight data with an external program. Data like GPS position, airspeed, height and so on. Is there an easy way to access different flight data from an external application during flight? The first way that come in mind is to connect to it in multiplayer mode. But, since I never have tested multiplayer, I don't know what information that is sent out to the other players. Or perhaps using the Paparazzi project to control the plane, and gather data from Paparazzi instead? Does anyone have any thoughts on how this can be done? I think the easiest way to proceed would be to use the FGNetFDM (--native) protocol or the --generic protocol (which allows you to design custom packets with the specific fields you choose.) Both of these can send the data out as UDP packets which then can be read by your external program using standard socket communication. This same basic mechanism also would permit your external program to send control commands so if some day you want to do some sort of hardware or software in the loop testing of your uav controller, that is also a possibility. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
On Sat, Oct 31, 2009 at 9:21 AM, Erik Hofman wrote: Alright, enough of this. I've spent three full weeks trying to get the position and orientation correctly and asked several times for help but no one seems to care. Fine, it. Erik, I've seen one thread with over 100 messages on the topic and this thread is about 60 messages already, not to mention all the smaller threads and individual messages. You are the audio system expert, and I've seen tons of people pitching in to offer problem reports on their platform and test potential fixes as you propose them. I'm not sure what you are hoping for in terms of help, but I've seen more interest and participation in this process of overhauling the audio system than for just about any other issue in recent memory. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ZKV500 GPS instrument; (New?) GPS code bug
Committed, thanks! 2009/10/30 Sébastien MARQUE Hi, sorry for being absent these last days. the zkv500 is now repaired (see attached patch) at least for turnpoint mode. I'm quite sure there will have problem some problems with route management, I haven't tested yet, but I'll do this week-end. I've also fixed the screen refresh frequency, which is now more regular. if someone can commit this patch, I'll be thankfull. best regards seb -- Come build with us! The BlackBerry(R) 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/devconference ___ 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 BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] t-shirt give away
Over on the flightgear forums we are organizing a t-shirt give away contest. We are doing this on the forums because we have the ability to create polls and let people vote there. http://flightgear.org/forums/viewtopic.php?f=10t=6252 The way this works is we took nominations for names of notable recent contributors to the project. We ended up with about 50 names in 5 minutes and then discovered that our poll software has a maximum of 10 options. So what you will see is 10 deserving names, but only 10 of the 100's or 1000's that could be on the list. Fear not! I hope to make this a monthly event, and I hope that everyone keeps in mind that the whole purpose of this is to have fun and not get too bogged down with some of the details that we could get bogged down in. Torsten's wife designed the t-shirt graphics (with some valuable input from Torsten and I.) You can see the design here: http://www.cafepress.com/fgfs To help you see some of the finer points of the design: we have a simple paper airplane that flies in, does a loop, and then is trailing off in a classic phugoid manuever ... (you can just feel the geeky multi-level intelligence oozing from this design!) The flight path is actually source code from the project (we have to distribute the source code right?) :-) All of this is set against the words TEAM FLIGHTGEAR in big bold letters. It is SO cool!!! If you want to order something yourself, feel free. I would like to point out that I've set the price on all these items to be the minimum possible that cafe press allows. This means that you are seeing the base price of these items and all that money goes to cafe press to produce and ship the item ... there is no extra markup that comes back to anyone else at the end of the month. My goal is simply to make these items as accessible as I can. There are probably cheaper ways to do t-shirts, but cafe press doesn't require me to print up 100 in advance and ship them myself, and their quality is pretty good; don't expect these to fade out on the first wash; they should last for a good while. So please head over to the FlightGear forums and vote for your favorite developer. It's wide open still ... only two votes separate 1st and last place right now! Go TEAM! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear in industry use
On Tue, Oct 27, 2009 at 5:46 AM, Leonardo Fabian Grodek wrote: Hi, Looking for information on autopilots I've found this: http://www.cloudcaptech.com/piccolo_II.shtm#software In the list of downloadable software you can see Flightgear listed, with credits. I've also found this: http://www.cloudcaptech.com/download/Piccolo/Piccolo%20Documentation/Version%202.1.1%20Docs/Software/Piccolo%20Simulator.pdf Those more active than me in FG development (almost everybody but me indeed...) could feel proud of their work by seeing FG recommended by industry leaders. I got to see a Cloudcap Piccolo flying on big UAV earlier this fall (16' wing span, 150 lbs beast of an airplane). This was an older piccolo. I hear v2 is even better. Good stuff! (of course the uav stuff I'm working will be much better once it is finished.) :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Mon, Oct 26, 2009 at 4:14 AM, James Turner zakal...@mac.com wrote: If it's an optimisation-related bug, tracing it is going to be pretty awful. That said, the crash seems rather widespread for a straight compiler issue. I'm also surprised that a compiler bug would change frequency based on compile options. In my experience 99.99% of optimization bugs are not the compiler's fault. Usually there is a code problem and for whatever reason, we skate by with one set of options, but not another depending on how the compiler arranges or pads the code. If turning off optimization makes a problem go away, that's a *huge* tip that there is likely a problem in our code. It would be interesting to see what the back trace is with optimization turned on. I hate optimiser bugs :( I have yet to see one in the wild myself. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Hi Alex, Ok, based on the backtrace, this would implicate something in the gps or perhaps FGPositioned code trying to do some sort of spatial sort? Regards, Curt. On Mon, Oct 26, 2009 at 3:54 PM, Alex D-HUND wrote: It would be interesting to see what the back trace is with optimization turned on. Absolutely - unfortunately, for whatever reason, none of the people who can easily generate a backtrace, have been able to reproduce the crash - I've tried, Jester has tried, and assorted others on IRC. Hi Curtis and James and others, I am sorry, I was a bit tired last night and might not phrased myself clearly. Also I am not a coder and maybe just don't understand what you mean. But the backtraces I made actually are with optimisation turned on. Well, I built the binaries without any options on this and therefore they are -O2 by default (as far as I was able to follow Jesters explanation). Here the link again: http://nopaste.org/p/aPZTtaYYX In the meantime I have installed valgrind and I am doing my first steps with it. A first trial run turned out to be very good, I already saw the scenery ten minutes after starting it. ;-) My gcc version is: 4.3.2 (Debian 4.3.2-1.1) And enclosed you'll find the .fgfsrc file containing the options I had the day I encountered that problem the first time. Except the change for the METAR, this one replaced the real-weather-fetch. Please let me know if you need more info, as I said, I am not a coder so don't really know what to look for. Thanks Alex -- Alex D-HUND f...@beggabaur.de -- Come build with us! The BlackBerry(R) 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/devconference ___ 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 BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG Landscape disappear
2009/10/24 Mathias Fröhlich Hi, On Monday 19 October 2009 11:04:42 Martin Laabs wrote: http://www.martinlaabs.de/tmp/fgfs-screen-001.png Is this terrain somewhere near sea level in altitude or is that much higher? The question means: Is terrain loaded so that you roll in effect on that terrain and that terrain is just not not displayed. Or is the tile just not there? Hi Mathias, The place I can most reliably reproduce this problem is on a flight between KBOS and KJFK. This is relatively low terrain. When you overfly the missing tiles, your altitude and your height above terrain is identical which suggests that the tile has been completely removed from the tile cache (or perhaps mislocated?) but my guess is that it's a caching problem. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS:
On Sat, Oct 24, 2009 at 10:11 AM, Heiko Schulz aeitsch...@yahoo.de wrote: Why has a such a serious project like FGFS no real support from lawyer in such things like Flight Pro Sim? I don't know about Europe, but around here civil lawyers are not a free government provided entitlement, and they are really expensive! (Probably even more expensive than ball room dancing instructors.) So our options are (a) some real lawyer volunteers to help us out or (b) some flightgear supporter (or group of flightgear supporters) pool together to purchase the services of a real lawyer. Neither of these options has happened which is why we don't have quick access to real lawyer support when these discussions come up. We have tried to contact FSF lawyers in the past, but again, without dropping a big bag of money on the table, all we've gotten is a very cursory look and a very generic opinion (which amounted to something like we haven't come close enough to the threshold to raise any of their alarm bells.) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
On Thu, Oct 22, 2009 at 2:11 PM, syd adams wrote: Glad you mentioned the sound type, I hadn't thought about it . Same result here , looped sounds dont play ... but the rest seem to , ( Ive only tested with my aircraft). Just a little off topic, but congratulations Syd, you were the one hundredth poster to this thread! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Another person selling FlightGear on ebay
Here's a slightly different wrinkle (maybe) on this whole selling copies of FlightGear under dubious premises. In this case FlightGear is prominently displayed in the ebay ad, but later they claim: Copyright This item is copyrighted. Any reproduction, duplication or resale of any kind is strictly prohibited. Software included is either released under GNU or contains our protected IP. Copyright © 2009 MT Software Solutions. All rights reserved. Is this a problem? Here's the link so you can see it all in context: http://cgi.ebay.co.uk/Flight-Gear-Simulator-2009-for-Microsoft-Windows-Vista_W0QQitemZ180388068783QQcmdZViewItemQQptZUK_PC_Video_Games_Video_Games_JS?hash=item29fff77daf Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG Landscape disappear
On Mon, Oct 19, 2009 at 5:07 AM, Heiko Schulz aeitsch...@yahoo.de wrote: Hello all, Hello, here is another snapshot while flying which demonstrates the problem quite well: http://www.martinlaabs.de/tmp/fgfs-screen-006.png Greetings, Martin L. I have sometimes the same problems using Terragear terrain but not beeing connected to the server. (so not fetching tiles, but using the fetched tiles instead) It seems indeed to me, that tile actually under and nearest to the aircraft disappears, and appears again when it is in a certain distance. In the moment I don't have this problem using CVS from 09/13/2009, but with some older binaries I had this problem. I don't have time today to check this again, but previously I could reliably trigger this bug by flying from KBOS to KJFK. Somewhere about halfway I started seeing the problem, and by the time I would get to JFK, the tiles would be missing more than they were present. At the time I convinced myself this is a tile caching bug. Originally tiles were flushed out of the cache based on their distance from the current view point. Along the way this got changed to a time based system so that the most recently used tiles were highest priority in the cache. (This makes some sense if the view point can jump around significantly like between the tower and the aircraft when the two are far apart.) Then during the OSG port, this got further modified so that only tiles that were drawn got their time stamps updated. (That sounded like a good idea at least on paper.) This unfortunately led to a race condition that could cause a tile to be unloaded before it was properly scheduled. Even worse, the current tile that you are over the top of could be missing when you did a reposition, and because it had already been scheduled for loading, it was never scheduled again. But in the mean time it had been flushed from the cache so it was no longer there. Oh, and by the way, the FDM needed a ground height query to succeed before it could re-init, so this led to a deadlock and hang. We did a small bit of massage on the OSG logic and that fixed the one reliable test case I had at the time. However, a similar missing tile problem resurfaced later on during a KBOS-KJFK flight. So I still think this is a tile caching issue. The contributing factors to consider (I think) are: - time based aging of cache entries may not be the best approach, especially in a situation where you could potentially remove a tile that is literally underneath you if it's never actually entered the view frustum. Also considering that an aircraft could turn 180 degrees suddenly, a distance base cache aging scheme might be better? - The AI and multplayer system? Since all the cache aging code was written, we've added features for doing terrain height queries. AI aircraft and even nasal scripts can now query the terrain system to return the terrain height for any arbitrary location or even the terrain intersection with any aribitrary vector. Could this code be causing tiles from outside the view to get referenced and then tiles underneath the viewer end up getting removed to make room? Do we need to think through the tile intersection query semantics in the context of the tile cache scheme to make sure we haven't overlooked something? These are my thoughts ... I haven't had a chance to fully investigate. It would be great if some of you seeing the problem could try the KBOS-KJFK route to see if this triggers the bug for you. And those of you who haven't seen this problem could try the flight as well to see if you also have this bug. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] least squares code
2009/10/17 Mathias Fröhlich mathias.froehl...@gmx.net As always, tell the exact problem. Depending on your problem and requirements the solution ranges from a few lines of code to - 'better use an implementation that already exists is tested and is numerically stable'. Hi Mathias, I will be receiving a sequence of 2d data points in real time. I will start by assuming a linear relationship/fit which I know in advance is a reasonable assumption. I would like to find a way to incrementally compute a simple straight line least squares fit of the data I have received so far. I know incremental approaches exist. Isaias sent me a simple approach, but this maintains sums of all the data received so far and as Alex pointed out, that will be subject to increasing round off errors as the data accumulates (this code could be receiving hundreds of data points per second over the course of hours, days, even weeks.) So yes, a numerically stable approach is important. I suspect the code will just be a few lines, so if I can find an approach that is laid out algorithmically or in terms of some sort of pseudo-code, I'm pretty sure I can create and test my own implementation. Maybe I'm only imagining that such a thing exists, I googled for quite a while yesterday on a variety of search terms that are directly or loosely related and wasn't able to turn up what I was hoping to find. (Thus my cry for help) :-) A method that forgets the oldest data and weights newer data more heavily might also be interesting (versus an approach that sums up the entire history of the data ... although that would be ok too.) I'm happy to start simple and get fancier later on if I need to. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] least squares code
I'm having a duh moment here ... I've googled and looked through my old college text books and can't find something that I think should be easy to find. I'm probably forgetting the proper name of the technique or something stupid. The basic formulas for least squares fitting of a line to a set of data are well know. (I'm referring to the standard linear least squares fit of a line to some data.) I know I've seen a derivation of these formulas that allow you to incrementally build your least squares solution as each data point comes in (based on the current data and the past solution.) I know I've seen this several places in my life, even recently. I'd rather not spend a week re-deriving the formulas from scratch and testing and debugging. Does anyone have a link or pointer to basic code or psuedo-code that implements this incremental (recursive?) least squares approach? Thanks in advance, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sun, Oct 11, 2009 at 3:39 AM, Alan Teeder wrote: First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. I think what Lee(e) may be observing is that when you tune an autopilot to behave well when the update rate is 60hz, and then fly into an area of complex scenery + effects the frame rate in FlightGear can drop substantially. In this situation, the autopilot (which is running at the same update rate as the graphics) can go unstable, leading to wild oscillations. Presumably this is an entirely different issue than what Pete is dealing with, and neither of these contradict anything you have said. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Sun, Oct 11, 2009 at 4:53 PM, James Turner zakal...@mac.com wrote: On 9 Oct 2009, at 01:06, Curtis Olson wrote: Is there still a missing connection in the code, or is the missing connection in my head? :-) Given that there is probably a beta coming up, I've just committed a 'fix' (more like a hack, but it's all about your point of view) that restores the critical connection from the route-manager to the AP. It should even work for altitudes (un-tested!). The behaviour can be disabled via a new config-flag, so realistic systems can stop the route-manager upsetting them, but the default value is 'on', for minimal surprise to existing users. Note I haven't (yet) fixed the filtering, so starting at KLAX one does still get the heliport, I'll fix that in the next day or two. Since the dialog updating bug is fixed, you can now enter KLAX-KPHX, hit 'activate', and use true-heading-hold in the generic AP as before. (Note the route-manager doesn't calculate some values until you are airborne, at present, to avoid numerical weirdness when speed and heading are unclear). I may also make the GPS fully generic, and then add a similar config flag (or more likely, share it) so that any aircraft can use the functionality - again, this will take a couple of days for me to convince myself about the ramifications for modelling realistic devices. Hi James, Thanks for looking into this. I'm going to be tied up with work and out of town most of this coming week so I probably won't get a chance to test this out until next weekend or the week following. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
I haven't looked at these autopilot configurations (at least not for a long time) but off the top of my head, I think this can all be fixed by tuning the autopilot. For instance, lowering the max aileron deflection from (-1 ... 1) down to maybe (-0.1 ... 0.1) might be an interesting thing to start with. These are normalized values so +/-1 represents full deflection and 0.1 represents 1/10th of full deflection. If the autopilot is hitting you with full instantaneous aileron deflection that might be part of the issue. The other thing to look at is tuning the actual PID gains. These are obscured a bit given that we are using a slightly different form of the PID algorithm compared to what you might see in a Control Theory-101 class. I believe there is an autopilot tuning README and it just takes some fiddling around to see what changing the different values will accomplish. There's an art (maybe part science) to tuning autopilots ... I've yet to meet an expert in that area, but they must exist ... they are probably locked in the basement of Airbus and Boeing and various UAV companies and not allowed to leave their cells. :-) Curt. On Sat, Oct 10, 2009 at 1:56 PM, Pete Morgan ac...@daffodil.uk.com wrote: I'm working on my motion sim for xmas. Its powered by a vacum cleaner atmo.. One BIG BIG problem - am basicng the cockpit on Bravo and 787 The autopilot heading bug is very violent and JERKS to direction.. How can we solve that problem please because on my motion platform, I cant keep up with the drastric movements. Actually I can, but this is where there is a problem.. the behaviour of bank is performing well with the Ardiono/pneumatics card firing off the valves, however the violent values from the autopilot when auto pilot is engaged is causing a problem.. I've damped it down in my arduino/python middle man code, But I think this problem is an actual flightgear problem.. Any one offer me some advice which area of code to look at please... eg I could damp it in nasal script ? pete -- Come build with us! The BlackBerry(R) 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/devconference ___ 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 BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sat, Oct 10, 2009 at 3:23 PM, Heiko Schulz aeitsch...@yahoo.de wrote: If you mean this sudden banking when after reaching a new wayoint: yes. It is known and is still on the bug-list on flightgear.org anywhere. There were some aircraft authors who had a workaround with nasal- to my knowledge the 787 Forums-version and so much as I know the 777 by Syd had this also. With the work by James Turner now on the GPS and Route-Manager it would be nice we could solve that. Bu Mega-fault is a bit hard said- the people here are working for free and in their spare-time beside Job, family and other hobbies Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. FlightGear also doesn't model how much load the airframe can endure before pieces began to depart and go their own separate ways. Thus assuming infinite control surface deflection rates and perfectly rigid and robust airframe, and assuming the flight dynamics are configured correctly, what you see is a realistic response. You can tune the control surface movement rates and maximum deflection angles in the autopilot configuration for each aircraft. This would be an excellent place to start. This isn't a systemic FlightGear problem, it's an autopilot configuration problem that seems to be replicated across many aircraft. But tuning autopilots is hard for most people, and probably for most aircraft authors so this is an area that is not attended to very well. You might be imagining that FlightGear has a single universal autopilot that runs all airplanes the same way, and you'd be wrong. There is an individual config file that sets up the cascading stages and inputs and reference values and outputs for each stage. You can do a lot of neat stuff with it, but if it's not well tuned you'll get a lot of unstable behavior. For what it's worth I recently saw a very expensive UAV flying with a poorly tuned autopilot and the result was not smooth and graceful whereas the aircraft flew beautifully under manual control. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrascenery.googlecode.com question
I see that terrascenery.googlecode.com includes a Models/ directory. If I leave this as is, does this directory get searched for models or do I need to copy this over the top of $FGROOT/data/Models/ Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New route manager?
Are there instructions for the new route mgr? The new version in CVS doesn't not work like before. I added two waypoints, but it just flies a hdg of 0 and doesn't track to the next waypoint any more ... ??? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrascenery.googlecode.com question
Thanks Martin, that's a handy option. Curt. On Thu, Oct 8, 2009 at 8:58 AM, Martin Spott wrote: Curtis Olson wrote: [-- multipart/alternative, Encoding 7bit, 2 Zeilen --] [-- text/plain, Encoding 7bit, Zeichensatz: ISO-8859-1, 10 Zeilen --] I see that terrascenery.googlecode.com includes a Models/ directory. If I leave this as is, does this directory get searched for models or do I need to copy this over the top of $FGROOT/data/Models/ http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commit;h=82a68740f196e57f7dca155ba8fd88bbc94466c4 Just added recently, requires: --prop:/sim/paths/use-custom-scenery-data=true Many thanks to Durk ! This actually allows users of TerraSync/SVN to get the most current Shared Models together with the respective Scenery tiles. I'm just right now testing the patch against TerraSync to pull this directory as well. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) 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/devconference ___ 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 BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Thu, Oct 8, 2009 at 10:05 AM, James Turner zakal...@mac.com wrote: On 8 Oct 2009, at 15:17, Curtis Olson wrote: Are there instructions for the new route mgr? The new version in CVS doesn't not work like before. I added two waypoints, but it just flies a hdg of 0 and doesn't track to the next waypoint any more ... ??? http://wiki.flightgear.org/index.php/Route_Manager Is the current instructions, feedback is welcomed. Ok, I started up in the alphajet for instance at KLAX (7L). I pulled up the new route manager dialog and it suggested CL02 H1 as the starting location. I set that to KLAX-7L for the start and typed in KPHX for the destination, KSLC for the alternate, cruising speed of 350kts, cruising altitude of 18,500. I then clicked Activate and it still inserted CL02-H1 for the first waypoint and that's it. I removed CL02 and clicked activate again, and this time it put KLAX-07 for the first way point and then put KPHX in twice. So I manually manipulated the list so it contained only one waypoint ... KPHX. Ok! So now the HUD read hdg=0.0 which means the autopilot is configured to fly a straight heading of 0 degrees north. What used to happen is the route manager would compute the heading to the target waypoint, and configure the autopilot to fly that heading. This part apparently doesn't happen any more .. at least not with the alphajet? I like the realism of the new system (assuming the glitches are ironed out). But the old system was designed to be simple and quick and ubiquitous ... it was available and worked for all aircraft assuming they had a reasonably tuned autopilot config and the aircraft author didn't go out of their way to disable it. The old system took 1 second to punch in a way point, and then the autopilot instantly took over and you were flying there. You could use F6 to toggle the heading hold on and off. Not a *realistic* system, but very convenient for some types of testing (or cheating). Is it possible to keep the old simple/easy system available and make the new route manager a new separate system? Right now I don't seem to be able to get the alphajet to navigate to Phoenix (or anywhere else) on it's own. I wasn't really intending to go to Phoenix today, I was just using that as an example. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Thu, Oct 8, 2009 at 10:54 AM, James Turner zakal...@mac.com wrote: This is a straight bug, I'll look into it. If you are sitting at KLAX 7L, it's supposed to load up that airport and runway automatically. Ok, thanks for looking into it. As you suggest, filtering out heliports and seaports by default might be worth considering. I suspect the HUD functionality is confused, I was unaware it even existed, again I'll take a look tonight. What the original route manager did was constantly compute the heading to the next waypoint and dump that value into /autopilot/settings/true-heading-deg Then the autopilot could be activated in true-heading-follow mode and you would fly right to the destination. I just did a cvs update and I see a number of fixes, but I'm still confused about how to make the autopilot follow what the new route manager is doing? I opened up the gps dialog box and checked NAV Slave, but when I put the autopilot into NAV1 CDI Course follow mode, it flew a heading of 40 degrees where the proper heading would be closer to 274. Is there still a missing connection in the code, or is the missing connection in my head? :-) Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots as PNGs
On Wed, Oct 7, 2009 at 8:57 AM, Ron Jensen wrote: One man's feature is another man's bug. :) While admittedly most screen shots don't want the UI shown, a very large percentage of screen shots I've shared were created to show the UI components as part of a tutorial or to demonstrate an issue. I would prefer the screen shot code to generate an image identical to what is shown on the screen. ... and if you don't want any gui elements in your screenshot, it's easy enough to turn them all off and use the F3 hot key to take the snapshot. (Close all the dialog boxes, and then F10 toggles the menu on/off) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
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/devconference ___ Flightgear-devel mailing listflightgear-de...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) 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/devconference ___ 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 BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
On Wed, Oct 7, 2009 at 10:33 AM, Durk Talsma d.tal...@xs4all.nl wrote: On Wednesday 07 October 2009 11:18:07 am Stuart Buchanan wrote: I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. FWIW, I've run into one situation where the new cloud code significantly slowed down my system. I found that reducing the range setting from 20km to approximately 11-12 kilometers gave me back decent performance, without too mach sacrificing of detail. It seemed to be a rather sharp transition, so I'm wondering whether texture memory use has something to do with it. Just thinking out loud, Would it be feasable to impement some sort of LOD scheme, where sprites are dynamically added as they are getting closer? That way, it might be possible to have clouds across a much larger area with as much of an impact on performance. I also noticed a huge frame rate drop when I was in or close to being in the cloud layer, so that the clouds consumed the greatest percentage of the screen real estate ... that is when the frame rates were the worst. If we are drawing zillions of transparent quads and suddenly they are sized to cover nearly the whole screen, then we are basically rendering the whole screen (or most of the screen) for each cloud quad, or enough of them that are near by to pull the frame rates down to very low levels. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) 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/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Tue, Oct 6, 2009 at 3:19 AM, AJ MacLeod wrote: On Monday 05 October 2009 22:34:01 Thomas Betka wrote: I really didn't hear many people even mention the IFR training opportunity that is being missed with FG; shoot, most people I talked to 1-2 years ago (when I was trying to learn how to modify the 2D panel in the 172) couldn't understand why I was even wasting my time by not going 3D! We understood and understand perfectly what you were trying to achieve, and having plenty of experience in the task knew that it was not only possible to achieve it with 3D instruments, but that it would be easier, quicker and more flexible. You're always welcome to ignore good advice and plod on doing things any sub-optimal way you please... but it's fairly bad manners to dismiss those who give that advice as uncomprehending idiots. How about precise orthogonal placement and sizing of the instruments on the screen down to pixel level fine tuning so that you can draw them exactly in the right place to show through a panel cutout? http://www.atcflightsim.com/products/820/Link/810M_001.html With 3d instruments you have an infinite variety of head positions relative to instrument positions, etc. With a 2d panel you can adjust a number in the placement xml file and reload the panel on the fly. You can even do that over an ssh connection with remote eyes giving feedback over the phone. I actually don't see how the additional layer of complexity involved with passing all the geometry through an extra transform, combined with requiring the use of a 3d modeling tool makes 3d panels easier to use, easier to develop, and visually more precise than 2d panels. (There could be a discussion of capability differences, but so far the 2d panels have had all the capability I've needed for my own projects.) Best regards, Curt. -- 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
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Tue, Oct 6, 2009 at 7:57 AM, Tim Moore timo...@redhat.com wrote: 3D panel does not mean that you need a 3D view of the cockpit to see the instruments. I guess I've never seen an example of anyone configuring an orthographic view in FlightGear, but I'm sure it's doable. Do we have configuration level support for this, or would it be a coding exercise? The other part is that the designer would need to carefully align the panel surface orthogonal to the view direction to assure there is no warping of the panel relative to the view plane, again, should be a relatively simple task, but would need to be done and need to be thought about. So it's definitely a solvable problem, but there are several extra steps, and I haven't seen an example to work from within FlightGear. And generally, if it's never been done before, the first person blazing the path will typically run into some unexpected surprises. Regards, Curt. -- 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
Re: [Flightgear-devel] RSync for TerraSync down
We've got a round robin setup for scenery.flightgear.org $ host scenery.flightgear.org scenery.flightgear.org has address 128.101.141.136 scenery.flightgear.org has address 67.202.82.26 128.101.141.136 has it's rsync server running, but maybe 67.202.82.26 needs to have it's rsync daemon checked? I'm not sure who maintains the machine, but if it's no longer online and being maintained, we can take it out of the rotation. Curt. On Tue, Oct 6, 2009 at 11:53 AM, Daniel Vigano wrote: Hello, if I want use TerraSync with RSync this message appears: rsync: failed to connect to scenery.flightgear.org: Connection timed out (110) rsync error: error in socket IO (code 10) at clientserver.c(124) [receiver=3.0.5] I think the RSync server is down. Daniel -- 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 -- 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
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Tue, Oct 6, 2009 at 1:33 PM, Detlef Faber fa...@sol2500.net wrote: The german section of Openoffice.org contains such a warning too. I would really appreciate this. And we could stop the advertising of this product on the FlightGear site. I can look into it, but I'll say this purely from a humorous/hypothetical perspective: if anyone understands how adsense work, any time one of us clicks on his ad, it costs him money, but google has very sophisticated filters to catch this any many other kinds of abuse so a single person can't do much on that front. I can't bring myself to be this sleazy and it wouldn't reflect positively on the flightgear project (but it's fun to think about) :-) so what if I could add some text that says: if the ad in this box is from xyz.com, click on it as many times as possible, email all your contacts to also click on it, but make sure you don't buy anything. I shouldn't even think things like that, let alone post them ... ! Curt. -- 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
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Mon, Oct 5, 2009 at 7:28 AM, Heiko Schulz aeitsch...@yahoo.de wrote: I really would like to admit your sentences. But - on their website I can't see any reference, hint or link to Project FlightGear. But I see that he earns money with our work. I do know that this allowed under or licence. But is this moral? I do understand that he sells this without any offical reference to FlightGear- if he woulden't no one would buy it because it is downloadable for free for anyone. I can see other big OpenSource Projects like Blender, which have have this kind of support- without beeing sold. If really both sides wants to win, then we should make a derivative work of FGFS like a FAA-licenced, one which is beeing sold then. That would really help this project to gain some more respect and even a lot of more seriousness to our project. Even now, as Microsoft ESP is stopped and Aerososft is coming with a replacement 2012. Just my thoughts, correct me If I'm wrong with some facts. There is a PC-ATD certification, but if you read the spec, it requires certain things with control inputs that you cannot achieve with a $20 walmart joystick. We meet most of the spec, but there are a few gaps that go beyond just software. Take a look at http://www.sf.net/projects/fgatd/ However, the PC-ATD certification is very limited in terms of how many hours you can log with it. For more serious pilot / IFR training, the entry level is usually Advanced ATD certification, (or more historically Level 3 FTD certification.) However, these certifications are for the whole simulator, and not just a certification for a software application. In fact, the idea of getting FAA certification for a software application is really misleading because it's not something that they directly do. They certify a whole simulator which includes software, flight dynamics, physical controls (with correct size, placement, and control loading), and often a full enclosure, as well as a visual system. Interesting things that are required for Advanced ATD certification are a GPS and a Flight Director/Autopilot. If you read that X-Plane is FAA certified, they certainly mean that X-Plane was one component in an FAA certified simulator, not that the software itself is FAA certified, however they don't work very hard to make that distinction clear to their users. For the Official Record: FlightGear is also been a key software component in several FAA certified simulators, just like X-Plane. So we can make the same claims that they are able to make (if we want to be misleading.) I've been involved in the FAA certification process and my experience is that if you (a) meet the certification requirements that the FAA lays out (which is doable but a lot of work) and (b) you schedule an FAA inspector to come on sight and verify that you meet the requirements and sign off on it, then you too can have an FAA certified simulator. The inspectors I've dealt with have been very fair and generally look more towards ways to pass you instead of trying to find any little thing they can fail you on. Interestingly, for the Level 3 FTD certification, the FAA requires that each installation be individually certified. Even if you relocate the simulator, you need to have an FAA inspector come out and recertify the sim. It's my understanding that for an Advanced ATD certification (which allows you to log essentially the same things as Level 3 FTD) the FAA certifies a product and then you can replicate it and sell it and the FAA doesn't need to come out and sign off on each one. Fun stuff ... there's nothing here that FlightGear can't already do, it's just a matter of going through a sometimes an intense amount of work to pull all the pieces together and verify and document that the entire simulator as a whole meets all the requirements and there is a lot more to it than just software work. Regards, Curt. -- 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
Re: [Flightgear-devel] Minor GUI Update
On Mon, Oct 5, 2009 at 3:00 AM, Stuart Buchanan wrote: The main reason for including it is that I find that I rarely want to play the replay from the cockpit. I'm typically trying to judge how good my 3-point taildragger landing was, which is best done from a different view. I'm guessing most people use replays to see what happened from a different viewpoint. As Tom points you, you can change view very quickly. However, we now have a very large number of different views, and aircraft can (and do) add their own. While developers like ourselves are very au-fait with cycling between the views, I think more in-experienced users may struggle. Some may not even be aware that other views are available. Providing a convenient way for the user to select their initial view, and in particular using the view names themselves makes things a lot easier. Note that the drop-down defaults to the currently selected view, so there's no change in function if you just press OK. I don't know if this would overly clutter the gui, but perhaps it would be useful to add a short blurb reminding the user that they can still change views using the normal mechanism during the replay. My initial reaction when I first saw the view selection dialog box was that I wondered if people might think that by offering a dialog box, their choice would lock them into a specific view for the entire replay? Here's a random idea ... thinking as I type here ... What about adding a view selection dialog box to the main menu bar that users can easily find and use during all phases of flight and during replay? Adding an easy to use menu/dialog box option is the way to counter hidden keyboard commands that many new users might not stumble upon for quite a while ... ? Regards, Curt. -- 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
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Mon, Oct 5, 2009 at 11:34 AM, Heiko Schulz aeitsch...@yahoo.de wrote: To be more clear: Quote from http://www.x-plane.com/pg_levels.html In other words, the copy of X-Plane that can be purchased right here for under $50 has all the features required for FAA certification built in--you just have to buy USB keys (one per computer) to unlockthem all! Please note that using these keys makes X-Plane certifiable by the FAA; it does not automatically confer certified status. The FAA only certifies the combination of the hardware and the software used in a simulator, and users who want to certify their sim must do so through the FAA. Ok, sounds like they've clarified their web page since I saw it. This sounds reasonably fair, except they don't say what specific FAA certification. I can fill in myself that it's probably Advanced ATD, but it would be helpful if they state that. Of course you still need some professional controlls, cockpits etc. to be fully FAA-certified at least. So does our last stable version 1.9.1 does have all features needed to be certifiable by the FAA ? I think we are pretty close. A GPS might be one outstanding item, but Dave Luff has done a tone of work on a KLN-89 emulator. It may very well be that it is already far enough along to satisfy FAA requirement Advanced ATD requirements, but I don't know for sure yet. I don't believe they require a GPS that is certified for instrument approaches, however, that's something that a lot of people want so it's a good thing to have. Really? Let's pull the software pieces together and sell them for a cheaper price than X-Plane... We we have the pieces, we have the price point. The problem is that building an FAA certifyable simulator is still a *lot* of work!!! That's why it often remains in the domain of for profit businesses because they have access to the resources and funds to engineer and build enclosures, physical flight controls, realistic instrument panels, do motion bases, wrap around visual systems, and pull all the pieces together into a solid, easy to use simulator that can be handed off to a non-technical person to use. That's still a very hard and very time consuming process, even if all the software components are ready to go. Ask anyone who's built a cockpit themselves ... it's a ton of work. But it's a great hobby and if anyone is thinking about trying, it will be a tremendous learning experience for you and if you are successful at many of the tasks that are needed, you will develop real, marketable skills. Regards, Curt. -- 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
Re: [Flightgear-devel] October $250 Flight Gear Developers
On Mon, Oct 5, 2009 at 12:56 PM, Heiko Schulz aeitsch...@yahoo.de wrote: So it is just the GPS? Or still more? As with all things, it's maybe not that simple. We can already plug in a real gps and run with that. I've messed with a Garmin 295 and a Garmin 400 (which means we should be able to support a real G430/530 as well.) So it depends what gps you want and if you don't mind putting in a real one, or if you want a full software emulation, and if you want a software emulation, how far do you have to go? Is it just some basic features we need or do we need to mimic the entire thing down to the boot messages, and correct satellite positions for the date/time? Pretty close does not mean in my eyes that we are FAA-certificable yet- But woulden't be that a nice goal to be? Well again, I can sit here and say anything, but the reality is that no matter how much work we do in advance, when it comes down to putting *your* system together, you'll find things that are missing or not quite the way you want them and you will want to do extra work. A good instructor station is another items that is missing from the open-source world. The instructor station I've worked with in my FAA certification efforts has been a commercial product that talks to flightgear via it's network interfaces. What it boils down to, is that anyone who is going through the actual process to achieve FAA certification, is going to be doing it for business reasons (at some level.) So there's a careful dance that goes on to protect business interests at the same time as participating in and supporting open-source goals. It's easy to chit chat about these things and toss wishful thinking back and forth, but how many people have actually dug in and read the FAA certification specs? The people who have are probably the ones actually pushing forward with a FlightGear based certified simulator product. The reason FlightGear is currently being used as part of FAA certified simulators is that it's easily good enough for that purpose, and has many advantages in terms of openness, adaptability, interfaceability, extensibility, and cost. The reason we haven't pushed for some sort of blanket certification is that so far, the people going through the process have been working for their own business interests, contributing back the open-source changes to be sure, but also not giving away the complete store when they do something separate to achieve the final certification status. Even the lowly PC-ATD certification ... we have a project for that, but how many people have signed up to advance that forward? The people that want to get to FAA certification with FlightGear can do it already, but building an FAA certified simulator is very time consuming and costly and generally a significant distance beyond what a hobbiest would have time or motivation to achieve? What is FAA certification good for? Answer: so that you can log hours in the simulator and save money/time over practicing certain tasks in a real aircraft. It's no where near cost (or time) effective to build your own sim for your own personal training. The only way it makes any kind of financial sense is if you are a school and offering sim time to your students. In that case it's way more effiicent to buy something existing than build it yourself. FAA Certification == ability to sell hours in your sim. FAA certification == lots of cost and effort. There's not a lot of motivation within the hobby community to jump into that world, and if you do jump into that world, you might as well make a few bucks from all your time and effort. I see I'm going in circles here so it's time to stop. :-) Best regards, Curt. -- 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
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/misc strutils.cxx, 1.4, 1.5 strutils.hxx, 1.4, 1.5
Hi Jim, Thanks for the quick fix on the strutils. In this case, (haha, so to speak) yes, I think if code is already referencing OpenGL, then it would be fair to replace that with code that references OSG. And yes, if you can generate png's instead of the 42x larger ppm format, that would be a big nice convenience. Thanks! Curt. On Mon, Oct 5, 2009 at 4:54 PM, James Turner zakal...@mac.com wrote: On 30 Sep 2009, at 19:44, Curtis Olson wrote: I just noticed you added an OSG dependency to strutils.cxx/hxx If possible it would be nice to avoid adding graphics system dependencies to these text manipulation libraries. SimGear and SimGear code is used in a variety of places beyond FlightGear, even in embedded systems where compiling opengl and OSG is completely impossible. I have a pending change to replace the screenshot code in SimGear (simgear/screen/screen-dump.cxx) with a version using osgDB. The major advantage being that we would create screenshots as .pngs instead of PPMs. Is it 'safe' (from your point of view) to use OSG code in this place? It's already code that directly calls OpenGL, so I *guess* it's not used on your embedded device? Regards, James -- 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 -- 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
Re: [Flightgear-devel] Minor GUI Update
On Sun, Oct 4, 2009 at 3:53 PM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: Hi All, I've just updated the Instant Replay dialog with two small enhancements: - A short list of useful keys. This is partly because I can never remember that p p is used to end the replay, and from discussions elsewhere, it seems other people forget this too. - A dynamic view selection combo box to select the view for the replay. This replaces the previous (broken) view selection combo, and includes all the configured views. Comments are welcome as always. Hi Stuart, One comment/question. I never understood the inclusion of a view selection box for the replay? When I run the replay I'm usually flipping all around between views using the normal view selection keys, and often panning the view with the mouse. It's very rare that I sit and watch an entire replay from a fixed view that I decided upon at the start of the replay. I could be the oddball, and it doesn't hurt anything to have a view selection dialog box ... just making a comment. :-) Thanks, Curt. -- 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
Re: [Flightgear-devel] New Sound system committed
On Sun, Oct 4, 2009 at 9:05 AM, Erik Hofman wrote: Allright, the new sound system has been committed. The basics works as follow: There is one SoundMgr that handles multiple SoundGroup classes. Each SoundGroup class handles multiple SoundSample classes. A SoundSample class defines the properties of each individual sound like pitch, volume, position, orientation, sound cone paramters, etc. This class can be created all over the code but *has* to be assigned to a SampelGroup before you can hear it. Current sample groups are atc, avionics and fx for the master airplane effects. The position of a SoundSample is relative to (0,0,0) of the model and hence relative to the base position of the SampleGroup. A SampleGroup class has to be assigned to the SoundManager to be heard and holds data of a group of samples (maybe 'sample cloud' might be a good description). This class has to be created for each individual model that can produce one or more sounds. The SampleGroup class can be altered by modifying it's volume, position and orientation. Repositioning this class also means repositioning all it's associated samples. Altering it's orientation also means repositioning the absolute (real world) position (and orientation) of the associated sound samples. The SoundMagaer can be repositioned which basically means moving the listener around. It's also possible to alter the listener orientation en velocity with this class, together with the master volume. Hi Erik, One quick question: will the sound configuration xml files need to change to match the new system or will there be backwards compatibility? Thanks, Curt. -- 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
Re: [Flightgear-devel] Discussion: contests and awards
On Fri, Oct 2, 2009 at 1:41 PM, Erik Hofman wrote: There's one problem that comes up; At the moment I am working on updating the Sound System. While I'm not claiming this would be a contender for the contest it's clear to me that I needed help for it in some parts. Who's going to win then? After all, FlightGear is and will be, a joint effort in the end. Hi Erik, Don't worry, I only know 3 people in the FlightGear project who would jump in at the last second like that and claim all the credit ... and they've shared the prizes already for the last 6 months so someone else is due real soon now. So all you need to do is come up with yet another really cool idea now and finish it since one of them already claimed the current and any future audio system. (Hopefully that is read as some Friday afternoon humor with lots of smiley's) :-) :-) :-) But more seriously, there's no perfect system, and I was imagining a for-fun contest with a t-shirt or coffee mug as the prize ... more symbolic than anything ... except the winner now has something that only a very select group of other people would have. I was thinking of something that would be fun where we could cheer each other on and encourage each other. I think when it comes down to it, it would be pretty clear who put in the work for a particular feature. And in the case of shared effort on a particular feature ... I don't know, maybe we could find some benefactor who would be willing to sponsor additional prizes. If it was a really close call, I'd probably be willing to dig into my own pocket once in a while to help out. The intent for this particular style of contest would be just for fun. And if someone *really* just wanted a t-shirt and mug, I could send them the top secret link to the cafepress.com page where they could order one themselves. :-) Regards, Curt. -- 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
Re: [Flightgear-devel] bug tracking
I agree that a bug tracking system is a good thing. My thoughts hopes are that once we finalized what we were doing with our eventual move away from CVS, We would move our code to a system that offers a number of developer features including an integrated bug tracker. Google does offer a nice system, but long term, it would be nice to just use the bug tracker associated with our project, rather than setup a completely new project and only use the bug tracker out of it. Curt. On Wed, Sep 30, 2009 at 11:12 AM, Pete Morgan ac...@daffodil.uk.com wrote: Just the word bug and track are enough to scare pilots. So The concept is to set up a tracking system for bugs. So u must have at least one winge.. http://code.google.com/p/flightgear-bugs/ lets fix them ;-) pete -- 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 -- 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
Re: [Flightgear-devel] bug tracking
On Wed, Sep 30, 2009 at 11:58 AM, Pete Morgan ac...@daffodil.uk.com wrote: Curtis Olson wrote: I agree that a bug tracking system is a good thing. My thoughts hopes are that once we finalized what we were doing with our eventual move away from CVS, We would move our code to a system that offers a number of developer features including an integrated bug tracker. Google does offer a nice system, but long term, it would be nice to just use the bug tracker associated with our project, rather than setup a completely new project and only use the bug tracker out of it. Curt. for me as an intermediate user, If there is a facility to report bugs ie PIEPR's then that would be cool. So at the moment This site is for identifying bugs only.. No less or more. It will be seperate atmo from source.. However recognising the bugs is THE issue. eg one of the three paths 1) dont set up a bug tracker and ignoire them 2) Have a bug tracker and then ignore them 3) Have an active bug tracer and identify problem area and resolve issue.. 4) Send a report to the developers that there is a bug u need to fix.. Curtis .. please endorse and go for this bucktracker please.. At least that way we can all complain until we sort it.. ;-) this way it will be a steady eddie ;-) the SCM is another issue I'd be more inclined to use the bug trackers at http://code.google.com/p/simgear and http://code.google.com/p/flightgear but those sites are currently tied up with svn versus git versus hg discussions. Personally I think it could turn into a mess if we fill up this new site with a bunch of bug reports and then have no way to move them to the official site(s) later. We also have bug trackers available at our sourceforge registered projects. I always felt the sourceforge bug tracker was kind of slow and clunky. The google bug tracker seems much nicer, and it appears it is integrated with the repository so you can reference specific patches or branches. That would be harder to do if the bug tracker lived at a completely separate project name. We lose much of the cool functionality that google offers. Regards, Curt. -- 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
Re: [Flightgear-devel] bug tracking
I'm just not sure how productive it is to register yet another separate google project simply to use the bug tracker. Why not use the bug tracker at code.google.com/p/flightgear? I've been holding off pushing any particular bug tracking system, because it really makes a lot of sense to co-locate the bug tracking system with the code. Regards, Curt. On Wed, Sep 30, 2009 at 12:18 PM, Pete Morgan ac...@daffodil.uk.com wrote: Precisley the problem is that me as amuppet doth not know where the issue ie at, and where to report. So at least if we can point users to a particular point, then they can be filtered and sorted. therby dipatched to the concerned. At the moment its real crap.. so at least I want to use google issues as a common complaints dept, for delegation pete Curtis Olson wrote: On Wed, Sep 30, 2009 at 11:58 AM, Pete Morgan ac...@daffodil.uk.com mailto:ac...@daffodil.uk.com wrote: Curtis Olson wrote: I agree that a bug tracking system is a good thing. My thoughts hopes are that once we finalized what we were doing with our eventual move away from CVS, We would move our code to a system that offers a number of developer features including an integrated bug tracker. Google does offer a nice system, but long term, it would be nice to just use the bug tracker associated with our project, rather than setup a completely new project and only use the bug tracker out of it. Curt. for me as an intermediate user, If there is a facility to report bugs ie PIEPR's then that would be cool. So at the moment This site is for identifying bugs only.. No less or more. It will be seperate atmo from source.. However recognising the bugs is THE issue. eg one of the three paths 1) dont set up a bug tracker and ignoire them 2) Have a bug tracker and then ignore them 3) Have an active bug tracer and identify problem area and resolve issue.. 4) Send a report to the developers that there is a bug u need to fix.. Curtis .. please endorse and go for this bucktracker please.. At least that way we can all complain until we sort it.. ;-) this way it will be a steady eddie ;-) the SCM is another issue I'd be more inclined to use the bug trackers at http://code.google.com/p/simgear and http://code.google.com/p/flightgear but those sites are currently tied up with svn versus git versus hg discussions. Personally I think it could turn into a mess if we fill up this new site with a bunch of bug reports and then have no way to move them to the official site(s) later. We also have bug trackers available at our sourceforge registered projects. I always felt the sourceforge bug tracker was kind of slow and clunky. The google bug tracker seems much nicer, and it appears it is integrated with the repository so you can reference specific patches or branches. That would be harder to do if the bug tracker lived at a completely separate project name. We lose much of the cool functionality that google offers. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/http://baron.flightgear.org/%7Ecurt/ http://baron.flightgear.org/%7Ecurt/ -- 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 -- 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 -- 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
Re: [Flightgear-devel] bug tracking
On Wed, Sep 30, 2009 at 12:47 PM, Gijs de Rooy gijsr...@hotmail.com wrote: Hi, Curtis Olson wrote: Why not use the bug tracker at code.google.com/p/flightgear? Is it just me or does that project not exist? The link gives an error page and the project does not show up when searching for FlightGear on Google Code. The simgear one does exist... Ok, well the one that will eventually exist there ... :-) (except we cannot collectively agree on the best source code control system to move towards. Svn in better than cvs; cvs is better than svn, git implementations are dodgy under windows, git implementations under windows run fine, hg is a lean mean fighting machine, except google's implementation or servers currently has some sort of issues with the linux hg client or maybe visa versa; anything is better than cvs; don't transition to svn because once the cvs 'crisis' is averted then there's no further motiviation to go any further. the project has a lot of git experience, the project has a lot of svn experience, the project has a lot of cvs experienece, the project doesn't have much hg experience; every one can register a project name at their favorite hosting service, everyone can setup their own local repostory clone using their favorite tool; but some developers have argued this *very* passionately implying perhaps that there will be a huge firestorm following up any bad or incorrect decisions for how to move foward; we have set up a sequence of constraints that gives us no option to do anything.) Regards, Curt. -- 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
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/misc strutils.cxx, 1.4, 1.5 strutils.hxx, 1.4, 1.5
Hi Jim,
I just noticed you added an OSG dependency to strutils.cxx/hxx If possible
it would be nice to avoid adding graphics system dependencies to these text
manipulation libraries. SimGear and SimGear code is used in a variety of
places beyond FlightGear, even in embedded systems where compiling opengl
and OSG is completely impossible.
Would it work to use something like the following instead of an OSG
function?:
#include ctype.h
int toupper(int c);
int tolower(int c);
Right now this OSG dependency is breaking one of my other projects.
Thanks,
Curt.
On Sat, Sep 26, 2009 at 6:44 AM, James Turner j...@baron.flightgear.orgwrote:
Update of /var/cvs/SimGear-0.3/source/simgear/misc
In directory baron.flightgear.org:/tmp/cvs-serv8677/simgear/misc
Modified Files:
strutils.cxx strutils.hxx
Log Message:
Extend simgear::strutils with convertToLowerCase helper - currently a proxy
for osgDB helper of the same name.
Index: strutils.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/strutils.cxx,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- strutils.cxx13 Apr 2008 21:11:44 - 1.4
+++ strutils.cxx26 Sep 2009 11:44:33 - 1.5
@@ -25,6 +25,11 @@
#include strutils.hxx
+#include osgDB/FileNameUtils // for convertToLowerCase
+
+using std::string;
+using std::vector;
+
namespace simgear {
namespace strutils {
@@ -180,5 +185,12 @@
return do_strip( s, BOTHSTRIP );
}
+ string convertToLowerCase(const string str)
+ {
+// proxy onto osgDB - easy to reimplement here, but let's avoid
+// code duplication for the moment.
+return osgDB::convertToLowerCase(str);
+ }
+
} // end namespace strutils
} // end namespace simgear
Index: strutils.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/strutils.hxx,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- strutils.hxx28 Jul 2008 07:52:14 - 1.4
+++ strutils.hxx26 Sep 2009 11:44:34 - 1.5
@@ -30,16 +30,12 @@
#include simgear/compiler.h
#include string
-
#include vector
-using std::vector;
-
#include cstdlib
-using std::string;
namespace simgear {
-namespace strutils {
+ namespace strutils {
// /**
// * atof() wrapper for string type
@@ -64,9 +60,9 @@
* @param s String to strip.
* @return The stripped string.
*/
- string lstrip( const string s );
- string rstrip( const string s );
- string strip( const string s );
+ std::string lstrip( const std::string s );
+ std::string rstrip( const std::string s );
+ std::string strip( const std::string s );
/**
* Split a string into a words using 'sep' as the delimiter string.
@@ -79,12 +75,15 @@
* resulting in at most maxsplit+1 words.
* @return Array of words.
*/
- vectorstring
- split( const string s,
+ std::vectorstd::string
+ split( const std::string s,
const char* sep = 0,
int maxsplit = 0 );
-} // end namespace strutils
+
+ std::string convertToLowerCase(const std::string str);
+
+ } // end namespace strutils
} // end namespace simgear
#endif // STRUTILS_H
--
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
___
Simgear-cvslogs mailing list
simgear-cvsl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simgear-cvslogs
--
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
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/misc strutils.cxx, 1.4, 1.5 strutils.hxx, 1.4, 1.5
Ok, duh! I see that is a single character function, but there has to be a
string class function or it can't be too hard to whip up a little function
ourselves.
Thanks,
Curt.
On Wed, Sep 30, 2009 at 1:44 PM, Curtis Olson wrote:
Hi Jim,
I just noticed you added an OSG dependency to strutils.cxx/hxx If possible
it would be nice to avoid adding graphics system dependencies to these text
manipulation libraries. SimGear and SimGear code is used in a variety of
places beyond FlightGear, even in embedded systems where compiling opengl
and OSG is completely impossible.
Would it work to use something like the following instead of an OSG
function?:
#include ctype.h
int toupper(int c);
int tolower(int c);
Right now this OSG dependency is breaking one of my other projects.
Thanks,
Curt.
On Sat, Sep 26, 2009 at 6:44 AM, James Turner
j...@baron.flightgear.orgwrote:
Update of /var/cvs/SimGear-0.3/source/simgear/misc
In directory baron.flightgear.org:/tmp/cvs-serv8677/simgear/misc
Modified Files:
strutils.cxx strutils.hxx
Log Message:
Extend simgear::strutils with convertToLowerCase helper - currently a
proxy for osgDB helper of the same name.
Index: strutils.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/strutils.cxx,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- strutils.cxx13 Apr 2008 21:11:44 - 1.4
+++ strutils.cxx26 Sep 2009 11:44:33 - 1.5
@@ -25,6 +25,11 @@
#include strutils.hxx
+#include osgDB/FileNameUtils // for convertToLowerCase
+
+using std::string;
+using std::vector;
+
namespace simgear {
namespace strutils {
@@ -180,5 +185,12 @@
return do_strip( s, BOTHSTRIP );
}
+ string convertToLowerCase(const string str)
+ {
+// proxy onto osgDB - easy to reimplement here, but let's avoid
+// code duplication for the moment.
+return osgDB::convertToLowerCase(str);
+ }
+
} // end namespace strutils
} // end namespace simgear
Index: strutils.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/strutils.hxx,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- strutils.hxx28 Jul 2008 07:52:14 - 1.4
+++ strutils.hxx26 Sep 2009 11:44:34 - 1.5
@@ -30,16 +30,12 @@
#include simgear/compiler.h
#include string
-
#include vector
-using std::vector;
-
#include cstdlib
-using std::string;
namespace simgear {
-namespace strutils {
+ namespace strutils {
// /**
// * atof() wrapper for string type
@@ -64,9 +60,9 @@
* @param s String to strip.
* @return The stripped string.
*/
- string lstrip( const string s );
- string rstrip( const string s );
- string strip( const string s );
+ std::string lstrip( const std::string s );
+ std::string rstrip( const std::string s );
+ std::string strip( const std::string s );
/**
* Split a string into a words using 'sep' as the delimiter string.
@@ -79,12 +75,15 @@
* resulting in at most maxsplit+1 words.
* @return Array of words.
*/
- vectorstring
- split( const string s,
+ std::vectorstd::string
+ split( const std::string s,
const char* sep = 0,
int maxsplit = 0 );
-} // end namespace strutils
+
+ std::string convertToLowerCase(const std::string str);
+
+ } // end namespace strutils
} // end namespace simgear
#endif // STRUTILS_H
--
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
___
Simgear-cvslogs mailing list
simgear-cvsl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simgear-cvslogs
--
Curtis Olson:
http://baron.flightgear.org/~curt/http://baron.flightgear.org/%7Ecurt/
--
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
Re: [Flightgear-devel] FlightGear September Newsletter now available
Hi Stuart, Thanks for keeping on top of the news letter. It is definitely appreciated! I like that you've kept it simple and concise. Thanks! Curt. On Wed, Sep 30, 2009 at 4:09 PM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: Hi All, The September edition of The FlightGear Newsletter is now available: http://wiki.flightgear.org/index.php/FlightGear_Newsletter_September_2009 As always, we're looking for contributions to the next edition, so if you've done something interesting with FlightGear, please write up a couple of paragraphs for the next edition. Thanks, -Stuart -- 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
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
Re: [Flightgear-devel] FlightGear Sound System redux
On Tue, Sep 22, 2009 at 10:24 AM, John Denker wrote: On 09/22/09 08:03, Ron Jensen wrote: I would like to hear all the cockpit sounds in exterior views because I am still sitting in the cockpit. My rudder pedals are under my feet, my throttle quadrant is at my knee, and the stick is in my hand. I am still flying the aircraft so it is important to hear the common cockpit sounds. Markers, radio calls, etc. 1) By that argument, there should be no Doppler effects -- or distance effects, or azimuth effects -- in any view, including flyby view, Tower view, et cetera. That would greatly simplify the audio code! 2) The counterargument is that maybe you are sitting somewhere, flying the plane via remote control. There are lots of RC pilots in the world, including in the FGFS user community. And even some in the USAF. The thing to remember here is that this is a virtual experience ... a simulation. We can do things in the simulation that cannot be done in real life. We can experience the simulation from perspectives that are not available in real life. In many ways, this is the power of simulation and visualization. When practicing IFR approaches in a simulator, you don't have to fly back to the start each time. You can reposition yourself instantaneously and fly many more practice approaches in the simulator than you could in real life within that same time period. So we need to be careful about justifying decisions based solely on realism or non-realism. We can spend the rest of our lives presenting examples and counter examples if we look at the issues from only that level. We need to be asking not only what is realistic or not realistic, but what makes sense? What would users possibly want to be able to do? And what would the most common usage or default configuration be? I love having our various external views available when I'm replaying real flight data. Sure, some of these perspectives would be *very* hard to recreate in real life, but they are a very useful tool for visualization and validating that the aircraft looks like it is flying right, or looks like it is flying the same way it flew in real life. If you are primarily acting as a pilot of an aircraft, how much of the external world can you actually hear over the sound of your own engines? How much time does a typical user spend in the simulator with the engines off? I would say this is not a high priority for a flight simulator based solely on a realism argument. But in a simulator I (and I imagine many others) spend a lot of time viewing our airplane from the outside. In that case having the sound system perform in a way that makes sense for an external view is nice. Sure, from a realism perspective I would die quickly after I saw my 747 flying at 45,000 from the outside. That's not a view I really would be excited to see in real life. At that point, I'm probably not paying attention to Doppler effects and if I can hear the cockpit audio or not, and I probably wouldn't hear any of that anyway over the sound of my own ears exploding. So keep in mind that a simulator offers unique features and unique abilities not available in real life. When we diverge from what's possible in reality, the best we can do is offer something that makes sense and fits within the flow of what's going on. If we can't agree on exactly what that is, making the behavior configurable with a reasonable default is often a good option. Best regards, Curt. -- 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
