Re: [Flightgear-devel] FGPositioned refactoring
James Turner wrote: I'd quite like to move forwards on this tonight, but I'd appreciate a bit more assent or criticism before I get too much further into the code. I'd say, if people don't care about responding for several days, they loose their qualification to criticize afterwards well, some might still try to apply criticism but I'd then count this as 'unqualified' So, if I were you and you think your design proposal is really well thought out, then I'd simply put your favorite heat protective suit on and go ahead :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Further FGRunway work
I've been working on my FGPositioned ideas in a local git tree, to get a feel for the scale of the changes. One thing I did last night was the slightly painful conversion of FGRunway to be heap, instead of stack based. One interesting thing I've come across is how the runway _length and _width fields are used - it turns out they're pretty much always used to calculate some particular positions on the runway, notably the threshold and the 'other end' point (sorry, there must be a better piece of terminology than that), or some offset from those points - eg five metres in, or several NM 'out' along the extended runway centreline. A few users are using the width to find the runway corners, and sometimes to perform a 'is point inside the runway' test - including the ATCDCL code, the Mk-VIII, the groundradar and the runway HUD instrument. All of which is fine, except in each case we get an ugly block of 'geo_direct_wgs_84' calls at each use site. So, I'm going to add some helpers to Runway - to return the threshold point directly, or a point on the extended centerline at an offset (in metres) from the threshold, and probably some other helpers to get the corners, and do a 'is point inside the runway' test. But, doing this, I wondered - there's these displaced threshold and stopway values in Robin's data, which we are parsing, storing in memory, and which are never used by any C++ code - they do get passed to Nasal, but I'd bet some money no one on that sides uses them either. Should I be checking them when computing my threshold point? Right now, everything is using the runway lat/lon, then moving half the runway length to get the threshold. I have the feeling I should be either adding or subtracting the threshold displacement value, but I don't know which. Or perhaps the displaced threshold offset is irrelevant to some / most people, and should be a separate, explicit accessor. Clearly people computing the runway corners / edges want the edge of the paved surface, but I wonder if (for example) the fg_init code that positions the plane at the runway threshold would be better using the displaced value? And I don't have a clue about the stopway information, any insight would be appreciated. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Window controls
Hey. I was just wondering if anyone could point me in the direction of the window controls in FG 1.0.0. I know FGRenderer.resize has to do with the viewport. I'm actually looking for the window dimensions, full screen mode, etc. I'm passing information to a camera, and it needs to know how large the window is at any given moment. Thanks. -cullam - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further FGRunway work
James, I can't tell much about the use cases in the FlightGear code, just from real-life experience. Take this as an aide, if it helps you - if it doesn't help, I dont mind you ignoring it silently :-) James Turner wrote: One interesting thing I've come across is how the runway _length and _width fields are used - it turns out they're pretty much always used to calculate some particular positions on the runway, notably the threshold and the 'other end' point (sorry, there must be a better piece of terminology than that), or some offset from those points - eg five metres in, or several NM 'out' along the extended runway centreline. Personally I'd simply call this 'other end' the 'opposite threshold' - but I'm not a native English speaker, so there might be a different, 'official' definition for it. When you look at the 'data/Scenery/Airports/K/H/A/KHAF.threshold.xml' file for example, then you'll realize that the notation almost matches the use case you're describing here: Threshold position plus the heading along the centerline. In real-life, the displaced threshold doesn't count for takeoff - you're going to begin your start run wherever you enter the runway, shortly behind the 'reglar' threshold. I guess, this should (logically) also apply for the cases when a certain threshold offset is being calculated in FlightGear for takeoff. The stopway is a different thing. It lies outside the area that's being embraced by the two regular thresholds, you don't use it for takeff, you should not use it for landing - but it might serve as your life insurance if you're too-high-to-fast during aproach Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] only a stupid question about FG and .fgfsrc
Hello, When loading FlightGear, fgfs looks for the file .fgfsrc which contains ( if we have created it ) a lot of data/parameters --config= , --geometry=, and so on. Is there any way to tell to fgfs to look for an other file for instance .fgfsspe1 ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Window controls
On Wed, Aug 20, 2008 at 1:48 PM, cullam Bruce-Lockhart [EMAIL PROTECTED] wrote: I'm actually looking for the window dimensions, full screen mode, etc. I'm passing information to a camera, and it needs to know how large the window is at any given moment. Thanks. The window size is available in the property tree as /sim/startup/xsize and ysize. Alternatively you could use a generic method to find the FG window and query its properties. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further FGRunway work
On 08/20/2008 04:44 AM, James Turner wrote: ... the threshold and the 'other end' point (sorry, there must be a better piece of terminology than that), Standard terminology gives you a couple of options: A) For a given runway, we have -- the arrival end, and -- the departure end. B) For a given runway, we have -- that runway itself, and -- the reciprocal runway. In the context of the active runway, there is a preference for option (A), for obvious reasons. In other contexts, for instance a discussion of displaced thresholds, option (B) would make more sense. there's these displaced threshold and ... Should I be checking them when computing my threshold point? In a word, yes. Officially there is only one threshold. If there is a displaced threshold, it is displaced relative to the beginning of the runway; it is not displaced relative to some other threshold. Reference: http://www.faa.gov/airports_airtraffic/air_traffic/publications/atpubs/PCG/T.HTM http://www.faa.gov/airports_airtraffic/air_traffic/publications/atpubs/PCG/D.HTM - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] only a stupid question about FG and .fgfsrc
Hi Gerard, The ~/.fgfsrc file is hardwired into the program. However you could remove this file or leave it empty (or put options in there that you always want no matter what.) From there you can specify additional xml config files with custom options using the --config=/path/to/xml/configfile.xml or you could create a shell script for each desired configuration that specifies the custom options on the command line. In my ~/.fgfsrc file I have a several different configurations commented out, and the uncomment specific sections when I want to run in that particular mode (i.e. normal flight versus UAV visualization versus multimonitor, etc.) There is probably a reasonably easy way to accomplish whatever your goal is here. Regards, Curt. On Wed, Aug 20, 2008 at 7:38 AM, gerard robin wrote: Hello, When loading FlightGear, fgfs looks for the file .fgfsrc which contains ( if we have created it ) a lot of data/parameters --config= , --geometry=, and so on. Is there any way to tell to fgfs to look for an other file for instance .fgfsspe1 ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Hey Martin, I guess I'd like to ponder this a little while longer. Should be no problem to use the existing mapserver name (i.e. not having git.flightgear.org just yet doesn't impede anyone's development progress), and I guess I'd like to spend some more time thinking about how official we want to make our project's git support. Regards, Curt. On Mon, Aug 18, 2008 at 3:26 AM, Martin Spott [EMAIL PROTECTED]wrote: Pigeon wrote: Ah, I did not notice it's only providing http access. The last time I tried (maybe a year ago) http was much much slower than git's protocol. I think git protocol access is definitely a ++ :) Ok, try it out - I've adjusted the instructions accordingly at: http://mapserver.flightgear.org/git/gitweb.pl Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Hi Curt, Hi Martin, how git is supported on systems that are not Linux ? -Fred - Curtis Olson a écrit : Hey Martin, I guess I'd like to ponder this a little while longer. Should be no problem to use the existing mapserver name (i.e. not having git.flightgear.org just yet doesn't impede anyone's development progress), and I guess I'd like to spend some more time thinking about how official we want to make our project's git support. Regards, Curt. On Mon, Aug 18, 2008 at 3:26 AM, Martin Spott [EMAIL PROTECTED]wrote: Pigeon wrote: Ah, I did not notice it's only providing http access. The last time I tried (maybe a year ago) http was much much slower than git's protocol. I think git protocol access is definitely a ++ :) Ok, try it out - I've adjusted the instructions accordingly at: http://mapserver.flightgear.org/git/gitweb.pl Martin. -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Frederic ! Frederic Bouvier wrote: how git is supported on systems that are not Linux ? Depends on whom you ask. I know that GIT support on Windows machines had been somewhat whacky for quite a while. Primarily GIT had been relying on some Unix filesystem features that had not been available on Windows - Mac OS X is not an issue because it basically is a Unix. I suspect James Turner is successfully using GIT on the Mac. I know about this GIT client implementation on Windows: http://code.google.com/p/msysgit/ but I don't have any opportunity to check wether it works. I'd welcome you to try it out and report back on this very list. Salut, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
On Wed, Aug 20, 2008 at 2:43 PM, Frederic Bouvier wrote: Hi Curt, Hi Martin, how git is supported on systems that are not Linux ? joking Download Virtual Box from sun (free) and run Linux in a virtual machine on your mac/windows host. /joking That said, if anyone is looking for a fun toy ... VirtualBox is pretty cool. I've got Vista running in a virtual machine on my Linux host and it works amazingly well. I'm not getting all of Vista's fancy effects (a good thing?) but otherwise both OS's run lickity split on the same hardware at the same time, even with FlightGear going full tilt on the Linux side ... pretty cool stuff! more seriously The lack of windows support is a serious knock against using git in a multi-platform project. Has this been addressed since I looked into this the last time, or are there plans to address it? /more seriously What Martin is referring to is a read only git mirror of the official FlightGear CVS repository so it should cause no harm as long as we are careful not to develop official dependencies that can only be supported on a single operating system. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Hi, Could be that this message comes twice due to an error I had from my mailprovider... GIT: I did test it some days ago, and it works, but it is not very comfortable. Well, not for me without any background in programming etc. The current SVN and CVS-clients are more comfortable. So in the moment I would like to see, that for releases and official things we keep on CVS( or maybe SVN?) Regards HHS --- Martin Spott [EMAIL PROTECTED] schrieb am Mi, 20.8.2008: Von: Martin Spott [EMAIL PROTECTED] Betreff: Re: [Flightgear-devel] GIT; Was: _Sport Model_ An: flightgear-devel@lists.sourceforge.net Datum: Mittwoch, 20. August 2008, 21:51 Frederic ! Frederic Bouvier wrote: how git is supported on systems that are not Linux ? Depends on whom you ask. I know that GIT support on Windows machines had been somewhat whacky for quite a while. Primarily GIT had been relying on some Unix filesystem features that had not been available on Windows - Mac OS X is not an issue because it basically is a Unix. I suspect James Turner is successfully using GIT on the Mac. I know about this GIT client implementation on Windows: http://code.google.com/p/msysgit/ but I don't have any opportunity to check wether it works. I'd welcome you to try it out and report back on this very list. Salut, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Migrating from CVS to SVN would already be a very good thing IMO
-Fred
- Heiko Schulz a écrit :
Hi,
Could be that this message comes twice due to an error I had from my
mailprovider...
GIT:
I did test it some days ago, and it works, but it is not very
comfortable. Well, not for me without any background in programming
etc.
The current SVN and CVS-clients are more comfortable. So in the moment
I would like to see, that for releases and official things we keep on
CVS( or maybe SVN?)
Regards
HHS
--- Martin Spott schrieb am Mi, 20.8.2008:
Datum: Mittwoch, 20. August 2008, 21:51
Frederic !
Frederic Bouvier wrote:
how git is supported on systems that are not Linux ?
Depends on whom you ask. I know that GIT support on Windows
machines
had been somewhat whacky for quite a while. Primarily GIT
had been
relying on some Unix filesystem features that had not been
available on
Windows - Mac OS X is not an issue because it basically is
a Unix. I
suspect James Turner is successfully using GIT on the Mac.
I know about this GIT client implementation on Windows:
http://code.google.com/p/msysgit/
but I don't have any opportunity to check wether
it works. I'd
welcome you to try it out and report back on this very
list.
Salut,
Martin.
--
Unix _IS_ user friendly - it's just selective about
who its friends are !
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery - album photo
http://fgsd.sourceforge.net/ FlightGear Scenery Designer
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Heiko, Heiko Schulz wrote: The current SVN and CVS-clients are more comfortable. So in the moment I would like to see, that for releases and official things we keep on CVS( or maybe SVN?) The (my) GIT mirror doesn't intend to replace Curt's CVS service, at least not in the near future. Nevertheless I have in mind to propose a switchover to GIT once the Windows support has proven to be reliable in all modes of operation. BTW, in case of demand I'd consider enabling read-only CVS pservice as an alternative frontend to this GIT repo. In the current state it's primarily meant as an option for those who are not entirely happy with the current CVS service, those who can live with a certain delay - source repositories are being synced every for hours, the data repo every six hours - but who like the network performance of this GIT service - in fact it's the best-networked repository service FlightGear ever had :-) Best Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
Frederic Bouvier wrote: Migrating from CVS to SVN would already be a very good thing IMO -Fred Sure enough. But if we take a migration into consideration, we sould probably go the GIT route. Although I'm not too experienced with git when it comes to committing things to it, from the git pull side, it looks pretty nice. I don't know however how it performs with binary data, which would be nice to know for flightgear-data. IMHO, the current solution as read-only is a good way to test it from one side and maybe later move more stuff to it. Cheers Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT; Was: _Sport Model_
On Wed, Aug 20, 2008 at 3:27 PM, Martin Spott wrote: The (my) GIT mirror doesn't intend to replace Curt's CVS service, at least not in the near future. Nevertheless I have in mind to propose a switchover to GIT once the Windows support has proven to be reliable in all modes of operation. BTW, in case of demand I'd consider enabling read-only CVS pservice as an alternative frontend to this GIT repo. In the current state it's primarily meant as an option for those who are not entirely happy with the current CVS service, those who can live with a certain delay - source repositories are being synced every for hours, the data repo every six hours - but who like the network performance of this GIT service - in fact it's the best-networked repository service FlightGear ever had :-) The current cvs server has 100Mbit to the switch, and then Gig-e out to the rest of the world. So for 99.999% of the folks out there, the network bottleneck will be at their own end of the pipe. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Curt, there's yet another point: Curtis Olson wrote: What Martin is referring to is a read only git mirror of the official FlightGear CVS repository so it should cause no harm as long as we are careful not to develop official dependencies that can only be supported on a single operating system. The FlightGear project has been notoriously behind about getting people's source code contributions into CVS - for years. We all know the story, it's been the same for years already, no need to repeat it here. So, in order not to loose the respective contributions over the time, such a GIT repo - be it mine or someone else's - makes the perfect tool that allows contributors to maintain their changes in a local branch while still easily keeping them in sync with the main source tree(s). Thus, it will be highly beneficial for the FlightGear project as a whole to support these developers by backing an official GIT repo instead of letting their enthusiasm fade out in disappointment Guess why there are there so many private GIT repositories containing modified versions of FlightGear source trees !? Please think of it and keep up with the times. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Martin Spott wrote: The FlightGear project has been notoriously behind about getting people's source code contributions into CVS - for years. We all know the story, it's been the same for years already, no need to repeat it here. So, in order not to loose the respective contributions over the time, such a GIT repo - be it mine or someone else's - makes the perfect tool that allows contributors to maintain their changes in a local branch while still easily keeping them in sync with the main source tree(s). Thus, it will be highly beneficial for the FlightGear project as a whole to support these developers by backing an official GIT repo instead of letting their enthusiasm fade out in disappointment Guess why there are there so many private GIT repositories containing modified versions of FlightGear source trees !? Please think of it and keep up with the times. Ah, great to hear this from you, Martin. This does BTW not only apply to the FG source code, but also to the scenery and flightplans... ;-) Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Blackout/Redout
Hello, I have included within the FG SR71-Blackbird a FDM Systems blackout.xml file. It activate redout or blackout in the cockpit view. I it is not perfect, it could be improved. The values estimated are the following: -the time to blackout to 5g is 300 seconds (like said by Eric on the Flightgear-devel) -the time to redout to -4g is 1 second, -and the duration time for the progressive shading from clear to dark (or red) is 4 seconds. (which gives 304 second for full dark and 5 second for full red) I mainly wonder if the basic calculation for the g-load is right. I have copied from the F16 (by Eric) the g load corrected which is summer name=g load corrected inputaccelerations/n-pilot-z-norm/input input-fcs/n-pilot-z-correction/input /summer Any idea on it. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT / SVN
On 20 Aug 2008, at 21:14, Frederic Bouvier wrote: Migrating from CVS to SVN would already be a very good thing IMO Just to add some data to this - git works great on the Mac, or any Unix, but I believe it's never going to fly (if you'll pardon the expression) on Windows, due to technical limitations there - git works great with the current setup (read-only repo mirrored from CVS). For local development, if you can, and want to use it, it's pretty nice (I think Melchior has said the same thing) - I'd be quite happy using git's patch submission features to flood people's inboxes with patches :) Although the round-trip delay from creating the patch to it being applied to CVS to getting mirroed to the git repo is pretty long. - I'd also be quite happy publishing a public tree for someone with CVS access to pull / cherry-pick from, and I assume any other 'heavy' git user would similarly be happy publishing their tree. My gut feeling is there should be a 'quick' migration to SVN for data and code, since CVS is just so dreadful - and the migration process is standard, and so are the tools (eg TortoiseSVN on windows is great). Deciding whether the primary code repos should then be git or svn is a more complex debate, but it feels like we'll always need both - git is too complex for some people, even if they're not on Windows. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How to contribute; Was: GIT
Hi Chris ! Christian Schmitt wrote: Martin Spott wrote: Guess why there are there so many private GIT repositories containing modified versions of FlightGear source trees !? Please think of it and keep up with the times. Ah, great to hear this from you, Martin. This does BTW not only apply to the FG source code, but also to the scenery and flightplans... ;-) Hey, the issue with FlightGear's source trees is that people _do_ submit their contributions, those guys with CVS write access are just too busy to review and commit. As far as I can tell (just guessing wildly), this also applies to AI flight plans. _But_, this is substantially different from the Scenery Model Repository where we explicitly ask/request people to submit their artwork - but some of them simply prefer to keep their stuff local instead of sharing it with the crowd Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
On Wed, Aug 20, 2008 at 3:52 PM, Martin Spott wrote: The FlightGear project has been notoriously behind about getting people's source code contributions into CVS - for years. We all know the story, it's been the same for years already, no need to repeat it here. So, in order not to loose the respective contributions over the time, such a GIT repo - be it mine or someone else's - makes the perfect tool that allows contributors to maintain their changes in a local branch while still easily keeping them in sync with the main source tree(s). Thus, it will be highly beneficial for the FlightGear project as a whole to support these developers by backing an official GIT repo instead of letting their enthusiasm fade out in disappointment Guess why there are there so many private GIT repositories containing modified versions of FlightGear source trees !? Please think of it and keep up with the times. Perhaps I misunderstand the scope and capabilities of git, but the way things settle out in my mind is that it would make sense to support an official GIT repository if (and only if) we decide to move the official master code repository to GIT. I don't see what an official GIT mirror provides over and above individual developer GIT mirrors. I do see that we have a variety of ad hock git repository clones that serve the needs and agendas of their individual developers/owners. Those seem to already do exactly what you propose. I suspect that one size does not fit all here ... (?) Is it possible for all the developers that run local repository mirrors and clones to git (hah, pun!) on the same page and move all their diverse stuff into a single repository? Would they all even want to? If the answer is a resounding yes, that would be good for me to know. And at the end of the day, no matter what source code version control system we use, and no matter what useful tools it provides for branching and merging, we still need a human in the loop to act as a sanity check to evaluate and approve changes that go into the master repository. (I understand this is a philosophical choice on my part. Another approach would be to let any and all changes from just about anyone to be committed to the master repository and let the review step happen when things break or crash or stop functioning optimally ... I just do not like that particular approach.) I agree that you are right that the development community has needs that should be better addressed, but my concern is to not act too swiftly and make choices that immediately benefit only a few vocal developers at the expense of other less vocal developers and perhaps serve the overall community less well than before. I'm not saying that your proposal falls into this category, just that I'd like to continue to move cautiously to make sure that it doesn't (especially in the case of GIT which still has questions surrounding it's ability to function well for non-unix developers.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Curtis Olson wrote: Perhaps I misunderstand the scope and capabilities of git, but the way things settle out in my mind is that it would make sense to support an official GIT repository if (and only if) we decide to move the official master code repository to GIT. I don't see what an official GIT mirror provides over and above individual developer GIT mirrors. I do see that we have a variety of ad hock git repository clones that serve the needs and agendas of their individual developers/owners. Those seem to already do exactly what you propose. I suspect that one size does not fit all here ... You're missing a small but quite interesting piece: Given the case that the local repositories would all base on and sync with the same 'primary' CVS-to-GIT gateway, it's getting far simpler for the respective developers/contributors to pull and merge the changes from each other, thus sharing their develpment for tests and cross-checks while still tracking CVS alias GIT _without_ waiting for the detour via official CVS. And at the end of the day, no matter what source code version control system we use, and no matter what useful tools it provides for branching and merging, we still need a human in the loop to act as a sanity check to evaluate and approve changes that go into the master repository. (I understand this is a philosophical choice on my part. My intention is not to challenge this your choice, I was just pointing out that the delay which is caused by the respective evaluation and approval process has been 'notoriously unpredictable' ;-) [...] Another approach would be to let any and all changes from just about anyone to be committed to the master repository [...] The point is that you're too often unable to afford the time that whould be required to tell wether the aspirant falls into the just about anyone-category (I guess you remember that such a case had been, in fact, initiating what has now grown up to the GIT mirror on our MapServer machine). If you're holding up this very choice, then you should also face the fact that this choice is not the appropriate solution for attracting really cluesome FlightGear developers. In this case you should at least agree to establishing some tools that allow people to mitigate the implications of the well-known bottlenecks. I agree that you are right that the development community has needs that should be better addressed, but my concern is to not act too swiftly and make choices that immediately benefit only a few vocal developers at the expense of other less vocal developers [...] I'm unable to follow your conclusions regarding CVS write access and vocal developers Good night, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT / SVN
For what it's worth, I have started playing around with cvs2svn, but only very recently. I've got nothing anyone can point at yet. Also by the way, I will be out of town for a work project thursday - sunday. Also by the way, my summer soccer team made the playoffs (we had to win our last 5 games of the season to get in, and then just barely.) But we beat the top seed in the first round 6-2 and moved on to the quarter-finals which we won in a shoot out after a 2-2 tie. This is the furthest any team I've played has made it into the playoffs. Now the semifinals and championship games are this weekend and I have to be out of town for a work project. Bummer ... ! But maybe they'll have a chance to win with out me on the field. :-) (I had to say that before someone else did.) :-) Curt. On Wed, Aug 20, 2008 at 4:27 PM, James Turner wrote: On 20 Aug 2008, at 21:14, Frederic Bouvier wrote: Migrating from CVS to SVN would already be a very good thing IMO Just to add some data to this - git works great on the Mac, or any Unix, but I believe it's never going to fly (if you'll pardon the expression) on Windows, due to technical limitations there - git works great with the current setup (read-only repo mirrored from CVS). For local development, if you can, and want to use it, it's pretty nice (I think Melchior has said the same thing) - I'd be quite happy using git's patch submission features to flood people's inboxes with patches :) Although the round-trip delay from creating the patch to it being applied to CVS to getting mirroed to the git repo is pretty long. - I'd also be quite happy publishing a public tree for someone with CVS access to pull / cherry-pick from, and I assume any other 'heavy' git user would similarly be happy publishing their tree. My gut feeling is there should be a 'quick' migration to SVN for data and code, since CVS is just so dreadful - and the migration process is standard, and so are the tools (eg TortoiseSVN on windows is great). Deciding whether the primary code repos should then be git or svn is a more complex debate, but it feels like we'll always need both - git is too complex for some people, even if they're not on Windows. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Crazy Altitude versus Agl
Hello Have you ever seen that, what is wrong? but that i was flying under the sea level. http://pagesperso-orange.fr/GRTux/CrazyAltAgl.jpg altitude-agl-ft = 20882967 altitude-ft = -11614 ??? I can reproduce it, i only have to fly under the sea/ground level. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] only a stupid question about FG and .fgfsrc
On mer 20 août 2008, Curtis Olson wrote: Hi Gerard, The ~/.fgfsrc file is hardwired into the program. Thanks , that, what i suspected, which explain i called my question = stupid. I was only looking for a way to have several configurations with the most simple command line. I have found an other way, it is to store several .fgfsrc v1, v2, v3,.. and to rename the one i want to .fgfsrc before to start FG It is the baby solution :) Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
