Re: [Flightgear-devel] Duplicate files in base package
On Fri, Feb 26, 2010 at 10:21 PM, Ron Jensen w...@jentronics.com wrote: I still support the idea common shared directories idea for such things as instruments This is a nice, happy thought. But in the real world it hasn't worked out so well. Since we model such a huge variety of aircraft, and different FDMs and systems provide different outputs, our common instrument folders would need to be huge to cover all the different kinds of instruments, plus variations and modifications to fit each individual aircraft's structure. It makes more sense to me to house each instrument with its aircraft. In real life, very, very few instruments are customized for each plane (the airspeed indicator, with its speed markings, is the obvious example). Most are manufactured by independent companies and are TSO'd, so that they can be used in hundreds of different aircraft models. Ditto for most avionics, aside from some glass panels, etc. A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DELETE DUPLICATE FG DATA FILES
Yippee! After the recent A380 update, there are presently NO 'case' only duplicates in any single folder, causing a Windows cvs update to hiccup... Thank you all... Case closed ;=)) Geoff. PS: This is nothing to do with a parallel, seemingly similar thread - RE: Duplicate files in base package which is another topic altogether ;=)) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. What we probably need for shared instruments is a well defined set of properties for each instrument. Currently most of our instruments animations are tied directly to the output properties of the signal source. In vor.xml the TO-flag is animated from /instrumentation/nav[0]/to-flag. It's only usable for nav1 and a second set of animation xml is needed for nav2. What we need are unique properties for each instrument that are responsible for the animation of the instrument on on side and unique properties that reflect some state (like a TO-flag signal) on the other side. What's left for the A/C designer is the linkage between these two side. When you buy the Sigma-Tek attitude gyro at you local avionics dealer (the base package), you get your device with a well known interface connector and your avionics technician (A/C designer) needs to do the wiring. Almost everything needed for that three-tier-design is already in fg. Probably we need some kind of relative mount point, so a single vor.xml can be loaded (mounted) into /instrumentation/vor-indicator[0] and /instrumentation/vor-indicator[1]. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] build on Windows; dependencies?
On Fri, 2010-02-26 at 16:39 -0600, stan.mar...@l-3com.com wrote: Update on my own post, regarding the missing files... Hi Stan, et al, includes a number of files which appear to have moved ... In addition to the dependencies problems, mentioned by Reagan, this missing or moved files also adds to the windows build problems, since it is difficult to _ALWAYS_ keep the vcproj (or dsp in my case) source file set UP-TO-DATE. Some tricks I have learned over the years ;=)) (a) subscribe to the cvs logs, and then you will 'see' when files are added, deleted, moved, and you can incrementally adjust your local system of choice. (b) and/or learn to read the Makefile.am trail. In any download these can give good information on what is include in what is being built in *nix, what ever version you are building. As previously stated, Fred and others are doing their best to keep the 'projects' msvc files current, but that will not address what is in previous releases. My TSS system is unfortunately 'frozen' until I do a later update, last was Feb 14, 2010, so will always have this problem. But as you have found, it is usually not too difficult to do these source list modifications. You have not yet addressed 'missing' files, which only become apparent after the final link, with sometimes many 'unresolved externals...'. Here you must find the source file containing the missing function in either SG or FG, and add it appropriately to SG or FG solution, a sometimes tedious process. You need a windows port of 'grep', and I have my own find all - http://geoffair.net/ms/fa4.htm Again I usually check what I am doing with the Makefile.am set, but this too can be quite difficult, since both SG and FG are made up of many different libraries in *nix, before the final Main fgfs exe, thus are in MANY different folders... christ...@freedomworks.ca wrote: Few months back we spent a couple days trying to compile FG on Windows using the FG Wiki and did not have any luck. [snip] Geoff, I appreciate your efforts in creating your own custom build process but we could not get your files to work. [snip] Can someone explain why this has not been addressed? Wow, Christian, and the others in the 'we', you manage to put _ALL_ efforts down, even though you say you 'appreciate' something, without ever saying exactly _WHAT_ problems you had! Saying you did not have 'luck', or that it did not 'work', is a put down, without telling what was the reason for your problems. You asked back on Jan 4 - Is there anyone that can give us some direction as to building for Windows? and we responded, but you still seem unhappy? Your specific problems, what ever they be, can ONLY be addressed if we know exactly _WHAT_ problems are being encountered. I just read the wiki :- http://wiki.flightgear.org/index.php/Building_FlightGear_-_Windows and it looks pretty clear. Long and tedious, but clear! I put thousands of words into my build site, and hope I make it CLEAR ;=)) Again, as Reagan suggested, there is NO simple apt-get, yum, etc 3rd party dependency library install system available for windows, so you, the user, must do it yourself, and I know that can be difficult and FRUSTRATING. And this is made even more difficult due to the fact that OpenSceneGraph (OSG) not only uses cmake before msvc, and has its own dependencies, like jpeg, and png, but, since it is a BIG set of DLLs (shared libraries), there can be other problems at runtime. Installing DLLs, in windows, such that they are available at runtime, can be difficult to understand... And this is similarly true to a lesser extent with OpenAL, and alut, although in my case, their SDK makes things easier, and only leaves alut... And then there is the enormous set of boost headers... but thankfully no build required... In my TSS build system, I address this by forcing _ALL_ the prerequisite dependency sources to be downloaded first, and put in a STRICT source directory structure. Once this is done, my setupfg.bat will take over, create a copy work, and the build can be relative simple ;=() The projects/VC?? msvc files included with the source download addresses this by providing a set of pre-built binary libraries, and includes, thus less build from source needs to be done... something I will migrate my TSS towards... It seems more like a chicken and egg problem ;=)) Until there are MANY more windows builders, willing to contribute some of their time to helping others, honing down the possible build systems, adding fixes, even to the wiki, we will not have many more windows builders... So is the windows FG build being addressed? I think so, but we could always have more input from others, with constructive criticisms, suggested fixes, changes, ideas on the build and install system, etc, etc... and in my case this can be off-board, since it only involves me... And Stan, gently, I would get off the 'boost' questions ;=)) If you read back in the archives you will see
Re: [Flightgear-devel] Duplicate files in base package
Something I'd love to see, in the long term, is a GUI that allows users to customize their panels, just like real aircraft owners do. I could decide to install a different brand of TC (the default late 1970s Cessna 172P now has a vintage 1950s needle and ball instead of a TC -- cool, but what's up with that?), upgrade or downgrade the GPS, swap out radios, etc. That would be especially attractive for flight schools and students, since they could match the panels of their actual aircraft pretty closely. All the best, David On Sat, Feb 27, 2010 at 8:53 AM, Torsten Dreyer tors...@t3r.de wrote: A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. What we probably need for shared instruments is a well defined set of properties for each instrument. Currently most of our instruments animations are tied directly to the output properties of the signal source. In vor.xml the TO-flag is animated from /instrumentation/nav[0]/to-flag. It's only usable for nav1 and a second set of animation xml is needed for nav2. What we need are unique properties for each instrument that are responsible for the animation of the instrument on on side and unique properties that reflect some state (like a TO-flag signal) on the other side. What's left for the A/C designer is the linkage between these two side. When you buy the Sigma-Tek attitude gyro at you local avionics dealer (the base package), you get your device with a well known interface connector and your avionics technician (A/C designer) needs to do the wiring. Almost everything needed for that three-tier-design is already in fg. Probably we need some kind of relative mount point, so a single vor.xml can be loaded (mounted) into /instrumentation/vor-indicator[0] and /instrumentation/vor-indicator[1]. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A380 model loading failures
I just updated data to try the A380, and I'm not seeing any model (interior or exterior) - the FDM and other pieces seem to be loading fine. My tree contains assorted minor changes, but nothing that should affect this. Relevant errors, I suspect: Failed to load submodel: Failed to load 3D model at /Users/Shared/FGFS/data/Aircraft/A380/XML/Wings/../../Models/Wings/wings.3ds Failed to load model: Failed to load 3D model at /Users/Shared/FGFS/data/Aircraft/A380/XML/Wings/../../Models/Wings/wings.3ds James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
On Sat, 2010-02-27 at 07:56 -0500, David Megginson wrote: On Fri, Feb 26, 2010 at 10:21 PM, Ron Jensen w...@jentronics.com wrote: I still support the idea common shared directories idea for such things as instruments This is a nice, happy thought. But in the real world it hasn't worked out so well. Since we model such a huge variety of aircraft, and different FDMs and systems provide different outputs, our common instrument folders would need to be huge to cover all the different kinds of instruments, plus variations and modifications to fit each individual aircraft's structure. It makes more sense to me to house each instrument with its aircraft. In real life, very, very few instruments are customized for each plane (the airspeed indicator, with its speed markings, is the obvious example). Most are manufactured by independent companies and are TSO'd, so that they can be used in hundreds of different aircraft models. Ditto for most avionics, aside from some glass panels, etc. A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. Those trivial differences are enough to make the instrument not work properly in an aircraft, though. I've spent a lot of time installing 5V light bulbs in avionics equipment that came rigged for 28V lighting. In FlightGear we have a problem in the common instruments-3d that many instruments use funky properties for their panel lighting (/sim/model//material/instruments/factor or /controls/lighting/instruments-norm) instead of a more sensical /systems/electrical/output/instruments- and then the is the argument about that being a -norm or a -volts. So to avoid duplicating instruments we'd be forced to create and maintain 3 or 4 properties to drive different instruments. I'll sacrifice disk-space for frame-rate, thank you. Last time I changed an (my) instrument in Instruments-3D there were howls of anguish. DCulp has packaged his common instruments in his DavePack aircraft, and that works pretty well, but I still believe the aircraft maintainer should have the right to keep his instruments with his aircraft, even if there is some duplication. Thanks, Ron -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
Ewww , a GUI to do this ? Its already pretty easy to point the model section to a different instrument , and the one Im currently working on , Im creating several panel files with different layouts that can be selected in the set file , but I'd hate to see instruments being changeable while in flight Just my thoughts on the matter :) Syd On Sat, Feb 27, 2010 at 7:16 AM, David Megginson david.meggin...@gmail.comwrote: Something I'd love to see, in the long term, is a GUI that allows users to customize their panels, just like real aircraft owners do. I could decide to install a different brand of TC (the default late 1970s Cessna 172P now has a vintage 1950s needle and ball instead of a TC -- cool, but what's up with that?), upgrade or downgrade the GPS, swap out radios, etc. That would be especially attractive for flight schools and students, since they could match the panels of their actual aircraft pretty closely. All the best, David On Sat, Feb 27, 2010 at 8:53 AM, Torsten Dreyer tors...@t3r.de wrote: A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. What we probably need for shared instruments is a well defined set of properties for each instrument. Currently most of our instruments animations are tied directly to the output properties of the signal source. In vor.xml the TO-flag is animated from /instrumentation/nav[0]/to-flag. It's only usable for nav1 and a second set of animation xml is needed for nav2. What we need are unique properties for each instrument that are responsible for the animation of the instrument on on side and unique properties that reflect some state (like a TO-flag signal) on the other side. What's left for the A/C designer is the linkage between these two side. When you buy the Sigma-Tek attitude gyro at you local avionics dealer (the base package), you get your device with a well known interface connector and your avionics technician (A/C designer) needs to do the wiring. Almost everything needed for that three-tier-design is already in fg. Probably we need some kind of relative mount point, so a single vor.xml can be loaded (mounted) into /instrumentation/vor-indicator[0] and /instrumentation/vor-indicator[1]. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
I think I misunderstood you ... a graphical tool to do this would certainly speed things up ... currently I used a dummy panel in Blender to find positions. I though you meant from the runtime menu :). Syd On Sat, Feb 27, 2010 at 11:23 AM, David Megginson david.meggin...@gmail.com wrote: On Sat, Feb 27, 2010 at 2:10 PM, syd adams adams@gmail.com wrote: Its already pretty easy to point the model section to a different instrument , and the one Im currently working on , Im creating several panel files with different layouts that can be selected in the set file , but I'd hate to see instruments being changeable while in flight Making changes in an XML file is certainly simpler than writing C++ code -- that's why I wrote the XML property system -- but eventually, we'll want to let less technical people make configuration changes as well. It's not a short-term goal, but something interesting to keep in mind, all the same. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
Could certainly be done ... perhaps (although maybe a little awkwardly ... or not?) using the FlightGear gui and nasal infrastructure. I'm envisioning the 2d panel structure I guess ... probably would be more complicated with 3d panels. Curt. On Sat, Feb 27, 2010 at 2:26 PM, syd adams wrote: I think I misunderstood you ... a graphical tool to do this would certainly speed things up ... currently I used a dummy panel in Blender to find positions. I though you meant from the runtime menu :). -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Google Bug Tracker and Aircrafts
Yeah this was discussed earlier because that list rapidly filled up with old bugs . I agree , missing features , or incomplete feature , or not knowing how an instrument works shouldn't be filed as a bug :) On Sat, Feb 27, 2010 at 12:54 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Hi, The Google Bug tracker is a nice instrument for the harcore developers here. But I have some problems with bug tracking there on aircrafts. All our aircrafts are in developement. It is difficult to say an aircraft is completly 100% ready. A lot of bugs often aren't more than just missing features. As an example: someone wrote that the Cessna Citation Bravo's ADF needle isn't working. In the description it sounds a bit different, as it just doesn't shows any NDB's. Does it ever have? To my knowledge not, so it is a missing feature, not a bug. Another example: someone noticed that the 737-300 shows two different cockpit- a 2d one and a 3d one. As it was exactly my intention, to keep the 2d-panel as long the flightdeck is not usuable as like the 2d-panel, and so I noted that in the ReadMe-file. Quote:This is the 737-300 in Progress... The Boeing 737-300 is now under work to be improved and come much closer to realityFor seeing the 3d-cockpit in progress pan the view so the 2d-panel will dissapear I wonder if a bug-tracker makes really sense here- we have more than 130 (?) aircrafts and I know a lot of them which do not have any proper cockpit; fdm; autopilot; systems etc... all bugs? Or just in development? I think aircrafts should be excluded as long they aren't part of the base package. Anyone agree or disgagree? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Google Bug Tracker and Aircrafts
Heiko Schulz wrote: I wonder if a bug-tracker makes really sense here- we have more than 130 (?) aircrafts 130?! There's 300 of them in CVS, so about 350 with the additional hangars! :) Agree with you on all points btw. It might be nice to have an additional bug tracker for aircraft though. Similar to an additional requests tracker, that someone posted on the list some days ago... Cheers, Gijs _ 25GB gratis online harde schijf http://skydrive.live.com-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
I don't know about dynamic positioning of instruments, but I would find it interesting to have an easy method of selecting alternate instruments for the same position. For example, I have several attitude indicator variations that could be used based on period or pilot/owner preference. This would have application in aircraft like the Grumman Goose, which spans many decades of instrument development. It would be interesting to have a menu of instrument choices that I could then be saved with other user preferencess. Other than including the different instruments in the same xml/model package, which is clearly not the goal, I don't know how to do this, especially without burdening the system by loading instrument resources that are not used. Currently to do this I write up a little how-to for pulling in a different instrument in the relevant xml, but many folks don't read those details and perhaps miss the configuration possibilities. It would be great to offer an easier more dynamic scheme. -Gary On Sat, Feb 27, 2010 at 3:58 PM, syd adams adams@gmail.com wrote: I can see 3d instruments being easier position them on the panel with a mouse click then drag them like i did the b1900d manual ... or menu buttons in a dialog like the ufo does scenery objects for finer adjustments ... I suppose the 2d instrument placement would be almost the same... Dont know if I like the idea of moving instruments around in flight , but then I guess the new arrangement would need to be written to a file to be permenant . Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
Interesting idea... Ive got a panel file for each panel layout , but that changes the entire instrument positions and types , not individual instruments ... Might be tricky unless the instrument selection is from the Instruments-3d folder ... Just thinking out loud here :) Syd On Sat, Feb 27, 2010 at 1:23 PM, Gary Neely grne...@gmail.com wrote: I don't know about dynamic positioning of instruments, but I would find it interesting to have an easy method of selecting alternate instruments for the same position. For example, I have several attitude indicator variations that could be used based on period or pilot/owner preference. This would have application in aircraft like the Grumman Goose, which spans many decades of instrument development. It would be interesting to have a menu of instrument choices that I could then be saved with other user preferencess. Other than including the different instruments in the same xml/model package, which is clearly not the goal, I don't know how to do this, especially without burdening the system by loading instrument resources that are not used. Currently to do this I write up a little how-to for pulling in a different instrument in the relevant xml, but many folks don't read those details and perhaps miss the configuration possibilities. It would be great to offer an easier more dynamic scheme. -Gary On Sat, Feb 27, 2010 at 3:58 PM, syd adams adams@gmail.com wrote: I can see 3d instruments being easier position them on the panel with a mouse click then drag them like i did the b1900d manual ... or menu buttons in a dialog like the ufo does scenery objects for finer adjustments ... I suppose the 2d instrument placement would be almost the same... Dont know if I like the idea of moving instruments around in flight , but then I guess the new arrangement would need to be written to a file to be permenant . Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Google Bug Tracker and Aircrafts
I don't want to see any feature requests for the code either :) Tim On Sat, Feb 27, 2010 at 9:54 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Hi, The Google Bug tracker is a nice instrument for the harcore developers here. But I have some problems with bug tracking there on aircrafts. All our aircrafts are in developement. It is difficult to say an aircraft is completly 100% ready. A lot of bugs often aren't more than just missing features. As an example: someone wrote that the Cessna Citation Bravo's ADF needle isn't working. In the description it sounds a bit different, as it just doesn't shows any NDB's. Does it ever have? To my knowledge not, so it is a missing feature, not a bug. Another example: someone noticed that the 737-300 shows two different cockpit- a 2d one and a 3d one. As it was exactly my intention, to keep the 2d-panel as long the flightdeck is not usuable as like the 2d-panel, and so I noted that in the ReadMe-file. Quote:This is the 737-300 in Progress... The Boeing 737-300 is now under work to be improved and come much closer to realityFor seeing the 3d-cockpit in progress pan the view so the 2d-panel will dissapear I wonder if a bug-tracker makes really sense here- we have more than 130 (?) aircrafts and I know a lot of them which do not have any proper cockpit; fdm; autopilot; systems etc... all bugs? Or just in development? I think aircrafts should be excluded as long they aren't part of the base package. Anyone agree or disgagree? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch to protect terrasync SVN from ^C
Index: terrasync.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/TerraSync/terrasync.cxx,v
retrieving revision 1.28
diff -u -r1.28 terrasync.cxx
--- terrasync.cxx 23 Jan 2010 22:27:38 - 1.28
+++ terrasync.cxx 28 Feb 2010 05:49:01 -
@@ -35,6 +35,7 @@
#endif
#include stdlib.h // atoi() atof() abs() system()
+#include signal.h // signal()
#include simgear/compiler.h
@@ -270,8 +271,23 @@
}
+bool terminating = false;
+sighandler_t prior_signal_handlers[32];
+int termination_triggering_signals[] =
+ {SIGHUP, SIGINT, SIGQUIT, SIGKILL, 0}; // zero terminated
+
+void terminate_request_handler(int param) {
+cout \nReceived signal param ,
+ intend to terminate soon,
+ repeat to force an immediate effect.\n;
+terminating = true;
+signal(param, prior_signal_handlers[param]);
+}
+
+
const int nowhere = -;
+
// parse message
static void parse_message( const string msg, int *lat, int *lon ) {
double dlat, dlon;
@@ -281,8 +297,8 @@
string::size_type pos = text.find( $GPGGA );
if ( pos == string::npos )
{
- *lat = -.0;
- *lon = -.0;
+ *lat = nowhere;
+ *lon = nowhere;
return;
}
string tmp = text.substr( pos + 7 );
@@ -408,7 +424,8 @@
void getWaitingTile() {
while ( !waitingTiles.empty() ) {
- CompletedTiles::iterator ii = completedTiles.find(
waitingTiles.front() );
+ CompletedTiles::iterator ii =
+completedTiles.find( waitingTiles.front() );
time_t now = time(0);
if ( ii == completedTiles.end() || ii-second + 600 now ) {
sync_tree(waitingTiles.front().c_str());
@@ -422,7 +439,7 @@
int main( int argc, char **argv ) {
int port = 5501;
-char host[256] = ;// accept messages from anyone
+char host[256] = localhost;
bool testing = false;
bool do_checkout(true);
int verbose(0);
@@ -485,7 +502,6 @@
// Must call this before any other net stuff
netInit( argc,argv );
-
netSocket s;
if ( ! s.open( false ) ) { // open a UDP socket
@@ -524,7 +540,14 @@
}
-while ( true ) {// main loop
+for (int* sigp=termination_triggering_signals; *sigp; sigp++) {
+prior_signal_handlers[*sigp] =
+signal(*sigp, *terminate_request_handler);
+if (verbose) cout Intercepted signal *sigp endl;
+}
+
+while ( !terminating ) {
+// main loop
recv_msg = false;
if ( testing ) {
// No FGFS communications
@@ -532,6 +555,9 @@
lon = -123;
recv_msg = (lat != last_lat) || (lon != last_lon);
} else {
+if (verbose waitingTiles.empty()) {
+cout Idle; waiting for FlightGear position\n;
+}
s.setBlocking(waitingTiles.empty());
len = s.recv(msg, maxlen, 0);
if (len = 0) {
@@ -584,11 +610,11 @@
}
else if ( testing ) {
- exit( 0 );
+ terminating = true;
} else
ulSleep( 1 );
-} // while true
+} // while !terminating
return 0;
}
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
