Re: [Flightgear-devel] Last Wonder of the World...
Julien Pierru wrote: Also how come the sand is not present in the scenery? I think it's simply not defined for that area in the VMAP0 dataset, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: easyxml.cxx tweak
Regarding the parsing problem where tabs were present in the config file, I believe I have fixed that - I had made a stupid error in the last changes. The fix was tested with the lightning config file in JSBSim standalone (where I had been able to reproduce the error). Jon --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
On Wednesday 22 March 2006 07:40, Julien Pierru wrote: Teotihuacan pyramid complex: http://flamebunny.homelinux.net/pics/fgfs/Teotihuacan.jpg (20m NE of Mexico City MMMX on heading 045); Nice, but we clearly see a nasty scenery bug there --- there is no river there in the real life... V. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Vassilii Khachaturov wrote: On Wednesday 22 March 2006 07:40, Julien Pierru wrote: Teotihuacan pyramid complex: http://flamebunny.homelinux.net/pics/fgfs/Teotihuacan.jpg (20m NE of Mexico City MMMX on heading 045); Nice, but we clearly see a nasty scenery bug there --- there is no river there in the real life... Well, calling this a scenery bug is not really precise, if there's no river in real live then this is a fault in the VMAP0 dataset. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Am Mittwoch, 22. März 2006 14:07 schrieb Martin Spott: Vassilii Khachaturov wrote: On Wednesday 22 March 2006 07:40, Julien Pierru wrote: Teotihuacan pyramid complex: http://flamebunny.homelinux.net/pics/fgfs/Teotihuacan.jpg (20m NE of Mexico City MMMX on heading 045); Nice, but we clearly see a nasty scenery bug there --- there is no river there in the real life... Well, calling this a scenery bug is not really precise, if there's no river in real live then this is a fault in the VMAP0 dataset. Probably there even is a river in real life, but it doesn't have a default width of 50m. I have seen many rivers in the FG scenery that are 4-10m wide in real life. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Probably there even is a river in real life, but it doesn't have a default width of 50m. I have seen many rivers in the FG scenery that are 4-10m wide in real life. I walked all around the place on foot (in real life, that is), and there are no rivers there... V --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Open Source Article
Nice. Next stop will be the AOPA journal... V --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Accepted flightgear 0.9.9-2 (source i386) (fwd)
On Wed, 22 Mar 2006 18:10:33 +1100 Pigeon wrote: And mind you, just a note with the current FG's configure, it will still link the final binary against glut even if you configure it with --enable-sdl. Yeah, this was my experience too. I opted for --enable-sdl because of all the concerns about freeglut2.4 mentioned here; but glut still got linked in. Mind you, I haven't had any obviously-related-to-glut problems, and freeglut2.4 is the only glut I have on this machine, so maybe --enable-sdl took care of the specific problems with freeglut2.4 that people had been experiencing. But nevertheless, it's still in there. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Martin Spott wrote: Vassilii Khachaturov wrote: Hmm, according to this, there is a canal that carries the San Juan river there. http://asterweb.jpl.nasa.gov/gallery/images/teotihuacan.jpg Strange... maybe it was not with water when I was walking there? According to the pictures, it would be difficult to miss... We should be happy that reality has always some surprise for us from time to time :-) I have a lot of stories of people swearing up and down that something in a simulation just isn't right ... doesn't feel right, doesn't look right, is scaled wrong, doesn't accelerate fast enough, etc. and then after going and examining the real world, it becomes clear that the simulation is spot on. Of course for each of those stories there are a 100 or so where the simulator was actually way off. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Well, the NASA pic is over thirty years old .. wasn't the canals drying up what nailed the civilization in the first place ?? There seems to be a surfeit of water in many places, there are some floating buildings in Boston harbour, perhaps FG is looking ahead thirty years and trying to tell us .. p :s/Note that //g = --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Martin Spott wrote: We should be happy that reality has always some surprise for us from time to time :-) Someone complained about the pylons running along next to the bridge across the bay on approach to KSFO. It seemed odd to me too, but I checked anyway and... http://maps.google.com/?ll=37.58635,-122.247148spn=0.005688,0.009559t=h It may be strange and unexpected, but it's definitely supposed to be there, and not a misinterpretation of the FAA data. -- Jon Stockill [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Julien Pierru wrote: http://maps.google.com/maps?ll=3D19.693701,-98.845561spn=3D0.016544,0.0217= 15t=3Dkhl=3Den In order to make this URL work you have to remove every occurrence of 3D and remove the = before the line break as well: http://maps.google.com/maps?ll=19.693701,-98.845561spn=0.016544,0.021715t=khl=en Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Am Mittwoch 22 März 2006 18:55 schrieb Julien Pierru: well there is definitely a canal down there, not sure if it is dried up or not: http://maps.google.com/maps?ll=19.693701,-98.845561spn=0.016544,0.021715t =khl=en Julien P.S:that thred definitely generated some interests, though not the one i was hoping for, lol... Well, Julien, this only means that the models are so well done, that there's nothing to criticize... :-) Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] generic-instruments.xml and a second DME device
After some debating in IRC ... Can we please add a second DME device to Generic/generic-instruments.xml? i.e. dme namedme/name number1/number /dme It is ***NOT*** possible to create extra devices within an aircraft's local config files. I've tried it and it does NOT work. All you end up with are some properties but nothing that drives them. The majority of large airliners have a DME device per NAV radio and don't feature DME switching between NAV 1 and NAV 2 like a lot of the smaller aircraft nav systems have. At the moment it's impossible to have two DME distances displayed in a cockpit. If the tacan, KT-70, wxradar, mk-viii which are not generic can live in generic-instruments.xml then I see no argument against a second dme instrument living in there too especially if that's the only place to do it. Thanks Paul --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/SimGear dsp/dsw files
As you know, the file NEEDED to compile FG is config.h. Several years back this was COPIED from config.h-msvc6, like what is done in many other open projects ... this is common ... people get used to this ... Of course, they can be very puzzled why, unless they are also quite familiar with the *nix, and cygwin 'automake' environments ... that some header.h.in is used to generate a header.h, with corrections, depending on what was found during a header file search ... but, ok, that can be understood ... Another point I was going to make about the newer config.h-msvc6.in is that is does contain an AUTOMAKE macro - @VERSION@ - If you want to KEEP this for use with cygwin, that is fine. Then why not put back a config.h-msvc6, just for the MSVC environment, with NO automake macro ... If you run ./configure, the config.h-msvc is generated from config.h-msvc.in ( you need cygwin installed ). Why would cygwin need config.h-msvc generated from config.h-msvc.in? cygwin generates config.h, the main file, from config.h.in, no? Why would cygwin need to 'generate' an intermediate file that it does not use ... plays no part in a cygwin build? ... And even the suggested 'run ./configure' would lead you to a cygwin mess ... just like in the MSVC environment, the folder where you loaded certain things IS VERY important, thus you need to run, something like - $ ./configure -prefix=/fg-cvs to generate the correct folder placement of items ... But this is all in the cygwin environment. Nothing really to do with raw a MSVC compile ... I hope it is not suggested a MSVC user download and install cygwin JUST to generate config.h-msvc so MSVC can use a custom make step to COPY this to config.h ... ;=)) * They don't work as is. This is agreed, but they are a good START ;=)) Due to many things, like where did you download PLIB, Simgear, zlib, OpenAL, etc, ... almost nothing would work out of the box, including any SLN/VCPROJ files, if provided ... unless you 'conform' 100% to the folder structure chosen by the SLN/VCPROJ providers ... And for example, I note from Olaf's site, the addition of pthreads, and freeglut ... other folders locations that would be important ... that must be 'correct' to suit the given SG/FG SLN/VCPROJ files ... * The dsw files are for VC6. Visual C 6 does not compile FlightGear (any more). As recently as a few months ago, I assisted a person, (offline) to compile using MSVC6. It does require some code 'work' to do this, but it is POSSIBLE ... none of this has been put forward as a 'change' in the CVS code ... so why should you care? Yes, you can suggest they download other 'tools', new 'tools' etc ... but also why not let them use what they have ... * They don't even work for newer Visual Studios (Dependencies are broken: Microsofts Fault, not our's) Not sure how this is related to removing the DSW/DSP file, or what is exactly refered to here. If it is refer to the fact that MSVC7.1, and perhaps 8, no longer seem to keep as good a automatic track of dependencies as good old MSVC6, then, as a 'developer' you get used to using 'remake all' ;=)) actually, I more frequently use the 'batch mode' ... But why is this any reason for removing this set of DSW/DSP files, automatically generated? * IMHO No developer uses them. As I suggested, 'developers' tend to find their own way ... have their own preferences, etc ... it is for the new, first time users that I want to encourage to 'become' developers that I feel for ... that need help ... These DSW/DSP files can be automatically generated by am2dsp.pl, enhanced fractionally a few months ago by Fred, using am2dsp.cfg, thus can be the first indication that a new file has been added, or some source removed ... or you can read/view the raw Makefile.am files directly ... They do work for MSVC7.1 ... it provides a good 'conversion' to its new xml format, leaving the DSW/DSP alone ... do not know about MSVC8, since I have yet to BUY, and use this extensively ... I have tried a few times with the 'express' (free for now) version, and it did a similar 'conversion' ... This is good in that in a CVS update, you can quickly compare your old with the new, to see if you need to update your SLN/VCPROJ files ... if that is what you use ... I would vote for including Fred's VC7.1 and/or my VC8 project files from http://www.oflebbe.de/oflebbe/FlightGear. There are surely some pitfalls I too have MSVC7.1 *AND* MSVC6 build file on my site - http://www.geoffmclane.com/fg/ - this is purely a factor of how frequently you 'update' your site ... or the cvs, if put in cvs. Sure Fred and Olaf want to move on ... then I agree perhaps the SLN/VCPROJ files should also be added to the CVS source, but that is no reason to delete the auto-generated, partial, incomplete, DSW/DSP files from CVS ... let all forms live ;=)) So what am I suggesting? Simply, that a config.h-msvc file be returned to cvs, so the current custom step in am2dsp.cfg works! And that, that
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Thank you Thomas ;)From the google map, for those of you who managed to see it, you can see with the larger zoom that either side of the canal the ground is green, that means that the canal still contains flowing water. However it is true that is width might not be larger than 2-4 m. I guess the sim is close enough in this case, it can't be a 100% accurate. My next project is gonna be more tricky as i am planning on recreating parts of Machu Picchu. The problem here is that the moutain shape has to be accurate, not a strongpoint of the scenery so far. Is there a way to manually change the shape of the mountains? Julien
Re: [Flightgear-devel] $FG_ROOT/version
I had the same problem yesterday so i just edited the version file to read 0.9.10 ;).But yeah that's a big omission...Julien
[Flightgear-devel] handbooks
Found a 747 / 737 manual if anyones interested ? http://mcrenox.com.ar/fs/ Regards, Justin Smithies --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] $FG_ROOT/version
Josh Babcock wrote: Just did a cvs up and got this: tower:~$ fgfs --aircraft=bf109 Base package check failed ... Found version 0.9.9 at: /usr/local/share/FlightGear/data Please upgrade to version: 0.9.10 Apparently the version file and fgfs are out of sync. Sorry, got caught with a distraction in my life between changing that and committing it. Do a cvs update now in the data directory and it should bring it into sync. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] .ac texture memory leak?
I haven't had a chance to look at this (and I may not have a chance any time soon) but someone has reported to me that they believe that the .ac loader is leaking memory in terms of texture loading. In other words, an OBJECT_STATIC is loaded and unloaded as we would want when a tile is loaded or unloaded, but the associated textures are not unloaded. This person is working on creating 3d visual objects for many DAFIF objects, airspaces, approaches, waypoints, etc. His automated tools can create a huge number of objects and he is finding that even though the .ac files seem to be unloaded, there is still a big memory leak as we fly, and he thinks it is that textures are not being freed. The more objects he includes, the shorter distances he can fly before his machine gives up and spits FlightGear into the bit bucket. There is something not right, the analysis may not yet be 100% right on, but we do appear to have a major leak someplace ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: .ac texture memory leak?
* Curtis L. Olson -- Wednesday 22 March 2006 23:16: someone has reported to me that they believe that the .ac loader is leaking memory in terms of texture loading. Which version? The loader itself (plib) shouldn't leak anything. Textures are refcounted like everything else, and freed if there's no user left. But ... In other words, an OBJECT_STATIC is loaded and unloaded as we would want when a tile is loaded or unloaded, but the associated textures are not unloaded. As I posted in thread model accumulation on Sat, 25 Feb 2006 23:08:04 we didn't unload static objects *at all*, until recently. So maybe this is what the complaint stems from. Since two weeks we *do* unload OBJECT_STATIC with the bucket branch, but still not OBJECT_SHARED, random objects, and objects managed by FGModelMgr. (And unloading those three types would probably not be such a bright idea.) there is still a big memory leak as we fly, and he thinks it is that textures are not being freed. Depends on the fgfs version. We never free some memory until exit -- the whole scene graph, for example. We apparently rely on the OS to do that. No idea if we keep grabbing memory needlessly, without ever freeing it at runtime. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear photo scenery
I've updated my site with 2 new screen shots of the progress I am making with the High-res texture set. http://mellonroot.acomp.usf.edu/~phoenix/gallery.html -Rob
[Flightgear-devel] b1900d questions.....
HI all , still working on the b1900d , not enough free time lately . I have a few questions , though How do I disable the gui autopilot menu? I see its disabled in the c182... but havent figured out how yet ... I know it was discussed before , I should have paid more attention :)! The flight dynamics seem a bit off , Im not sure if anyone modified them again , but it seems to want to stall at take off speeds... I want to fix that , but I think someone may have tweaked it to be more accurate ... and I'm no expert in that area... if everyone thinks its ok I'll leave it alone. One more - any votes on keeping or removing the popup GPS ? I personally dont care for it myself, but it made testing much easier I might as well try to fix as much as I can while I'm on a roll :). Cheers, Syd --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d questions.....
syd sandy wrote: One more - any votes on keeping or removing the popup GPS ? I personally dont care for it myself, but it made testing much easier I might as well try to fix as much as I can while I'm on a roll :). I vote to put the clickable regions directly on the panel. Josh --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d questions.....
same as Josh, clickable regions directly on the panel.Julien
Re: [Flightgear-devel] generic-instruments.xml and a second DME device
On Wed, 2006-03-22 at 20:41 +0200, Paul Surgeon wrote: After some debating in IRC ... Can we please add a second DME device to Generic/generic-instruments.xml? i.e. dme namedme/name number1/number /dme It is ***NOT*** possible to create extra devices within an aircraft's local config files. I've tried it and it does NOT work. All you end up with are some properties but nothing that drives them. It works for the Concorde in 0.9.9, I just checked. It has an aircraft specific Concorde-instruments.xml containing (among other things) !-- 2 DME frequencies -- dme namedme/name number0/number /dme dme namedme/name number1/number /dme and loads it from the concorde-set file with : instrumentation pathAircraft/Concorde/Systems/Concorde-instrumentation.xml/path /instrumentation Then uses it in Aircraft/Concorde/Panels/Instruments/concorde-dme.xml The majority of large airliners have a DME device per NAV radio and don't feature DME switching between NAV 1 and NAV 2 like a lot of the smaller aircraft nav systems have. At the moment it's impossible to have two DME distances displayed in a cockpit. If the tacan, KT-70, wxradar, mk-viii which are not generic can live in generic-instruments.xml then I see no argument against a second dme instrument living in there too especially if that's the only place to do it. TACAN is every bit as generic as DME or VOR. Every military aircraft produced since about 1950 has had a TACAN set installed. Thanks Paul --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: b1900d questions.....
* syd sandy -- Thursday 23 March 2006 05:45:
How do I disable the gui autopilot menu?
nasal
b1900d
scriptsettimer(func {gui.menuEnable(autopilot, 0)}, 1)/script
/b1900d
/nasal
Needs to be delayed, because gui.nas itself enables that entry with
settimer(..., 0).
One more - any votes on keeping or removing the popup GPS ?
I like it. What about offering both this *and* panel hotspots? :-)
m.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
