Re: [Flightgear-devel] segfault at LFPG
Hi Tim, On Wednesday 27 August 2008 15:37:19 Tim Moore wrote: This is great! We can't call osgDB:SharedStateManager::share from the database pager thread. I'll check in a fix soon. Great to hear that this stack trace was useful. :-) Cheers, Durk - 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] Service update
This was way too long in coming, but I have done a few service updates. 1. The master ftp.*gear.org server was having stability problems for some time now and would crash every couple days. I never got to the bottom of the problem ... I fully replaced the motherboard, cpu, and memory at one point. The kernel would periodically dump out dazed and confused messages to the console and eventually after a few days the machine would just lock up. This started after a kernel upgrade, so my best guess (not that it matters anymore) is that there was some driver bug or incompatibility with this older hardware and the newer linux kernel. I have completely removed that hardware and consolidated ftp and cvs services on a single machine ( baron.flightgear.org.) 2. I also noticed that www.simgear.org and www.terragear.org had gone off line when my department here redid some IP address space. I missed that, and only one person complained and only very recently, but those services should be back online now. 3. I suspect I need to spend some time reviving the anonymous rsync server, but I haven't had a chance to look into that yet. No one has complained though so I assume it is not very popular and thus a lower priority. 4. I plan to continue to tinker with setting up a test svn service with a snapshot conversion of flightgear's cvs repository. For now this will be for test and play only. I realize that selecting a revision control system is close to a religion for some folks (just like picking an OS, or a text editor, or a web browser, or a mail client, or a computer case color.) There has been many intelligent and useful comments posted to the list in support of various packages and I appreciate how much people care about this issue. But we have to support all our users and developers and we need to pick a system that all our developers can run smoothly on their favorite OS. 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] Service update
Curtis Olson wrote: 3. I suspect I need to spend some time reviving the anonymous rsync server, but I haven't had a chance to look into that yet. No one has complained though so I assume it is not very popular and thus a lower priority. From my point of view this is not the correct conclusion. Instead, I simply assume that it doesn't make any difference wether I complain or not. So I remain looking at the regular error messages from the mirror jobs and waiting until the machine is back in service :-) 4. [... Source Code Management ...] There has been many intelligent and useful comments posted to the list in support of various packages and I appreciate how much people care about this issue. But we have to support all our users and developers and we need to pick a system that all our developers can run smoothly on their favorite OS. Curt, apparently you insist on getting things wrong. Yes, I do prefer using GIT and I agree with _everything_ that Melchior has been adding to this discussion (including him taking back the paragraph about disk usage). But this is _not_ the point !! In fact we didn't have a _single_ !! person stating that MSysGit does not work. There was a sole person claiming that he didn't get it to work, but was uncertain wether he knew how to use it properly. Period. The remaining statements concerning GIT on Windows have been nothing but guesses and assumptions (better known as FUD) and I expect an experienced project coordinator being able to tell the difference. _This_ is the point which sheds an ugly light onto the whole topic. Adding to that, you have still failed to deliver a reason (aside from spreading FUD) why the project should _not_ have _one_ official GIT mirror of the existing CVS (or maybe SVN) repositories - no matter who's going to run it in the end. In the end, you're wasting developer resources by thwarting the efficiency of not all but at least some of the involved people and you don't have a single point. This is really getting somewhat problematic. 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] Service update
Curtis Olson wrote: When I researched the topic, I saw over and over again that the biggest knock against git is that it does not have good support for windows. That has been repeated on this list by more than just me. Yes, GIT has had pretty bad Windows support for a long time. Yes, I didn't check it (simply because I don't have a Windows machine). On the other hand, we both know that bad news of this doesn't work on Windows-type have a very long half-life, so unless someone who's reasonably skilled wrt. using SCM systems does a test, there's simply nothing to put your bet on for the current state. Until someone from our project actually tries this on a windows system (possibly you could even test it?) then we are all apparently spreading FUD including you. No, I'm not spreading FUD, at least I don't claim that MSysGit works. Instead, I do claim that having _one_ official GIT mirror for those who'd like to use it, is an overall benefit for the project. Please don't put words into my mouth which I have not said. [...] I'm sorry you are so frustrated by this issue, but I would appreciate if you keep your comments fair and professional. :-( I repeat: You have not shown to have a point against introducing an official (or 'authoritative') GIT mirror. Please explain to me what you consider to be unprofessional about this claim ? 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] Service update
Curtis Olson wrote: On Thu, Aug 28, 2008 at 10:40 AM, Martin Spott [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: From my point of view this is not the correct conclusion. Instead, I simply assume that it doesn't make any difference wether I complain or not. So I remain looking at the regular error messages from the mirror jobs and waiting until the machine is back in service :-) I appreciate your perspective. :-) Curt, apparently you insist on getting things wrong. Yes, I do prefer using GIT and I agree with _everything_ that Melchior has been adding to this discussion (including him taking back the paragraph about disk usage). But this is _not_ the point !! In fact we didn't have a _single_ !! person stating that MSysGit does not work. There was a sole person claiming that he didn't get it to work, but was uncertain wether he knew how to use it properly. Period. The remaining statements concerning GIT on Windows have been nothing but guesses and assumptions (better known as FUD) and I expect an experienced project coordinator being able to tell the difference. When I researched the topic, I saw over and over again that the biggest knock against git is that it does not have good support for windows. That has been repeated on this list by more than just me. I have not tested it personally on windows, but it appears that neither have you. Just because I saw something on the web, doesn't mean it's true, but there does seem to be a general web consensus here, and you have given no information that can be used to disprove this web consensus. _This_ is the point which sheds an ugly light onto the whole topic. Adding to that, you have still failed to deliver a reason (aside from spreading FUD) why the project should _not_ have _one_ official GIT mirror of the existing CVS (or maybe SVN) repositories - no matter who's going to run it in the end. In the end, you're wasting developer resources by thwarting the efficiency of not all but at least some of the involved people and you don't have a single point. This is really getting somewhat problematic. Until someone from our project actually tries this on a windows system (possibly you could even test it?) then we are all apparently spreading FUD including you. If you have not tested git on windows and have not found a nice front end, then you cannot say for sure that it works and works well (which is important in the face of all the web based reports that it doesn't work or doesn't work well or easily.) If our windows developers have also not tested it, then they cannot say for sure that it does or does not work. In the mean time, we know that SVN does work pretty good. I'm sorry you are so frustrated by this issue, but I would appreciate if you keep your comments fair and professional. :-( Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ - 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 I'll give msysgit a try. Are there known issues with it that I should be looking for? Also, timoore indicated on IRC that msysgit does work, but that TortoiseCVS/SVN users might find things that are surprising or less convenient. jentron did some testing and noted that, by default, msysgit converts unix2dos/dos2unix automatically. That looks like a dangerous default setting to me. I hesitate to trust it to not screw something up. Maybe the biggest issue is that git's UI isn't Windowsy enough? Do we have any windows TortoiseCVS users/contributors who wouldn't be able to cope with a command line or otherwise foreign UI? - 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] Service update
On Thu, Aug 28, 2008 at 11:38 AM, Martin Spott [EMAIL PROTECTED]wrote: I repeat: You have not shown to have a point against introducing an official (or 'authoritative') GIT mirror. Please explain to me what you consider to be unprofessional about this claim ? I have never attempted to make a point against introducing an authoritative GIT mirror. I have only suggested that we do one thing at a time because I am a terrible multi-tasker and my non-work time has limits. I would like to take a serious look at migrating from CVS to SVN first. Then I am willing to take a serious look at GIT. I have suggested that the process of taking a serious look at GIT does involve taking a serious look at all the platforms it supports because there are reports of potential problems. That is a hurdle we need to clear. We have established that none of us know if it's a small hurdle, a big hurdle, or no hurdle at all, but that will be part of the process of taking a serious look at GIT. Again, I apologize if you do not like my road map or the number of miles I am able to travel in a day. 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
* Frederic Bouvier -- 8/27/2008 12:26 PM: It is just that nobody explained me the benefits of using GIT over a well known system such as CVS and SVN. I am aware of the serious lacks of CVS, that's why I am advocating switching to SVN. Half of the fgfs developers are already using GIT for sg/fg. Not in anticipation of a possible switch, but because GIT offers a lot that neither CVS nor SVN do. So the well known is rather misleading. How many are already using SVN for fgfs development because it's so great? My guess is: exactly zero. :-P GIT is well supported on Unix/Linux/Mac/Windows. Windows is supported through msysgit (http://code.google.com/p/msysgit/). This isn't a hostile fork. Merging it with stock git is planned. A tortoise-like click-and-point interface for Windows users is being worked on. Windows using FlightGear developers are certainly smart enough to use the command line for a while until it's finished. GIT isn't difficult. Checking out a GIT repository, making a local branch, committing there, and finally submitting (pushing) is easy. Additional familiar commands can easily get added via GIT aliases. But GIT does offer a lot more than CVS and SVN put together, and some of those capabilities can be harder to grok at first ... until you are familiar with them. But that doesn't make it harder than SVN, because SVN doesn't offer those features in the first place. Why I prefer GIT: Mainly because it supports local feature/topic branches. I do no longer want to work without that. m. - 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] improving VOR indication (patch for navradio.cxx/hxx)
Here is a little patch that changes the behaviour of the VOR CDI and OFF-flag
for indicators like the HSI when getting outside the range of the VOR
station.
Currently, when flying at a distance between the effective_range and twice the
effective_range of a VOR station, the in-range property is computed based on
a random value, causing the OFF Flag and the CDI bar to perform an ugly
jitter.
The attached patch introduces a new property signal-quality-norm which is
computed based on the distance to the station and the range. It is 1.0 when
the distance is less than the range and decreases by 1/x^2 for distances
greater than the range leading to a signal-quality-norm of 0.25 for distances
two times the range, 0.125 for three times the range and so on.
The in-range flag is tied to a signal-quality-norm greater than 0.2 (fixed
squelch).
The CDI and GS needle deflection is multiplied with the signal-quality-norm.
The benefit is:
- Ability to animate the OFF-Flag with a smooth transition.
- CDI and GS needle deflection shows correct values when in range
(signal-quality-norm=1.0) and show some wrong indication when the range is
exceeded
- CDI and GS needle start to move, even when the OFF flag is visible
- No more jitter for flag and needles
See the new SenecaII ki525a hsi as an example at
http://www.t3r.de/fg/navpatch.jpg
The numbers on the image are:
(1) the new property signal-quality-norm
(2) distance exceeds the effective-range by 30%
(3) NAV flag has a rotation animation bound to signal-quality-norm and is
partially visible
(4) CDI is partially deflected even with NAV flag shown
This implementation better matches reality - at least, how I observed it ;-)
The attached patch is agains current HEAD.
I hope the patch gets into CVS with the help of some kind commiter.
Greetings, Torsten
Index: navradio.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/navradio.cxx,v
retrieving revision 1.29
diff -u -p -r1.29 navradio.cxx
--- navradio.cxx 3 Aug 2008 14:34:42 - 1.29
+++ navradio.cxx 28 Aug 2008 18:28:08 -
@@ -35,6 +35,7 @@
#include simgear/structure/exception.hxx
#include Navaids/navlist.hxx
+#include Main/util.hxx
#include navradio.hxx
using std::string;
@@ -68,6 +69,7 @@ FGNavRadio::FGNavRadio(SGPropertyNode *n
to_flag_node(NULL),
from_flag_node(NULL),
inrange_node(NULL),
+signal_quality_norm_node(NULL),
cdi_deflection_node(NULL),
cdi_xtrack_error_node(NULL),
cdi_xtrack_hdg_err_node(NULL),
@@ -176,6 +178,7 @@ FGNavRadio::init ()
to_flag_node = node-getChild(to-flag, 0, true);
from_flag_node = node-getChild(from-flag, 0, true);
inrange_node = node-getChild(in-range, 0, true);
+signal_quality_norm_node = node-getChild(signal-quality-norm, 0, true);
cdi_deflection_node = node-getChild(heading-needle-deflection, 0, true);
cdi_xtrack_error_node = node-getChild(crosstrack-error-m, 0, true);
cdi_xtrack_hdg_err_node
@@ -314,6 +317,8 @@ FGNavRadio::update(double dt)
bool has_gs = has_gs_node-getBoolValue();
bool is_loc = loc_node-getBoolValue();
double loc_dist = loc_dist_node-getDoubleValue();
+double effective_range_m;
+double signal_quality_norm = signal_quality_norm_node-getDoubleValue();
double az1, az2, s;
@@ -418,18 +423,32 @@ FGNavRadio::update(double dt)
effective_range
= adjustNavRange( nav_elev, pos.getElevationM(), range );
}
+
+effective_range_m = effective_range * SG_NM_TO_METER;
+
// cout nav range = effective_range
//( range ) endl;
- if ( loc_dist effective_range * SG_NM_TO_METER ) {
- inrange = true;
- } else if ( loc_dist 2 * effective_range * SG_NM_TO_METER ) {
- inrange = sg_random() ( 2 * effective_range * SG_NM_TO_METER
- - loc_dist )
- / (effective_range * SG_NM_TO_METER);
- } else {
- inrange = false;
- }
+//
+// compute signal quality
+// 100% within effective_range
+// decreases 1/x^2 further out
+//
+{
+double last_signal_quality_norm = signal_quality_norm;
+
+ if ( loc_dist effective_range_m ) {
+ signal_quality_norm = 1.0;
+} else {
+ double range_exceed_norm = loc_dist/effective_range_m;
+ signal_quality_norm = 1/(range_exceed_norm*range_exceed_norm);
+}
+
+signal_quality_norm = fgGetLowPass( last_signal_quality_norm,
+ signal_quality_norm, dt );
+}
+signal_quality_norm_node-setDoubleValue( signal_quality_norm );
+inrange = signal_quality_norm 0.2;
inrange_node-setBoolValue( inrange );
if ( !is_loc ) {
@@ -507,6 +526,7 @@
[Flightgear-devel] Re;Test
Hi, just checking if I got rid of the postmaster error. I keep getting my e-mails bounced back but no problem with receiving other's e-mails. I keep unsubscribing then subscribing, changing parameters etc. see what happens. I hope I can post something here I need your help people!- 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] improving VOR indication (patch for navradio.cxx/hxx)
Hi Torsten, Does this patch work with any aircraft and nav radio, or do the individual aircraft need to be updated to match. I did a quick test in the default c172 flying from SJC to SFO, but the SFO 28R ILS seemed to have rock solid needle response even on the ground at SJC (26+ miles away) and the TO flag is showing. This will be a nice addition, but I just want to make sure the default behavior scales fairly close to reality. Thanks, Curt. On Thu, Aug 28, 2008 at 2:04 PM, Torsten Dreyer wrote: Here is a little patch that changes the behaviour of the VOR CDI and OFF-flag for indicators like the HSI when getting outside the range of the VOR station. Currently, when flying at a distance between the effective_range and twice the effective_range of a VOR station, the in-range property is computed based on a random value, causing the OFF Flag and the CDI bar to perform an ugly jitter. The attached patch introduces a new property signal-quality-norm which is computed based on the distance to the station and the range. It is 1.0 when the distance is less than the range and decreases by 1/x^2 for distances greater than the range leading to a signal-quality-norm of 0.25 for distances two times the range, 0.125 for three times the range and so on. The in-range flag is tied to a signal-quality-norm greater than 0.2 (fixed squelch). The CDI and GS needle deflection is multiplied with the signal-quality-norm. The benefit is: - Ability to animate the OFF-Flag with a smooth transition. - CDI and GS needle deflection shows correct values when in range (signal-quality-norm=1.0) and show some wrong indication when the range is exceeded - CDI and GS needle start to move, even when the OFF flag is visible - No more jitter for flag and needles See the new SenecaII ki525a hsi as an example at http://www.t3r.de/fg/navpatch.jpg The numbers on the image are: (1) the new property signal-quality-norm (2) distance exceeds the effective-range by 30% (3) NAV flag has a rotation animation bound to signal-quality-norm and is partially visible (4) CDI is partially deflected even with NAV flag shown This implementation better matches reality - at least, how I observed it ;-) The attached patch is agains current HEAD. I hope the patch gets into CVS with the help of some kind commiter. Greetings, Torsten - 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] improving VOR indication (patch for navradio.cxx/hxx)
On 28 Aug 2008, at 20:51, Curtis Olson wrote: Does this patch work with any aircraft and nav radio, or do the individual aircraft need to be updated to match. I did a quick test in the default c172 flying from SJC to SFO, but the SFO 28R ILS seemed to have rock solid needle response even on the ground at SJC (26+ miles away) and the TO flag is showing. This will be a nice addition, but I just want to make sure the default behavior scales fairly close to reality. I suspect there's lots of debate over decay functions - Torsten's computation is cheap and seems reasonable, but I'll let people with more aeronautical experience comment in detail. However, the use of random() in the existing code is much worse - ultimately some semi-random model would be nice, but that would random over much, much longer timer periods (hours or days) - the current code causes the dreaded 'strobing' of reception (and in the dme code as well), as the random() call is evaluated every update, i.e frame. Hence random seems plain wrong to me (despite being motivated by a worthwhile goal) so anything that replaces it with a stable decay function gets my vote. 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
Re: [Flightgear-devel] improving VOR indication (patch for navradio.cxx/hxx)
On Thu, Aug 28, 2008 at 3:03 PM, James Turner wrote: I suspect there's lots of debate over decay functions - Torsten's computation is cheap and seems reasonable, but I'll let people with more aeronautical experience comment in detail. However, the use of random() in the existing code is much worse - ultimately some semi-random model would be nice, but that would random over much, much longer timer periods (hours or days) - the current code causes the dreaded 'strobing' of reception (and in the dme code as well), as the random() call is evaluated every update, i.e frame. Hence random seems plain wrong to me (despite being motivated by a worthwhile goal) so anything that replaces it with a stable decay function gets my vote. Ok, I have committed this patch, we can always adjust the service volume later. Thanks, this is one thing that has been visually annoying for quite some time. 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
Melchior FRANZ wrote: * Melchior FRANZ -- 8/26/2008 3:03 PM: But it would make me a bit nervous if an aircraft developer commits several pointless updates of 5MB sound files. GIT can't compress that. We'd collect the whole pile on our disks. How much would disk space requirements grow each year? Bah, I just saw a rather cheap 1TB disk offered in the ads of a shop that focuses on books, music CDs and paper stuff. I guess that a few MB more aren't really an issue nowadays. Hereby I withdraw the above consideration. So what's left as an argument against switching to GIT right away? That's after some more discussions and tests, of course. :-) And by the way: an SVN checkout keeps two copies of every single file. And for most files that copy takes about as much disk space as the *whole* history of that file in GIT, which includes all file revisions! (IIRC) I just tested the fg GIT server and checked out fgdata, which is quite a piece of stuff. It took some time, but that's normal for the first checkout and not different to CVS. The interesting thing is running du -c after the checkout on both different dirs: CVS: 1696167 total git: 1043121 total Which clearly shows how efficient git works even with binary files and considering that this copy contains all the changes, as Melchior already stated. - 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] AI Carrier with Aircraft, and the last JSBSim version
With Catapult it is less a problem, with answering time delay, i mean it should work. Catapults features need only to know the starting position with a more or less value precision: a carrier with 20 km speed does 5.6 meter per second = 0.50 1/10 sec = 0.05 1/100 sec The heading won't be a difficulty, the heading of the carrier is not quickly moving. I haven't done much with FG or JSBSim lately, but thought I'd add my $0.02 worth, since I'm working on this stuff on a 'real' simulator. Not all carriers shoot off at the carrier's heading. Some US carriers (sorry, I can't name names) are left of carrier heading, up to 8 degrees. Some secondary cats (cats 3 and 4) are off even more. (I think they even show some of that in Top Gun). Plus, the force applied is in carrier axes (with the aforementioned offset), not in aircraft body axes. The force must be translated into body axis so that it tracks down the cat track. That way, if you are lined up poorly on the cat, it straightens you out. The carrier is most likely not going to be changing heading or speed during a launch, but it should be accounted for. With a high-seas condition, the boat is rock, roll, and heave a lot. Traps are REALLY difficult when the seas are rough. They probably have to time a shot off a cat to coincide with an up motion, so that you don't get shot into a wave. Bill - 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
