Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
* Mathias Fröhlich -- Wednesday 26 July 2006 22:49: Because it is not a limitation but rather a gain. A *well* *done* and *well* *supported* scenegraph will help you some much more than you probably can imagine now. You completely miss the point: we are using ssg! There was no decision made to switch to osg. So, if we switch to ssg wrappers first, we lose capabilities, that we may or may not get back later. I don't accept that and object. In fact, a proper design - like a well done scenegraph provides You miss the point. We are using ssg! So why should we limit ourselves in the long term with ssg? Fact is: we are using ssg. We may or may not switch to osg later. There has *no* decision been made, so we can't rip out stuff now that osg may provide later. The way to go is: - formal decision to switch to osg (or at least to start working on it) - generate osg branch in cvs - parallel development In the osg branch you can do with the HUD what you like. But not in the current, *SSG* branch. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d models
Hi all, just wondering on weather some one has looked into tapping into the 3d models that are available for downlaod from google earth? i think we maybeable to use these if we convert them as they are created by users of the sketchup program. any thoughts? Jason - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
Jon Stockill schreef: Jason Cox wrote: Hi all, just wondering on weather some one has looked into tapping into the 3d models that are available for downlaod from google earth? i think we maybeable to use these if we convert them as they are created by users of the sketchup program. any thoughts? It may be possible if the authors of the models are happy to release them under the GPL. The import script in the latest version of blender works well on geometry, but doesn't seem to support textures yet, so some retexturing may be required. Does Blender do KML files now? That's awesome! I do all of my modeling in SketchUp because it's 100 percent free and very intuitive to work with. If Blender has support for it, you can do the rendering / texturing / animating there or export it to 3DS or MAX or LWO or whatever. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
* Robin van Steenbergen -- Wednesday 26 July 2006 18:01: Does Blender do KML files now? Yes. $ head -18 ~/.blender/scripts/kmz_ImportWithMesh.py|tail -15 Name: 'Google Earth (.kml / .kmz)...' Blender: 241 Group: 'Import' Tip: 'Import geometry of .kml or .kmz 3D models' __author__ = Jean-Michel Soler (jms) __version__ = 0.1.8, june, 25, 2006 __url__ = Script's homepage, http://jmsoler.free.fr/didacticiel/blender/tutor/py_import_kml-kmz_en.htm; __bpydoc__ = \ Use this to read 3d geometry from .kml and .kmz (zipped .kml) files. Caution: the geometry data of the Google Earth's files on the web is licensed and you can not load or use it in a personnal work. Be aware that the contents of the file you try to read must be free or legally yours. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
Melchior FRANZ wrote: * Robin van Steenbergen -- Wednesday 26 July 2006 18:01: Does Blender do KML files now? Yes. $ head -18 ~/.blender/scripts/kmz_ImportWithMesh.py|tail -15 Name: 'Google Earth (.kml / .kmz)...' Blender: 241 Group: 'Import' Tip: 'Import geometry of .kml or .kmz 3D models' __author__ = Jean-Michel Soler (jms) __version__ = 0.1.8, june, 25, 2006 __url__ = Script's homepage, http://jmsoler.free.fr/didacticiel/blender/tutor/py_import_kml-kmz_en.htm; __bpydoc__ = \ Use this to read 3d geometry from .kml and .kmz (zipped .kml) files. Caution: the geometry data of the Google Earth's files on the web is licensed and you can not load or use it in a personnal work. Be aware that the contents of the file you try to read must be free or legally yours. So forget converting anything from their 3d warehouse - if you want to use a model you'll need to get it direct from the author. -- Jon Stockill [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
Jon Stockill wrote: Melchior FRANZ wrote: * Robin van Steenbergen -- Wednesday 26 July 2006 18:01: Does Blender do KML files now? Yes. $ head -18 ~/.blender/scripts/kmz_ImportWithMesh.py|tail -15 Name: 'Google Earth (.kml / .kmz)...' Blender: 241 Group: 'Import' Tip: 'Import geometry of .kml or .kmz 3D models' __author__ = Jean-Michel Soler (jms) __version__ = 0.1.8, june, 25, 2006 __url__ = Script's homepage, http://jmsoler.free.fr/didacticiel/blender/tutor/py_import_kml-kmz_en.htm; __bpydoc__ = \ Use this to read 3d geometry from .kml and .kmz (zipped .kml) files. Caution: the geometry data of the Google Earth's files on the web is licensed and you can not load or use it in a personnal work. Be aware that the contents of the file you try to read must be free or legally yours. So forget converting anything from their 3d warehouse - if you want to use a model you'll need to get it direct from the author. It sounds like we need to infiltrate google with FlightGear people. Can I get some volunteers to go get jobs there? I'll need a couple developers and at least one VP level manager type. We can solve this problem for ourselves at least from the inside out. :-) Or perhaps we could get a volunteer to purchase 51% of their stock? Curt. -- Curtis Olsonhttp://baron.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
Curtis L. Olson schreef: Jon Stockill wrote: So forget converting anything from their 3d warehouse - if you want to use a model you'll need to get it direct from the author. It sounds like we need to infiltrate google with FlightGear people. Can I get some volunteers to go get jobs there? I'll need a couple developers and at least one VP level manager type. We can solve this problem for ourselves at least from the inside out. :-) Or perhaps we could get a volunteer to purchase 51% of their stock? Curt. Are all their models from the 3D warehouse owned by Google? So if I submit something to the 3D Warehouse I essentially give up my rights? SketchUp is a great tool for scenery design. I'm working on an accurate model of Eindhoven Airport and you can actually put the ground chart of the airport on the 'floor' and model on top of that. Texturing can be done using Blender or 3DS or whatever, but SketchUp is great for defining geometry. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] awy.dat parsing code
Hi all, Ealier today, I posted a message here indicating my intentions of committing the airway database code into CVS. For some reason, that email still hasn't appeared on the list. In the mean time, however, I decided to go ahead and submit the code anyways. I had a few reasons for this 1) It's been in my development tree for such a long that it became a real pain to keep it cleanly separated from my other development work and in sync with CVS. 2) I'm having a few days off, with no particular plans, should anything be broken, now is the time to find out. 3). If the code doesn't run on some systems, one can always disable it by commenting out just 2 or 3 lines of code. Cheers, Durk - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] awy.dat parsing code
Hi all, Ealier today, I posted a message here indicating my intentions of committing the airway database code into CVS. For some reason, that email still hasn't appeared on the list. There was an issue with the SourceForge mailing lists yesterday. I think they are still catching up. If this persists, file a bug report with them. Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
Melchior, On Thursday 27 July 2006 09:58, Melchior FRANZ wrote: * Mathias Fröhlich -- Wednesday 26 July 2006 22:49: Because it is not a limitation but rather a gain. A *well* *done* and *well* *supported* scenegraph will help you some much more than you probably can imagine now. You completely miss the point: we are using ssg! There was no decision made to switch to osg. So, if we switch to ssg wrappers first, we lose capabilities, that we may or may not get back later. I don't accept that and object. In fact, a proper design - like a well done scenegraph provides You miss the point. We are using ssg! So why should we limit ourselves in the long term with ssg? Fact is: we are using ssg. We may or may not switch to osg later. There has *no* decision been made, so we can't rip out stuff now that osg may provide later. The way to go is: - formal decision to switch to osg (or at least to start working on it) - generate osg branch in cvs - parallel development In the osg branch you can do with the HUD what you like. But not in the current, *SSG* branch. I believe that you miss the point. The point is that we can, without loosing features, with a sensible design, prepare getting rid of ssg. As allmost allways, building sensible structures is a win even if no switch will happen. Just blocking that is not a good idea. ... did you ever look at the sceens of csp.sf.net? Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
* Mathias Fröhlich -- Thursday 27 July 2006 18:15: I believe that you miss the point. That may be ... The point is that we can, without loosing features, with a sensible design, prepare getting rid of ssg. As allmost allways, building sensible structures is a win even if no switch will happen. Sure. As I said: I'm still in favor of abstracting where possible, and of switching to OSG (when it has been officially decided!). I just won't drop raw gl-* commands when there is no replacement in ssg. This would be at least a temporary loss that is not justified. You said you have a lot of OSG transition work on your HD already, which is fine. This is a *hard* piece of work, and we will all profit from it. BUT: I don't disassemble fgfs in *CVS* now, when the propsed, better replacement is on *your HD* only. You can get hit by a lightning or run over by the proverbial bus, and all we have is a broken fgfs in *CVS*, with none of your improvements available. Just blocking that is not a good idea. I'm not blocking a good idea. I'm demanding a correct handling of the whole matter. (A) discussion, (B) decision, (C) branching, (D) entering the shiny world of osg. ... did you ever look at the sceens of csp.sf.net? occasionally, yes. I also have osg/head here and love to look at the stunning examples. And *still* I won't cripple the HUD code (even more) because of that. :-P m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers
* Melchior FRANZ -- Thursday 27 July 2006 18:31: (A) discussion, (B) decision, (C) branching, (D) entering the shiny world of osg. BTW: I would check this branch out, test it, and try to help, although I'm afraid that I can't do much. The whole scene graph thing isn't my thing, as you may have noticed. ;-) Meanwhile I'm reading the ssg documentation ... once again ... m. -- I could be wrong, of course. But I'm never wrong. -- Linus TORVALDS - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: FlightGear language support]
(I am resending this due to the faulty sf-mailing system which is troublesome since ca. 5 days) Georg Vollnhals schrieb: Hi, as there is an actual question about German language support in the German FG Forum I played a little around with 1. the start-parameters --language=de / --language=ger / --language=xxx 2. brute force method renamed strings-de.xml to strings-default.xml in FG/data/translations but nothing worked. -- It seems that this feature is actually no more supported or I did something wrong. -- If it is not actually supported, are there plans to get it back working again? (At least for the main menue with the sub-menues). Thank you for an answer as I want to give feedback to the German user (if no other did it until now). Regards Georg HeliFlyer EDDW ---BeginMessage--- Hi, as there is an actual question about German language support in the German FG Forum I played a little around with 1. the start-parameters --language=de / --language=ger / --language=xxx 2. brute force method renamed strings-de.xml to strings-default.xml in FG/data/translations but nothing worked. -- It seems that this feature is actually no more supported or I did something wrong. -- If it is not actually supported, are there plans to get it back working again? (At least for the main menue with the sub-menues). Thank you for an answer as I want to give feedback to the German user (if no other did it until now). Regards Georg HeliFlyer EDDW ---End Message--- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear language support
Hi, as there is an actual question about German language support in the German FG Forum I played a little around with 1. the start-parameters --language=de / --language=ger / --language=xxx 2. brute force method renamed strings-de.xml to strings-default.xml in FG/data/translations but nothing worked. -- It seems that this feature is actually no more supported or I did something wrong. -- If it is not actually supported, are there plans to get it back working again? (At least for the main menue with the sub-menues). Thank you for an answer as I want to give feedback to the German user (if no other did it until now). Regards Georg HeliFlyer EDDW - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Airway database parser
Hi all, I still have some code lingering around that reads and parses the contents of the FlightGear/ x-plane airway database (awy.dat.gz). I've never committed that code, because of the pre version 1.0 feature freeze period we were in. As it appears, plans have changed somewhat in this respect, and therefore I'd like to go ahead and commit this code within the next few days or so. Note that the only working code that currently makes use of the airway database is a highly experimental chunk of AI traffic airway following code, that doesn't work very well yet. In the long term, the database would be good for the dynamic display of airways in GPS units, or flight management computers. Cheers, Durk - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 7 page MFDs
I'm trying to build 3 MFDs that each have several pages --one has 7 or more ( the aircraft is still in development) I'm not sure what the simplest organization is. Nested layers seems complex as there as 6 instruments plus text and lables on several pages. I was thinking I would organize each page as a panel. so I tried giving the different panels the same name and looked for an array in the property tree that I might work with --didn't find anything. Is there a way to turn panels on and off? maybe I could add a switch statement somewhere in the source code that reads a property? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathias Fröhlich Sent: Thursday, July 27, 2006 10:16 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers Melchior, On Thursday 27 July 2006 09:58, Melchior FRANZ wrote: * Mathias Fröhlich -- Wednesday 26 July 2006 22:49: Because it is not a limitation but rather a gain. A *well* *done* and *well* *supported* scenegraph will help you some much more than you probably can imagine now. You completely miss the point: we are using ssg! There was no decision made to switch to osg. So, if we switch to ssg wrappers first, we lose capabilities, that we may or may not get back later. I don't accept that and object. In fact, a proper design - like a well done scenegraph provides You miss the point. We are using ssg! So why should we limit ourselves in the long term with ssg? Fact is: we are using ssg. We may or may not switch to osg later. There has *no* decision been made, so we can't rip out stuff now that osg may provide later. The way to go is: - formal decision to switch to osg (or at least to start working on it) - generate osg branch in cvs - parallel development In the osg branch you can do with the HUD what you like. But not in the current, *SSG* branch. I believe that you miss the point. The point is that we can, without loosing features, with a sensible design, prepare getting rid of ssg. As allmost allways, building sensible structures is a win even if no switch will happen. Just blocking that is not a good idea. ... did you ever look at the sceens of csp.sf.net? Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d models
On Wednesday 26 July 2006 12:53, Robin van Steenbergen wrote: I'm working on an accurate model of Eindhoven Airport and you can actually put the ground chart of the airport on the 'floor' and model on top of that. We have the capability to generate an airport directly out of the ground chart. Ampere - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] KLN89B implementation question
David Luff wrote: Check out the KLN89B with: $ fgfs --aircraft=c172p-2dpanel --geometry=1024x768 This is a panel-click only instrument - like the KAP140 it's not connected to the menu dialog. I finally got around to trying the KLN89B and was able to make it work. I tried to put it into the pa24-250 similar to the way I added the navcom-kx155 and the adf-radio. I added the following to the radio-panel.xml file (in ../pa24-250/Panel/): instrument include=../../Instruments/kln89.xml namekln89/name x256/x y450/y w576/w h152/h /instrument instrument include=../../Instruments/md41-52x-gps-annunciator.xml namemd41/name x330/x y1005/y w550/w h300/h /instrument special-instrument nameKLN89 GPS/name x200/x y440/y w512/w h128/h /special-instrument This actually worked but the data displayed by the special-instrument does not seem to scale when I change w and h values. I assume that this is because the display is hard coded pixels. Is there any way to get around this. The display seems to be half the size relative to the kln89 than would be appropriate. By the way, if you add this to the radio-panel.xml file, it will hide the dme which I moved to y295/y in my file. Thanks for any suggestions, Dave Perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear MP authentication
On Tuesday 25 July 2006 06:32, Julien Pierru wrote: A few questions arise, first what do you guys think about an authentication system, second what would be the best way of implementing it within FG and third would it be limited to be used by the tracking system or as a way of moderating the mp servers. I assume this would require changes to the packet protocol? Ampere - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear MP authentication
I know, this discussion is barely coupled to ongoing development, but because I like to participate in creating admirable plans, I don't want to miss it :-)) Buchanan, Stuart wrote: 2) Account holders have a key generated based on their call-sign (*). This is transmitted with the MP position data. The MP server uses it to authenticate the user. MP server doesn't need to check against the LDAP directory. I believe it is essential to verify a key against the directory because otherwise you won't be able neither to check if the key really belongs to the account holder nor to verify if it's still valid. I think the validity of a key has to be verified against the directory from time to time using a fixed interval. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
