Re: [Flightgear-devel] fgfs-builder repository
Hi, Arnt Karlsen wrote: On Wed, 06 Dec 2006 18:25:00 +0100, Ralf wrote in message [EMAIL PROTECTED]: Hi all, Douglas Campos has provided a Subversion repository for the fgfs-builder. The development version can be checked out at http://svn.qmx-systems.com/fgfsbuilder/trunk ..http://80.239.32.253/arnt/fgfsbuilder.trunk.revenge.of.theGIF.bug Try installing libungif4-dev. The dependency lists for Debian etch are currently not up-to-date. Cheers, Ralf - 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] fgfs-builder repository
On Thu, 07 Dec 2006 14:46:58 +0100, Ralf wrote in message [EMAIL PROTECTED]: Hi, Arnt Karlsen wrote: On Wed, 06 Dec 2006 18:25:00 +0100, Ralf wrote in message [EMAIL PROTECTED]: Hi all, Douglas Campos has provided a Subversion repository for the fgfs-builder. The development version can be checked out at http://svn.qmx-systems.com/fgfsbuilder/trunk ..http://80.239.32.253/arnt/fgfsbuilder.trunk.revenge.of.theGIF.bug Try installing libungif4-dev. The dependency lists for Debian etch are currently not up-to-date. ..thanks, will try that after I see how the stable branch crash on that same job (make enable-FlightGear ;make all), it's still running. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - 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] fgfs-builder repository
Hi, Arnt Karlsen wrote: ..thanks, will try that after I see how the stable branch crash on that same job (make enable-FlightGear ;make all), it's still running. :o) Yeah, I'm thinking about disabling some of the OSG plugins or features by default to reduce compile time. Perhaps we can also remove the plib scenegraph stuff, if it's not used by other tools (fgsd, fgrun, TerraGear). Cheers, Ralf - 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] Addressing the discontinuity that occurs when using discrete terrain altitude data during landing...
Hi! I've been working on a prototype flight simulator and I'm running into an issue I have no idea how to solve, so I decided to ask here since this very same problem might have been addressed in FlightGear. I want to model the landing of my aircraft. My problem lies in the altitude data. The data I have to use is a pixel map, which means that one square (which has around 100 meters side) has a certain value of altitude and the adjacent square has a completely different value... This means that if I try to land the aircraft in the border between two squares... it will either fall down or crash against this virtual discontinuity! I'm betting there's an obvious solution to this, but I'm out of ideas!... Any suggestions? Thanks! Antonio DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA. - 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] Addressing the discontinuity that occurs when using discrete terrain altitude data during landing...
On 12/7/06, Antonio Almeida wrote: I've been working on a prototype flight simulator and I'm running into an issue I have no idea how to solve, so I decided to ask here since this very same problem might have been addressed in FlightGear. I want to model the landing of my aircraft. My problem lies in the altitude data. The data I have to use is a pixel map, which means that one square (which has around 100 meters side) has a certain value of altitude and the adjacent square has a completely different value... This means that if I try to land the aircraft in the border between two squares... it will either fall down or crash against this virtual discontinuity! I'm betting there's an obvious solution to this, but I'm out of ideas!... Any suggestions? In FlightGear, our terrain is modeled as an irregular mesh of triangles. We can lookup the terrain elevation at any point. As you move the terrain elevation value will change smoothly. It's not smooth in the sense of the first or second derivative, but that doesn't cause us a problem, especially on airport surfaces because we go to extra precautions to make sure all the elevation points are fitted to a smoothed surface (that approximates the original terrain data.) You might want to consider turning your grid of elevation heights into a triangle mesh (which you must have to do in order to render the data) and then sample your elevations off the mesh rather than the original data. Or maybe you could just interpolate between mesh points ... that might be even simpler. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ 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] Addressing the discontinuity that occurs when using discrete terrain altitude data during landing...
Your altitude must be computed as the average of the surrounding squares or the position on the sloping line between two points if you really want it to match the graphics. On Thu, 7 Dec 2006 8:56 am, Antonio Almeida wrote: Hi! I've been working on a prototype flight simulator and I'm running into an issue I have no idea how to solve, so I decided to ask here since this very same problem might have been addressed in FlightGear. I want to model the landing of my aircraft. My problem lies in the altitude data. The data I have to use is a pixel map, which means that one square (which has around 100 meters side) has a certain value of altitude and the adjacent square has a completely different value... This means that if I try to land the aircraft in the border between two squares... it will either fall down or crash against this virtual discontinuity! I'm betting there's an obvious solution to this, but I'm out of ideas!... Any suggestions? Thanks! Antonio DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA. www.GlobalBoiling.com for daily images about hurricanes, globalwarming and the melting poles. www.ElectricQuakes.com daily solar and earthquake images. - 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] Latest OSG note...
On Thursday 07 December 2006 07:20, syd wrote: I just compiled CVS OSG tonight (avoiding the broken Producer) and everything compiled fine , no errors, but I get a steady stream of Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) while running Flightgear.It doesnt seem to effect performance , but doesnt leave room for any other messages. Has this been seen by anyone else, or any idea where to begin looking for the cause of the problem ? I also see this. It seems to only happen when there is a light (airport lights, vasi etc.) visible in the scene. -- Roy Vegard Ovesen - 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] Latest OSG note...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roy Vegard Ovesen wrote: On Thursday 07 December 2006 07:20, syd wrote: I just compiled CVS OSG tonight (avoiding the broken Producer) and everything compiled fine , no errors, but I get a steady stream of Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) while running Flightgear.It doesnt seem to effect performance , but doesnt leave room for any other messages. Has this been seen by anyone else, or any idea where to begin looking for the cause of the problem ? I also see this. It seems to only happen when there is a light (airport lights, vasi etc.) visible in the scene. Is this on a Mac? If so, there's been some email about this on osg-users. Perhaps another CVS update would fix it. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFeE6peDhWHdXrDRURAtMnAJ4kUrDndPq2HOcEeV1TWgFygRgZ5QCgxyEi 8Whd7KNC12UwXe9egw8HvNw= =kZS8 -END PGP SIGNATURE- - 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] nasal hash question
Josh Babcock wrote:
foreach(light; lights) {
propertyPath = 'some/path/'~light;
# do magic to the hash lightNodes here
# So that a node linked to propertyPath
# with a key of light gets added to lightNodes
}
The hash/vector index expression is an lvalue that can be assigned as
well as inspected. So it's just:
foreach(light; lights) { lightNodes[light] = propertyPath; }
Andy
-
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] PRE_OSG_PLIB_random number branch in data/
On Wednesday 06 December 2006 19:09, Melchior FRANZ wrote: I hereby declare that branch in the data/ dir dead. There are *no* differences between that PLIB branch and HEAD, except those that were caused by the synchonization horror. Some people don't Not true: As extensively discussed on the mailing list (and agreed upon by most developers prior to the switch), the main development effort should focus on an OSG based flightgear in CVS HEAD, after branching off a stable version intended for bugfixes and a possible release. I'm in the process of reorganizing the directory structure of AI traffic in CVS HEAD, and this aready has had some ramifications for the base package. Since I consider this a new feature, I'm focusing my efforts on CVS HEAD only, and leave the existing directory structure as it was in CVS PLIB (both code and data). So, the natural way is that new features / Aircraft go into CVS head (and CVS HEAD only), while CVS PRE OSG should be maintained for bugfixes only. know that such a branch exists and hence don't commit there, others don't commit there although they know it. And I'm tired of the useless double commits and won't continue them. HEAD still works for the PLIB_OSG_PRE_... executable version. Well, there's no reason to, as CVS PLIB should only be maintained for apparent bugfixes. CVS HEAD is improving at a rapid pace (Congrats Matthias), but until we have all the functionality of we should keep a separate branch of a matching data dir. Once OSG FlightGear is up to specs, the PLIB branches can be jettisoned, but not before that time. I suggest, that a PLIB branch (yes, only PLIB, without the random number) be created for only those *files* that *really* need a PLIB and a OSG version. Not the whole data/ dir, and also not a whole aircraft dir. And whoever does that shall be the only one responsible for synchronization. :-P m. PS: the PRE_OSG_PLIB_random number branch should probably be removed Nope. 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] PRE_OSG_PLIB_random number branch in data/
* Durk Talsma -- Thursday 07 December 2006 19:04: On Wednesday 06 December 2006 19:09, Melchior FRANZ wrote: I hereby declare that branch in the data/ dir dead. There are *no* differences between that PLIB branch and HEAD, except those that were caused by the synchonization horror. Some people don't Not true: As extensively discussed on the mailing list (and agreed upon I do no longer agree, and I stop committing to the PLIB branch. You, Mathias and I were the only ones committing to both branches. Everyone else only committed to HEAD, no? And now I will also only commit to HEAD. All my commits to HEAD work for PLIB, anyway, and I intend to keep it at that. If AI is the only part with two versions, then it's easy enough to extract HEAD for all, and the PLIB branch for AI only. 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] PRE_OSG_PLIB_random number branch in data/
* Melchior FRANZ -- Thursday 07 December 2006 19:12: You, Mathias and I were the only ones committing to both branches. Everyone else only committed to HEAD, no? Oh, and Fred. 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] PRE_OSG_PLIB_random number branch in data/
Selon Melchior FRANZ : * Melchior FRANZ -- Thursday 07 December 2006 19:12: You, Mathias and I were the only ones committing to both branches. Everyone else only committed to HEAD, no? Oh, and Fred. Yes, to backport Durk's work. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - 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] PRE_OSG_PLIB_random number branch in data/
On Thursday 07 December 2006 20:18, Frederic Bouvier wrote: Selon Melchior FRANZ : * Melchior FRANZ -- Thursday 07 December 2006 19:12: You, Mathias and I were the only ones committing to both branches. Everyone else only committed to HEAD, no? Oh, and Fred. Yes, to backport Durk's work. Actually, Fred just beat me in responding. :-) I actually haven't committed anything to CVS PLIB yet, but have a few bug fixes floating around that need to go into CVS PLIB. I've been out of the loop for a while, so I didn't have a chance to do so yet... 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] PRE_OSG_PLIB_random number branch in data/
On Thursday 07 December 2006 19:12, Melchior FRANZ wrote: I do no longer agree, and I stop committing to the PLIB branch. You, Mathias and I were the only ones committing to both branches. Everyone else only committed to HEAD, no? And now I will also only commit to HEAD. All my commits to HEAD work for PLIB, anyway, and I intend to keep it at that. Just to clarify: I actually agree (quite strongly) that minimizing double commits is a good thing. New features and new aircraft should probably just go into HEAD, as that is the version that we want to push forward in the long run. If AI really remains the only change, your solution might be workable, but the longer we keep a branched version, the more likely it becomes that there will be more data restructuring. And then we might regret the decision to have dumped the CVS PLIB base directory. So from that perspective, I'd still argue to keep it for a while, albeit with minimum maintenance. ;-) 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] PRE_OSG_PLIB_random number branch in data/
* Durk Talsma -- Thursday 07 December 2006 20:33: If AI really remains the only change, your solution might be workable, but the longer we keep a branched version, the more likely it becomes that there will be more data restructuring. And then we might regret the decision to have dumped the CVS PLIB base directory. So from that perspective, I'd still argue to keep it for a while, albeit with minimum maintenance. ;-) Yes, something like that. I don't want to boycott the PLIB branch, but it has become very tedious to commit everything to both. And when I tried to, I ran into files where others have only committed to HEAD, and I would have had to decide whether *I* wanted to sync them (no fun), or risk making a bigger mess. And that although several people already said that they use the PLIB binary with HEAD data, which still works fine. (With the exception of AI, maybe, but after all the tower.cxx crashes I haven't used that much.) I'll continue to commit changes to both source branches, as we still can't say for sure, from which branch the next release will be made (or can we?). 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] PRE_OSG_PLIB_random number branch in data/
Hi, Durk Talsma schrieb am 07.12.2006 20:33: If AI really remains the only change, your solution might be workable, but the longer we keep a branched version, the more likely it becomes that there will be more data restructuring. If AI is the only thing needing a new data structure: Why not add these patch to the plib-branch? Durk Talsma schrieb am 07.12.2006 19:04: Not true: As extensively discussed on the mailing list (and agreed upon by most developers prior to the switch), the main development effort should focus on an OSG based flightgear in CVS HEAD, after branching off a stable version intended for bugfixes and a possible release. Oh, did I miss something? I remember posts with the idea, to port stable improvements / finished developments to the plib branch... Maik - 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] osg/plib, difference in collision detection
Hi, is this a bug or a feature? While plib-fg does not detect collisions with cows and multiplayer aircrafts, osg-fg does detect. If another player starts in multiplayer on the same position, e.g. where I am spinning up the rotor of a heli), my heli crashes. Maik - 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] PRE_OSG_PLIB_random number branch in data/
On Thursday 07 December 2006 20:54, Melchior FRANZ wrote: * Durk Talsma -- Thursday 07 December 2006 20:33: If AI really remains the only change, your solution might be workable, but the longer we keep a branched version, the more likely it becomes that there will be more data restructuring. And then we might regret the decision to have dumped the CVS PLIB base directory. So from that perspective, I'd still argue to keep it for a while, albeit with minimum maintenance. ;-) Yes, something like that. I don't want to boycott the PLIB branch, but it has become very tedious to commit everything to both. And when I tried to, I ran into files where others have only committed to HEAD, and I would have had to decide whether *I* wanted to sync them (no fun), or risk making a bigger mess. And that although several people already said that they use the PLIB binary with HEAD data, which still works fine. (With the exception of AI, maybe, but after all the tower.cxx crashes I haven't used that much.) I'll continue to commit changes to both source branches, as we still can't say for sure, from which branch the next release will be made (or can we?). Agreed. Btw, with the additional explanation, your original mail starting this thread actually makes a lot more sense now. Thanks, :-) 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] nasal hash question
Andy Ross wrote:
Josh Babcock wrote:
foreach(light; lights) {
propertyPath = 'some/path/'~light;
# do magic to the hash lightNodes here
# So that a node linked to propertyPath
# with a key of light gets added to lightNodes
}
The hash/vector index expression is an lvalue that can be assigned as
well as inspected. So it's just:
foreach(light; lights) { lightNodes[light] = propertyPath; }
Andy
Yeah, I got confused by another error I made. The problem was that I was
trying to reference a vector like a hash. Once I defined the hash
properly it started to work. I just forgot to say so here :(
Josh
-
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] fgfs CVS/OSG; patch for renderer.cxx
* Mathias Fröhlich -- Sunday 03 December 2006 12:56: I still build upon the patched osg-1.2 version. So I will only do that change in cvs if most of the others tell me that they want to use osg-cvs too. OK, that's a solid 2:0 for cvs then. :-} 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] Info request on airport radar.
Hi Roberto, Roberto Inzerillo wrote: Is that a fixed rpm or are there different speeds for different radar types? Any hint on tech specs about that? If possible, I'd like to make its movement close to the real one. I'd love to hand you some real specs but actually I don't have the slightest idea where to find such thing. From memory I'd say one turnaround of the long-distance radar that's located at EDDL is about 2.5 sec (once I visited the TWR at EDLN and they-re connected to the EDDL radar). Ground radar might be below 2 sec. I get close past EDDL by car several times a month, but typically I'm in hurry. Next time I'll try to take some spare minutes with me and figure the actual RPM - if that's precise enough for you, 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
