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] 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] 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
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] 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] Duplicate files in base package
On Friday 26 February 2010 17:16:38 Detlef Faber wrote: I guess most duplicate files are instruments which are not in the generic folder. Of course it would be desireable to have them all in one place and reference to there, but that would cause severe problems with the aircraft downloads, because every aircraft on the download page would need a second package for instruments which are not in the Base package. Including all these Instruments in the Base Package would greatly increase the download size. This repeatedly strikes me as problems that Linux packages managers have solved completely, elegantly and simply a long time ago. They support dependencies, so commonly used parts only have to be installed once. They support versioning, making upgrades simple and safe by for example not allowing binaries to be installed alongside incompatible data. With systems like the openSUSE build service, users can even create their own repositories and link to others. Those systems even support mirrors to spread downloads. Maybe it's time to use what's already there? Stefan -- 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
-- From: Stefan Seifert n...@detonation.org Sent: Friday, February 26, 2010 5:26 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Duplicate files in base package This repeatedly strikes me as problems that Linux packages managers have solved completely, elegantly and simply a long time ago. They support dependencies, so commonly used parts only have to be installed once. They support versioning, making upgrades simple and safe by for example not allowing binaries to be installed alongside incompatible data. With systems like the openSUSE build service, users can even create their own repositories and link to others. Those systems even support mirrors to spread downloads. Maybe it's time to use what's already there? One problem which springs to mind is that there must be many same name files (e.g. HSI.xml and its related HSI.ac) which are specific to one aircraft and are in fact entirely different. These will need to be renamed per aircraft (e.g SpitfireMKX.HSI) or per instrument manufacturer (e.g. FD108HSI). However if a common library could be set up a great saving would be made, not only in unused duplicates, but in the ability of designers to find already completed instruments. -- 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 Fri, 26 Feb 2010, Alan Teeder wrote: Maybe it's time to use what's already there? One problem which springs to mind is that there must be many same name files (e.g. HSI.xml and its related HSI.ac) which are specific to one aircraft and are in fact entirely different. These will need to be renamed per aircraft (e.g SpitfireMKX.HSI) or per instrument manufacturer (e.g. FD108HSI). It's my understanding that the duplicate checker operates on checksums not filenames. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- 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
-- From: Gene Buckle ge...@deltasoft.com Sent: Friday, February 26, 2010 8:29 PM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Duplicate files in base package On Fri, 26 Feb 2010, Alan Teeder wrote: Maybe it's time to use what's already there? One problem which springs to mind is that there must be many same name files (e.g. HSI.xml and its related HSI.ac) which are specific to one aircraft and are in fact entirely different. These will need to be renamed per aircraft (e.g SpitfireMKX.HSI) or per instrument manufacturer (e.g. FD108HSI). It's my understanding that the duplicate checker operates on checksums not filenames. Apologies. The upper-lower case duplicate name problem was in my stupid head. I still support the idea common shared directories idea for such things as instruments Alan -- 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 Fri, 2010-02-26 at 21:13 +, Alan Teeder wrote: I still support the idea common shared directories idea for such things as instruments Alan 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. Also, each instrument is commonly comprised of three separate files, the texture (png), the model (ac) and the animations (xml). Needing a change in any one of these really necessitates all three being in the same place. So even if the texture and the model are the same, using a different animation file means the .png and .ac are duplicates, its true, but this also ensures the model and or texture don't change in ways that are incompatible with the animation file. -- 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 agree , there's a lot of duplication ,(in instruments, too) but I think the problem is author's tastes ... I've duplicated textures because I dont care for the look , or style , etc,of existing ones and Im sure that's the same for other contributors. So it might be a problem deciding who's get's used, and how many duplicates pop up in that folder :). But it would be nice to solve this one... Cheers On Thu, Feb 25, 2010 at 1:23 PM, Roy Vegard Ovesen roy.v.ove...@haugnett.no wrote: FSlint reports that the base package, or the data directory, contains quite a lot of duplicate files. The file that is wasting the most bytes is glass_shader.png (some instances named glass.png) with 43 974 656 bytes, or around 45MB. This file is duplicated 89 times. The second biggest waster is shader.png (here too some instances are named glass.png) with 31 457 280 bytes and 641 instances. Running fdupes in the data directory reports that duplicate files occupy about 420 megabytes of the 2.7 Gig. Thats roughly 15% (if my math is correct). Many of the duplicate files seem to be textures. This begs the question: would it be better to have a directory $FG_ROOT/Aircraft/Textures where one would put textures that are shared by several aircraft? There already is a $FG_ROOT/Textures directory, but this seems to contain only non-aircraft textures. Comments? -- Roy Vegard -- 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
On Friday February 26 2010 02:18:30 syd adams wrote: I agree , there's a lot of duplication ,(in instruments, too) but I think the problem is author's tastes ... I've duplicated textures because I dont care for the look , or style , etc,of existing ones and Im sure that's the same for other contributors. I've only considered files that are bit-by-bit identical (identical SHA1 checksum). If in your example you've duplicated a bitmap from another aircraft and then changed the file, then it is not considered a duplicate. So it might be a problem deciding who's get's used, and how many duplicates pop up in that folder :). But it would be nice to solve this one... Cheers -- Roy Vegard -- 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
