Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
Cameron Moore [EMAIL PROTECTED] said: Speaking of which, when I hit 's' to switch panel, it looks like we're reading the XML file each time. It funny that loading scenery doesn't cause any hiccups in performance but switching panels does. Yep, I just used the panel-load that was/is bound to a function key after swapping the panel path property. Panel-load is mostly for reloading the panel while making changes to it (without having to reload flightgear). At some point it might be a good idea to create an array of panel objects and load them all at startup. Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
* [EMAIL PROTECTED] (Jim Wilson) [2001.12.22 08:27]: Cameron Moore [EMAIL PROTECTED] said: Speaking of which, when I hit 's' to switch panel, it looks like we're reading the XML file each time. It funny that loading scenery doesn't cause any hiccups in performance but switching panels does. Yep, I just used the panel-load that was/is bound to a function key after swapping the panel path property. Panel-load is mostly for reloading the panel while making changes to it (without having to reload flightgear). At some point it might be a good idea to create an array of panel objects and load them all at startup. Jim Could we add a check for the file's modified time and not load it if it hasn't been modified? -- Cameron Moore [ Do Roman paramedics refer to IV's as 4's? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
John Check writes: While I'm at it... is there a chance we might see being able to include fully defined layers in instruments at some point? The best I can do now is layer include=whatever.xml transformations /layer You should be able to include a complete layer with this mechanism, i.e. layer include=Layers/gauge-face.xml/ where Layers/gauge-face.xml contains n PropertyList namegauge face/name texture pathAircraft/Instruments/Textures/vac-amp-oil.rgb/path x10.5078125/x1 y10.484375/y1 x21.0/x2 y20.9609375/y2 /texture w110/w h110/h /PropertyList Eventually, I guess you could have a separate subdirectory for each instrument, with a README, etc. Think of yourself as a fine craftsman, like a watchmaker. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
On Friday 21 December 2001 04:34 pm, you wrote: John Check writes: While I'm at it... is there a chance we might see being able to include fully defined layers in instruments at some point? The best I can do now is layer include=whatever.xml transformations /layer You should be able to include a complete layer with this mechanism, i.e. layer include=Layers/gauge-face.xml/ where Layers/gauge-face.xml contains n PropertyList namegauge face/name texture pathAircraft/Instruments/Textures/vac-amp-oil.rgb/path x10.5078125/x1 y10.484375/y1 x21.0/x2 y20.9609375/y2 /texture w110/w h110/h /PropertyList Right, thats exactly the limit of what we can do now but it just defines a texture cropping (which ain't bad). I was inquiring about the case of say, a glideslope needle as a fully self contained entity. Cut and paste works. Eventually, I guess you could have a separate subdirectory for each instrument, with a README, etc. Think of yourself as a fine craftsman, like a watchmaker. err.. uhh... umm.. whatever. I'd like to stay away from excessive directories. Maybe if the instruments were stored as tarballs All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
John Check writes: Eventually, I guess you could have a separate subdirectory for each instrument, with a README, etc. Think of yourself as a fine craftsman, like a watchmaker. err.. uhh... umm.. whatever. I'd like to stay away from excessive directories. Maybe if the instruments were stored as tarballs I think we are getting close to where we want a more flexible file system. We are already doing something along these lines with the Scenery. ie. when we look for a tile it can either have a .gz extension or not and we use the gzf__() functions on the compressed files and norman stdio f_() functions if it doesn't. This concept could fairly easily be extended to include directories. Kind of like Jar files in Java :-) We could even walk both the compressed and the uncompressed tree and use the 'newest' file for easy experimentation. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
Norman Vine wrote: John Check writes: Eventually, I guess you could have a separate subdirectory for each instrument, with a README, etc. Think of yourself as a fine craftsman, like a watchmaker. err.. uhh... umm.. whatever. I'd like to stay away from excessive directories. Maybe if the instruments were stored as tarballs I think we are getting close to where we want a more flexible file system. We are already doing something along these lines with the Scenery. ie. when we look for a tile it can either have a .gz extension or not and we use the gzf__() functions on the compressed files and norman stdio f_() functions if it doesn't. This concept could fairly easily be extended to include directories. The zlib functions handle uncompressed files so there shouldn't be any need for FILE* functions. BTW sg_gzifstream.open(const char* fname) attempts to open fname with and without the .gz extension. Kind of like Jar files in Java :-) We could even walk both the compressed and the uncompressed tree and use the 'newest' file for easy experimentation. Easy and slow. I remember someone once saying on this very list that file opening is a performance killer :) Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
* [EMAIL PROTECTED] (Norman Vine) [2001.12.21 19:25]: Bernie Bright writes: Norman Vine wrote: We could even walk both the compressed and the uncompressed tree and use the 'newest' file for easy experimentation. Easy and slow. I remember someone once saying on this very list that file opening is a performance killer :) It can be but . hope parsing XML configuration files should only be done once at startup time /hope Speaking of which, when I hit 's' to switch panel, it looks like we're reading the XML file each time. It funny that loading scenery doesn't cause any hiccups in performance but switching panels does. -- Cameron Moore -rw-r--r--1 cameron users 8 Oct 4 19:41 .signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Including instrumenst was: Re: [Flightgear-devel] c310 Panel
I found the following magazine review, which I used to fix the performance of the YASim model. It's the turbo variant. http://www.planeandpilotmag.com/content/specs/79cessnaturbo.html Also, this site, which is a buyer's guide for the 310 family, has lots of good trivia about equipment variation across the various models. I lifted the tank sizes from here. http://jtatwins.com/Tips%2014%20-%20Tips%20for%20Buying%20a%20Cessna%20310%20Part%20I%20Present%20Tense%20-%20How%20They%20Come%20in%201999.htm Yes, the file name on the server really is Tips 14 - Tips for Buying a Cessna 310 Part I Present Tense - How They Come in 1999.htm. No windows slaming here, that's a Mac user (or at least a Mac expatriot) if I ever saw one. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
