[Flightgear-devel] Tried to initialize a non-existent engine!
Hello devel members, That issue with jsbsim aircraft is back. It comes up when at reset , for instance c172p.and we get a crash with that message: Tried to initialize a non-existent engine! I thought it was solved. -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tried to initialize a non-existent engine!
On 25 Jan 2011, at 09:46, henri orange wrote: It comes up when at reset , for instance c172p.and we get a crash with that message: Tried to initialize a non-existent engine! It was solved, but my was over-written when Erik updated JSBSim (because I didn't remember to submit it to JSBSim). But last night I re-appllied the fix to Git, so it should work again - I spent some time with the C172 resetting and repositioning and everything worked fine. (I didn't try any other aircraft, due to lack of time) James -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tried to initialize a non-existent engine!
Thanks, I did not noticed the last nigh update. Will try out it. 2011/1/25 James Turner zakal...@mac.com On 25 Jan 2011, at 09:46, henri orange wrote: It comes up when at reset , for instance c172p.and we get a crash with that message: Tried to initialize a non-existent engine! It was solved, but my was over-written when Erik updated JSBSim (because I didn't remember to submit it to JSBSim). But last night I re-appllied the fix to Git, so it should work again - I spent some time with the C172 resetting and repositioning and everything worked fine. (I didn't try any other aircraft, due to lack of time) James -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tried to initialize a non-existent engine!
It comes up when at reset , for instance c172p.and we get a crash with that message: Tried to initialize a non-existent engine! It was solved, but my was over-written when Erik updated JSBSim (because I didn't remember to submit it to JSBSim). But last night I re-appllied the fix to Git, so it should work again - I spent some time with the C172 resetting and repositioning and everything worked fine. (I didn't try any other aircraft, due to lack of time) James What patch? Jon -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tried to initialize a non-existent engine!
On Tue, 25 Jan 2011, Jon S. Berndt wrote: It was solved, but my was over-written when Erik updated JSBSim (because I didn't remember to submit it to JSBSim). But last night I re-appllied the fix to Git, so it should work again - I spent some time with the C172 resetting and repositioning and everything worked fine. (I didn't try any other aircraft, due to lack of time) James What patch? This one, I think: http://gitorious.org/fg/flightgear/commit/c2458a17bf0a8a95caf1a43e37482162ae0100bc Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tried to initialize a non-existent engine!
On 25 Jan 2011, at 10:28, Jon S. Berndt wrote: What patch? FIx for #204, the issue Henri is describing: http://gitorious.org/fg/flightgear/commit/c2458a17bf0a8a95caf1a43e37482162ae0100bc Partial band-aid for #222, the reset-NaN crash: (ugly, but not in the main JSBSim code) http://gitorious.org/fg/flightgear/commit/4b494b1d0842bc53d7295f74c44cf4f7a3185446 Andreas' other fixes for #222: http://gitorious.org/fg/flightgear/commit/4f364af6d178d947eae1a5a751e3a9542b270069 Regards, James -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaNs when resetting JSBSim
Hi, In Ubuntu 8.04 LTS, just did a git pull (SG/FG/DATA), and make, etc, and on running the default a/c, as someone else also reported, get the console output :- creating 3D noise texture... DONE Trim Results: Altitude AGL:4.4 wdot: 1.54e-03 Tolerance: 1e-03 Failed Pitch Angle: 0.047 qdot: -2.47e-04 Tolerance: 1e-04 Failed Trim Statistics: Total Iterations: 61 Sub-iterations: wdot: 212 average: 3.4754 successful: 10 stability: 2.4898 qdot: 240 average: 3.9344 successful: 6 stability: 2.9703 Run Count: 1733 Initializing Nasal Electrical System power up Then, on doing a reset, get :- passed invalid index (0) to FGRouteMgr::jumpToIndex Trim Failed Trim Results: Angle of Attack:5.5 wdot: 4.25e+00 Tolerance: 1e-03 Failed Throttle:0.5 udot: -4.79e-01 Tolerance: 1e-03 Failed Pitch Trim: 0 qdot: 1.27e+00 Tolerance: 1e-04 Failed The climb rate cannot be higher than the true speed. and that is repeated on each reset... this was just sitting on my 'favorite' runway 33, at YGIL ;=)) I have been getting, and ignoring this for a while, since about the last JSBsim merge, I think... Is this a problem? Certainly do not like seeing 'Failed', but it seems fg runs ok, and the aircraft seems to fly ;=)) so maybe not a problem... Regards, Geoff. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Carrier Altitude
In attempting to place an item on the ocean surface, I came to realize that it's not the Nimitz that is hovering above MSL, it's that the ocean surface is about 7 meters below MSL. I was going to suggest simply dropping the carriers to match, but then looking around I discovered that it was not constant, as the ocean surface is different from front to back of the Nimitz. So the ocean surface is not flat. Where it meets the terrain north of the Golden Gate Bridge the water is at zero MSL. It then slopes down as it you head out to sea, to -8.72 meters below sea level, before starting to come back up again. I did not continue out to see if it continues to rise and fall, or if it's purely a dip in this area. This is different from the ocean surface being curved to match the earth, as it actually has a dip, at least in this spot. See screenshots - Terrain intersection north of Golden Gate [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at102804PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at102804PM.png[/IMG][/URL] At the Nimtiz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at100253PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at100253PM.png[/IMG][/URL] West of Nimitz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at103120PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at103120PM.png[/IMG][/URL] Anyone know why? Or, more importantly, can we set the carriers at an altitude appropriate for their default location, so they are no longer hovering? I'd prefer to do it globally so everyone was at the same altitude. Thanks, Peter-- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Quick explanation: the world is curved (oblate spheroid) so if in order to have an ocean that measures zero MSL at all points, it would have to be curved. To do this perfectly requires a *lot* of polygons. We have been using large polygons for the ocean so that leads to some errors depending on where you are within the polygon. Near the verticies will be pretty accurate, near the middle could be off by a few meters. Regards, Curt. On Tue, Jan 25, 2011 at 11:57 AM, Peter Brown smoothwater...@adelphia.netwrote: In attempting to place an item on the ocean surface, I came to realize that it's not the Nimitz that is hovering above MSL, it's that the ocean surface is about 7 meters *below* MSL. I was going to suggest simply dropping the carriers to match, but then looking around I discovered that it was not constant, as the ocean surface is different from front to back of the Nimitz. So the ocean surface is not flat. Where it meets the terrain north of the Golden Gate Bridge the water is at zero MSL. It then slopes down as it you head out to sea, to -8.72 meters below sea level, before starting to come back up again. I did not continue out to see if it continues to rise and fall, or if it's purely a dip in this area. This is different from the ocean surface being curved to match the earth, as it actually has a dip, at least in this spot. See screenshots - Terrain intersection north of Golden Gate [URL= http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at102804PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at102804PM.png[/IMG][/URL ] At the Nimtiz [URL= http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at100253PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at100253PM.png[/IMG][/URL ] West of Nimitz [URL= http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at103120PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at103120PM.png[/IMG][/URL ] Anyone know why? Or, more importantly, can we set the carriers at an altitude appropriate for their default location, so they are no longer hovering? I'd prefer to do it globally so everyone was at the same altitude. Thanks, Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On 24.01.2011 22:49, James Turner wrote: Perhaps another approach would be to do out-of-source builds. I think automake/conf should support that, although it's been a while since I've tried it. Cmake is very good at out-of-source builds :) Hmm. The out-of-source builds alone don't really help with switching branches. Changing branches back and forth still results in all differing sources getting new timestamps. So the next make triggers a rebuild of all affected sources/objects anyway. make isn't smart enough to notice that the older object files were generated from (older) sources, which had identical content to the current (newer) sources. So it's all the same if you maintained one or two sets of objects. You'll also need to keep git from touching any _sources_, so maintain two sets of matching sources and their objects. Using two completely separate repos helps - or the magic feature to create two separate source checkouts from one repository, which James mentioned. Could some git guru (git-goroo? ;) ) enlighten me, on how I can create two checkouts from one repo? That would actually be very useful - especially now that fgdata is branched. I don't want to pull another fgdata repo... and I don't feel brave enough to switch fgdata branches, since its release branch is already stripped (= switching affects thousands of files...). cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Tides? Ocean with LOD? On Tue, Jan 25, 2011 at 10:13 AM, Curtis Olson curtol...@gmail.com wrote: Quick explanation: the world is curved (oblate spheroid) so if in order to have an ocean that measures zero MSL at all points, it would have to be curved. To do this perfectly requires a *lot* of polygons. We have been using large polygons for the ocean so that leads to some errors depending on where you are within the polygon. Near the verticies will be pretty accurate, near the middle could be off by a few meters. Regards, Curt. On Tue, Jan 25, 2011 at 11:57 AM, Peter Brown smoothwater...@adelphia.net wrote: In attempting to place an item on the ocean surface, I came to realize that it's not the Nimitz that is hovering above MSL, it's that the ocean surface is about 7 meters below MSL. I was going to suggest simply dropping the carriers to match, but then looking around I discovered that it was not constant, as the ocean surface is different from front to back of the Nimitz. So the ocean surface is not flat. Where it meets the terrain north of the Golden Gate Bridge the water is at zero MSL. It then slopes down as it you head out to sea, to -8.72 meters below sea level, before starting to come back up again. I did not continue out to see if it continues to rise and fall, or if it's purely a dip in this area. This is different from the ocean surface being curved to match the earth, as it actually has a dip, at least in this spot. See screenshots - Terrain intersection north of Golden Gate [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at102804PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at102804PM.png[/IMG][/URL] At the Nimtiz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at100253PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at100253PM.png[/IMG][/URL] West of Nimitz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at103120PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at103120PM.png[/IMG][/URL] Anyone know why? Or, more importantly, can we set the carriers at an altitude appropriate for their default location, so they are no longer hovering? I'd prefer to do it globally so everyone was at the same altitude. Thanks, Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 1:13 PM, Curtis Olson wrote: Quick explanation: the world is curved (oblate spheroid) so if in order to have an ocean that measures zero MSL at all points, it would have to be curved. To do this perfectly requires a *lot* of polygons. We have been using large polygons for the ocean so that leads to some errors depending on where you are within the polygon. Near the verticies will be pretty accurate, near the middle could be off by a few meters. Regards, Curt. Curt, Does it not seem a bit odd to have a divot like this? I expected if flat then the polys would only go down until the mid-span of the ocean surface and then it would rise back up to meet the terrain again. Either way, can I suggest we lower the carriers to a closer approximation of altitude, at least at their default AI locations? Thanks, Peter On Tue, Jan 25, 2011 at 11:57 AM, Peter Brown smoothwater...@adelphia.net wrote: In attempting to place an item on the ocean surface, I came to realize that it's not the Nimitz that is hovering above MSL, it's that the ocean surface is about 7 meters below MSL. I was going to suggest simply dropping the carriers to match, but then looking around I discovered that it was not constant, as the ocean surface is different from front to back of the Nimitz. So the ocean surface is not flat. Where it meets the terrain north of the Golden Gate Bridge the water is at zero MSL. It then slopes down as it you head out to sea, to -8.72 meters below sea level, before starting to come back up again. I did not continue out to see if it continues to rise and fall, or if it's purely a dip in this area. This is different from the ocean surface being curved to match the earth, as it actually has a dip, at least in this spot. See screenshots - Terrain intersection north of Golden Gate [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at102804PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at102804PM.png[/IMG][/URL] At the Nimtiz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at100253PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at100253PM.png[/IMG][/URL] West of Nimitz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2011-01-24at103120PM.png][IMG]http://i512.photobucket.com/albums/t325/barefootr/th_Screenshot2011-01-24at103120PM.png[/IMG][/URL] Anyone know why? Or, more importantly, can we set the carriers at an altitude appropriate for their default location, so they are no longer hovering? I'd prefer to do it globally so everyone was at the same altitude. Thanks, Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Tue, Jan 25, 2011 at 1:00 PM, Peter Brown smoothwater...@adelphia.netwrote: Does it not seem a bit odd to have a divot like this? Well odd things result occasionally when we try to represent the physical world with triangles ... we could discuss how many triangles and where to concentrate them ... that's always a fair topic. We could represent the world perfectly if you gave me an infinite number of triangles, just like we could solve all the worlds problems if you gave me an infinite amount of money (or probably not in both cases.) :-) I expected if flat then the polys would only go down until the mid-span of the ocean surface and then it would rise back up to meet the terrain again. Isn't that what is happening? Either way, can I suggest we lower the carriers to a closer approximation of altitude, at least at their default AI locations? How about having carriers do a terrain height check and follow the polygon curvature of the FlightGear world? Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On 01/25/2011 12:14 PM, Curtis Olson wrote: How about having carriers do a terrain height check and follow the polygon curvature of the FlightGear world? Call it a feature. The real ocean has swells. They make carrier flight operations considerably more interesting. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Tue, 25 Jan 2011, ThorstenB wrote: You'll also need to keep git from touching any _sources_, so maintain two sets of matching sources and their objects. Using two completely separate repos helps - or the magic feature to create two separate source checkouts from one repository, which James mentioned. Could some git guru (git-goroo? ;) ) enlighten me, on how I can create two checkouts from one repo? That would actually be very useful - especially now that fgdata is branched. I don't want to pull another fgdata repo... and I don't feel brave enough to switch fgdata branches, since its release branch is already stripped (= switching affects thousands of files...). I suspect the option --local to git clone might be useful. I have not tried myself, though. anders@sleipner:~$ git clone -h usage: git clone [options] [--] repo [dir] ... -l, --local to clone from a local repository ... anders@sleipner:~$ git clone --help ... OPTIONS --local, -l When the repository to clone from is on a local machine, this flag bypasses the normal git aware transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. This is now the default when the source repository is specified with /path/to/repo syntax, so it essentially is a no-op option. To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository), but still avoid the usual git aware transport mechanism, --no-hardlinks can be used. ... Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 2:20 PM, John Denker wrote: On 01/25/2011 12:14 PM, Curtis Olson wrote: How about having carriers do a terrain height check and follow the polygon curvature of the FlightGear world? Call it a feature. The real ocean has swells. They make carrier flight operations considerably more interesting. Sounds great. How does it get implemented? Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On 25 Jan 2011, at 19:22, Anders Gidenstam wrote: I suspect the option --local to git clone might be useful. I have not tried myself, though. The thing I was thinking of is: git-new-workdir Which essentially symlinks the key pieces of .git between two different dirs. Documentation seems to be a bit lacking, though. James -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 2:14 PM, Curtis Olson wrote: On Tue, Jan 25, 2011 at 1:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I expected if flat then the polys would only go down until the mid-span of the ocean surface and then it would rise back up to meet the terrain again. Isn't that what is happening? I don't believe so, as it's no where near mid-span. If the distance was shorter I'll call it a super-long negative swell(swale?), but the distance between the points shown in the images is longer than that. I'll do some more research in different locations. That said, I was looking for information about it so that the carrier could be at actual sea level, or ocean surface rather than hovering above it. If the height-adjust is possible, that'd be a great solution if it kept in sync across MP. Thanks, Peter-- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Carriers are set to 0 ft altitude. However, we were aware of the discrepancy caused by a flat sea on a roundish world. The wake of the Nimitz is angled down to form a skirt that conceals the error from most, if not all, normal viewing angles. We deliberately do not seek the local sea level as this would both be expensive in frame rate terms, and the vertical movement would tend to unlatch aircraft on deck from the carrier. Vivian -Original Message- From: Curtis Olson [mailto:curtol...@gmail.com] Sent: 25 January 2011 18:13 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Carrier Altitude Quick explanation: the world is curved (oblate spheroid) so if in order to have an ocean that measures zero MSL at all points, it would have to be curved. To do this perfectly requires a *lot* of polygons. We have been using large polygons for the ocean so that leads to some errors depending on where you are within the polygon. Near the verticies will be pretty accurate, near the middle could be off by a few meters. Regards, Curt. On Tue, Jan 25, 2011 at 11:57 AM, Peter Brown smoothwater...@adelphia.net wrote: In attempting to place an item on the ocean surface, I came to realize that it's not the Nimitz that is hovering above MSL, it's that the ocean surface is about 7 meters below MSL. I was going to suggest simply dropping the carriers to match, but then looking around I discovered that it was not constant, as the ocean surface is different from front to back of the Nimitz. So the ocean surface is not flat. Where it meets the terrain north of the Golden Gate Bridge the water is at zero MSL. It then slopes down as it you head out to sea, to -8.72 meters below sea level, before starting to come back up again. I did not continue out to see if it continues to rise and fall, or if it's purely a dip in this area. This is different from the ocean surface being curved to match the earth, as it actually has a dip, at least in this spot. See screenshots - Terrain intersection north of Golden Gate [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=view http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Scre enshot2011-01-24at102804PM.png%5d%5bIMG%5dhttp://i512.photobucket.com/albums /t325/barefootr/th_Screenshot2011-01-24at102804PM.png%5b/IMG%5d%5b/URL current=Screenshot2011-01-24at102804PM.png][IMG]http://i512.photobucket.com /albums/t325/barefootr/th_Screenshot2011-01-24at102804PM.png[/IMG][/URL] At the Nimtiz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=view http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Scre enshot2011-01-24at100253PM.png%5d%5bIMG%5dhttp://i512.photobucket.com/albums /t325/barefootr/th_Screenshot2011-01-24at100253PM.png%5b/IMG%5d%5b/URL current=Screenshot2011-01-24at100253PM.png][IMG]http://i512.photobucket.com /albums/t325/barefootr/th_Screenshot2011-01-24at100253PM.png[/IMG][/URL] West of Nimitz [URL=http://s512.photobucket.com/albums/t325/barefootr/?action=view http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Scre enshot2011-01-24at103120PM.png%5d%5bIMG%5dhttp://i512.photobucket.com/albums /t325/barefootr/th_Screenshot2011-01-24at103120PM.png%5b/IMG%5d%5b/URL current=Screenshot2011-01-24at103120PM.png][IMG]http://i512.photobucket.com /albums/t325/barefootr/th_Screenshot2011-01-24at103120PM.png[/IMG][/URL] Anyone know why? Or, more importantly, can we set the carriers at an altitude appropriate for their default location, so they are no longer hovering? I'd prefer to do it globally so everyone was at the same altitude. Thanks, Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ http://www.flightgear.org/blogs/category/personal/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] NaNs when resetting JSBSim
Am 25.01.2011 12:59, schrieb Geoff McLane: [... JSBSim trim failure report] Is this a problem? Certainly do not like seeing 'Failed', but it seems fg runs ok, and the aircraft seems to fly ;=)) so maybe not a problem... It is probably not a problem, except for adding complexity when hunting NaNs... What happens is that the JSBSim trim routine is bound as a listener to the property /fdm/jsbsim/simulation/do_simple_trim. When a reset is triggered, the whole property tree is copied to a new instance. This triggers the listener. However, it runs on the old instance of JSBSim, so the results will be dropped anyway as a new instance will be created. I suggested a fix for that on the JSBSim-devel list, but that breaks backwards compatibility, so we'll have to find something else. The best way is probably -- as Jon proposed -- to reinitialize the existing instance without copying the property tree. But this might be quite a large task. Is the do_simple_trim property used in any FlightGear aircraft? I didn't find a reference to it in the fgdata aircraft dir, so it could be possible to completely untie this in JSBSim.cxx or so. If not, it should at least be untied before resetting. Best regards, Andreas -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Is there a problem with maintaining vertical sync with MPCarrier? If there is please file a report here: http://code.google.com/p/flightgear-bugs/issues/list Vivian -Original Message- From: Peter Brown [mailto:smoothwater...@adelphia.net] Sent: 25 January 2011 19:33 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Carrier Altitude On Jan 25, 2011, at 2:14 PM, Curtis Olson wrote: On Tue, Jan 25, 2011 at 1:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I expected if flat then the polys would only go down until the mid-span of the ocean surface and then it would rise back up to meet the terrain again. Isn't that what is happening? I don't believe so, as it's no where near mid-span. If the distance was shorter I'll call it a super-long negative swell(swale?), but the distance between the points shown in the images is longer than that. I'll do some more research in different locations. That said, I was looking for information about it so that the carrier could be at actual sea level, or ocean surface rather than hovering above it. If the height-adjust is possible, that'd be a great solution if it kept in sync across MP. Thanks, Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 2:55 PM, Vivian Meazza wrote: Is there a problem with maintaining vertical sync with MPCarrier? If there is please file a report here: http://code.google.com/p/flightgear-bugs/issues/list Vivian No Vivian, Curt suggested that carriers do a terrain height check and follow the polygon curvature of the FlightGear world. Not knowing if there was something in place to maintain sync with vertical change, I commented that that would be a great idea if possible. Peter-- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
2011/1/25 Vivian Meazza vivian.mea...@lineone.net: and the vertical movement would tend to unlatch aircraft on deck from the carrier. Are you sure of that statement ? Can the carrier vertical speed be higher than the speed of a falling object ? My bet would be that the normal reaction forces at the landing gears will vary by a fraction of percent rather than unlatching aircrafts ?!? Just my 2 cents. Bertrand. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Italian Flight Sim Show
Italian Flight Simulator Show: Weekend of March 19-20, 2011 Verona, Italy http://www.pvi.it/joomla/eventi/79-flight-simulator-show-2011/210-documenti-sul-flight-simulator-show I am just passing along information here in case we have FlightGear developers or users that might be interested in this show. Best regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Tue, Jan 25, 2011 at 1:22 PM, Anders Gidenstam wrote: I suspect the option --local to git clone might be useful. I have not tried myself, though. Once you get it all figured out, please let us know how, so we can get setup correctly too. :-) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Tue, 25 Jan 2011 21:08:00 +0100, Bertrand wrote in message aanlktimqvfcd2zf0ee0gqu7tuzxmop_ygdrnbuavo...@mail.gmail.com: 2011/1/25 Vivian Meazza vivian.mea...@lineone.net: and the vertical movement would tend to unlatch aircraft on deck from the carrier. Are you sure of that statement ? Can the carrier vertical speed be higher than the speed of a falling object ? ..only in really bad weather ;o) and only partially, e.g. near the bow and stern for pitching, and high up in the masts for rolling. My bet would be that the normal reaction forces at the landing gears will vary by a fraction of percent rather than unlatching aircrafts ?!? Just my 2 cents. Bertrand. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Tue, 25 Jan 2011, Curtis Olson wrote: Once you get it all figured out, please let us know how, so we can get setup correctly too. :-) I'm not sure this counts as figuring it all out.. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata 7930604 fgdata anders@sleipner:/opt/FlightGear$ git clone -l fgdata fgdata-test Cloning into fgdata-test... done. anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test/ 7930604 fgdata 4614988 fgdata-test/ After checking out the 2.2.0 branch in fgdata-test: anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test 7934896 fgdata 691112 fgdata-test A drawback is that the second clone fetches from the first so one would need to keep the first uptodate to get the latest commits in the second clone. It might be possible to set up fetch and branch tracking to avoid that. I'm not sure what happens if both clones fetch new commits from gitorious - probably that will lead to duplicate files (fetching from the first to the second local repro hopefully doesn't). Both repositories need to be on the same partition since filesystem hardlinks are used. The use of hardlinks also open up for some confusing du results - depending on in which order the files are attributed to directories. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata/.git fgdata-test/.git 3252104 fgdata/.git 4992fgdata-test/.git anders@sleipner:/opt/FlightGear$ du -sk fgdata-test/.git fgdata/.git 3246288 fgdata-test/.git 10808 fgdata/.git Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Tue, Jan 25, 2011 at 7:44 PM, ThorstenB bre...@gmail.com wrote: make isn't smart enough to notice that the older object files were generated from (older) sources, which had identical content to the current (newer) sources. Right. Enter ccache :) -- Csaba/Jester -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On Jan 25, 2011, at 1:13 PM, Curtis Olson wrote: Quick explanation: the world is curved (oblate spheroid) so if in order to have an ocean that measures zero MSL at all points, it would have to be curved. To do this perfectly requires a *lot* of polygons. We have been using large polygons for the ocean so that leads to some errors depending on where you are within the polygon. Near the verticies will be pretty accurate, near the middle could be off by a few meters. Regards, Curt. I don't know how big the tiles are, but I ran a ground vehicle due west from the Golden Gate Bridge to see what the variation was. It may just be that the first tile is out of whack? From terrain edge out to 21 miles it goes down and back up. From 21.2 miles out to 100 miles it's totally flat. Ocean surface as compared to 0 MSL : Golden Gate Bridge : 0 Terrain edge/Ocean start/End of channel : 0 Nimitz : -7m MSL 17 Miles out : -7m MSL 21.1 miles out : -3.7 MSL - At vertical wall, assuming Tile edge 21.2 miles out : 0 MSL - Up on new tile(?) 70 miles out : 0 MSL 100 miles out : 0 MSL Screenshots of locations with lat/lon: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Sea%20Level%20West%20from%20SFO/ Peter -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
The other implication here is that it would be extremely handy to have multiple branches checked out simultaneously for other reasons. git makes branching easy, yes, but if you find yourself bouncing between branches with changes for separate projects, and external events may require you to jump to a different branch at a moments notice, It's a major PITA to have to commit every little thing you are in the middle of to switch to another branch. This is like having to completely clean up your desk before you can work on a new task, and then clean it up again completely before you can jump to the next. I just don't work like that, I bounce between about 12 desktops, 40 browser tabs, multiple coding projects. And then when someone pushes something to the remote repository, you have to clean up the desk again, switch to the master branch, do a pull, and then individually switch to each of your local branches and do a merge. Tedious to say the least, and intrusive to the continuity of my work flow! I know where everything is on my desk ... if you make me clean it up and put it all away 10 times a day ... yeah I have a spotless desk, but I can't actually get anything done! Hope that didn't sound too much like a vent, still trying to figure out how to merge the git view of the world with my own, and I'm still not entirely happy. :-) I'll definitely have to checkout the local checkout feature. Do we understand the branching/merging nuances in this case? Will I need to do a git pull in the master branch for each locally cloned repository or will the hard links ensure that a git pull in one repository is reflected in all the others ... no I suppose not, since the local clones are clones of the first repository ... we'll probably need to still do individual git pulls in each of them (from the master branch) to update them ... so still lots of branch switching and manual fiddling to maintain these local branches. Hmmm. Curt. On Tue, Jan 25, 2011 at 3:16 PM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 25 Jan 2011, Curtis Olson wrote: Once you get it all figured out, please let us know how, so we can get setup correctly too. :-) I'm not sure this counts as figuring it all out.. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata 7930604 fgdata anders@sleipner:/opt/FlightGear$ git clone -l fgdata fgdata-test Cloning into fgdata-test... done. anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test/ 7930604 fgdata 4614988 fgdata-test/ After checking out the 2.2.0 branch in fgdata-test: anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test 7934896 fgdata 691112 fgdata-test A drawback is that the second clone fetches from the first so one would need to keep the first uptodate to get the latest commits in the second clone. It might be possible to set up fetch and branch tracking to avoid that. I'm not sure what happens if both clones fetch new commits from gitorious - probably that will lead to duplicate files (fetching from the first to the second local repro hopefully doesn't). Both repositories need to be on the same partition since filesystem hardlinks are used. The use of hardlinks also open up for some confusing du results - depending on in which order the files are attributed to directories. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata/.git fgdata-test/.git 3252104 fgdata/.git 4992fgdata-test/.git anders@sleipner:/opt/FlightGear$ du -sk fgdata-test/.git fgdata/.git 3246288 fgdata-test/.git 10808 fgdata/.git Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
[Flightgear-devel] list of aircraft that don't load in fgdata
I have tried to load several AC that did not load with filed to load file name errors. So I did a survey of the entire up-to-date fgdata. I used an up-to-date fgrun and went through all the AC. The following do not load even to the viewer in fgrun: 737-100, 737-300, AG-14, Airwave Xtreme 150, CRJ-200, DC-8-63, Fairchild Metroliner, Fooker50-Denim, Jaguar, Late-29, marchetti, MIG-29 Fulcrum, Mirage F1, North American OV-10A USAFE Bronco, Short Empire, x24b, and Zepphelin NT07 multiplayer copilot. This is on an FC14 Linux machine. Some of these did not load because of folder or file names having spaces in them, so they may load under Windows. Dave P. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..replay HUD speed tape bug?, was: Fgdata release branch for 2.2.0
On Mon, 24 Jan 2011 15:04:37 +, James wrote in message a0163f8d-7181-4441-a5a5-260f22d5b...@mac.com: Following on from the release branches of the code, it's now time to make a release branch for fgdata. (In fact it should have already been done, since fgdata contains changes incompatible with the code release branch) I'll create the release branch from 'master' very soon, and then restore files which are incompatible with the 2.2.0 code to a suitable version. I think the main issue here is Torsten Dreyer's environment changes - another option would be to merge the code parts of that to 2.2.0. Note the release branch will contain exactly the files (i.e, Aircraft) that go into the installers - so I'll remove all the other aircraft *from the release branch*. I'll be using the same list of aircraft that was used for 2.0, to begin with. Of course, bug-fix changes to dialogs, Nasal, aircraft or similar can be merged to the release branch. (Martin, I'm informed this would be be an appropriate time to sync the 'Models' dir in fgdata with your official version) As always, any comments or objections, please mention them. ..6 objections and a comment on the bright side, yeronnor, 1. on the c172p door color shades, we have brighter doors in: https://github.com/gasguru/flightgearthings/blob/master/c172p/fgfs-2.2-RC0-screen-024.png and https://github.com/gasguru/flightgearthings/blob/master/c172p/ ..2. the Dragonfly's _top_secret_ engine start-up procedure, the FG standard ~ } } } s procedure does not work, nor is there an Autostart option like in e.g. the 777, no screen shots here, ..and 3. the Sopwith Camel's (fdm?) way too heavily reinforced tail skid, that lead me to try out --model-hz=240, 600, 1200 to try make this chocked up angry bird, humanly controllable, https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-052.png thru https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-062.png ...4. with saner replayed approach and landing speeds... https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-074.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-068.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-063.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-064.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-065.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-066.png ...5. to prevent the Camel's rather excessive tail skid wear... https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-078.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-079.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-017.png ...and 6. the Camel's understandably embarrassed shade metal nose aimed at the 1273 knot face plant, unless we are to believe the HUD speed tape numbers didn't multiply replayed approach speed by the --model-hz=240 etc fdm math tune-up... even has metallic shades... https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-069.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-018.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-019.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-020.png https://github.com/gasguru/flightgearthings/blob/master/sopwith/fgfs-2.2-RC0-screen-021.png ..on the bright side, we of course have the bright yellow Cub: ;o) https://github.com/gasguru/flightgearthings/blob/master/Cub/fgfs-2.2-RC0-screen-006.png https://github.com/gasguru/flightgearthings/tree/master/Cub/ -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM support?
[PREFACE: I'm a FG end-user who's not a programmer, nor am I an intellectual property rights attorney. My sole desire is to use FG as a realistic flight similator, as opposed to using it as a fun game. Please consider the remarks below in that context. Thanks!] On Wed, 2011-01-19 at 19:15 -0300, Victhor wrote: VATSIM requires any developer to sign a NDA before having access to their network, so it's not possible to make a open source client. SB747 was made before the NDA requirement, but I suppose sources can't be released due to obvious licensing issues. I'll get to this in a moment, but first... It seems it has been fixed so that it reports you as the aircraft you're currently using, but I'm not sure. Just to be clear, sb747 hasn't been fixed to report the proper aircraft but, rather, a workaround has been found whereby you file your flight plan via simroutes.com and then once that's done you file a blank flight plan with sb747. Since your simroutes.com flight plan contains the aircraft type, that's what is reported on VATSIM, Now, back to the whole licensing/NDA issue... IMHO, and with all due respect to those who might disagree, while the ideal would be that an FG--VATSIM broker (to use VATSIM's term) would be open source, I do not understand why this has to be mandatory? If VATSIM were saying that FG itself had to become closed-source for it to connect to their network, then I'd be in total agreement. However, that's NOT the case. Correct me if I'm wrong, but what VATSIM seems to be saying is that they don't want just anybody trying to connect to their network, hence the only approved clients policy, and in order to enforce that policy they want to be the only source for releasing the source code. I'm not aware of them wanting to extract licensing fees (i.e. earn income) for access to the source code (right?), and it seems to me they're merely trying to protect the integrity of their network. Is that so wrong? What we have here is an opportunity to take FG to a whole new level, and I'd *really* hate to see that opportunity rejected out-of-hand over this issue. We say on one hand that FG is a serious flight simulation environment (as opposed to merely being a game) and, yet, when presented with the possibility of linking FG to a serious air traffic controlled online flying environment we immediately reject the idea because a client to connect to that environment would not be open source? IMHO, the FG multiplayer environment will *never* match the realism and professionalism of air traffic controlled online flying that VATSIM has achieved. Yes, we have a handful of MP ATC's (jomo, redneck, wookierabbit, and a few others), and those folks do a *fabulous* job. But they're just a handful, and those of us who are seriously flying under their direction are often overwhelmed by gamers who spawn into MP on the runways, ignore ATC directions, and otherwise disrupt (either accidentally or purposely) our efforts to mimick real-life flying under ATC control. By comparison VATSIM has *hundreds* of ATC's who must pass rigid certification requirements before they go to work on the network. VATSIM requires those who access the network to follow ATC directions, and failing to do so will get you booted from that network pretty quickly. It's possible on VATSIM to fly across North America, or even transatlantic, and do the whole flight (including clearance and ground control) under air traffic control the entire time, while being passed to multiple controllers in the process. I have listened to real-life ATC comms on liveatc.net and I have flown FG on VATSIM and, frankly, it's pretty hard to tell the difference between the two. So, while some of us may not like the idea of having to sign an NDA in order to develop an FG--VATSIM broker/client, the simple fact of the matter is this... those of us who want to use FlightGear to fly online in a realistic and professional air traffic controlled environment *can't* currently do that in MP (and, IMHO, likely never will be able to do it), but we *can* do it in VATSIM. In closing, the squawkgear/sb747 solution is an exceptional hack that does work, but if we *really* want to get serious about providing FG users with the capability of using FG as a serious flight simulation environment, then IMHO we should give this a serious look. Regards, Chris -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM support?
HI Chris, Here are a couple quick comment in reply ... My sense is that there are very few people who would outright oppose a vatsim interface to flightgear. I think most people would consider this is a good thing. Here is my question/concern. If some developer gets approved by vatsim and signs the appropriate NDA's and then builds an interface from vatsim to flightgear, then sure, that could be an external closed source application that bridges the communication gap between FlightGear and VATSIM. But here's the problem. Now anyone (good or evil) has a wide open, public, unsecured route into the vatsim network. The flightgear API's are open and you can inspect all the code and structures. So anyone could take the vatsim-flightgear interface and leverage it to interject any kind of nonsense into the vatsim network. This is exactly what vatsim is trying to avoid by protecting their communication protocols. As soon as they allow a translator to be written with an open/published/documented protocol at the other end ... this is the very next best thing for someone wanting to do mischief. Please notice: this isn't me being negative about vatsim, or being negative about the idea of a vatsim interface for flightgear. I'd personally love to have it available one way or another. But I'm trying to place myself in the perspective of what the vatsim folks would think. Hopefully I'm way wrong, but if we lay it all out for them open and honestly up front so we aren't trying to sneak something past them, what do you think they would say? FlightGear doesn't have a binary plug in system so it's not possible for someone to write a closed source plugin to implement the vatsim protocol. It would have to be done as an entirely open-source module within FlightGear, or as an entirely separate external application that communicates with flightgear through some network protocol. So all that said, here's one more thing to ponder. FlightGear is a volunteer driven project. The people that pitch in and do the work get to decide what they will work on and how they will do it. We can discuss vatsim back and forth all day long, but until a volunteer steps forward who's willing (and able) to build the vatsim interface to flightgear, and who is willing to sign all the vatsim nda's, and who is willing to do whatever discussion and negotiation and strategizing and design work that is required to make the system function satisfactorily from the perspective of both vatsim and flightgear ... until such a person emerges, really all we can do is talk about it theoretically. Best regards, Curt. On Tue, Jan 25, 2011 at 11:01 PM, Chris O'Neill wrote: [PREFACE: I'm a FG end-user who's not a programmer, nor am I an intellectual property rights attorney. My sole desire is to use FG as a realistic flight similator, as opposed to using it as a fun game. Please consider the remarks below in that context. Thanks!] On Wed, 2011-01-19 at 19:15 -0300, Victhor wrote: VATSIM requires any developer to sign a NDA before having access to their network, so it's not possible to make a open source client. SB747 was made before the NDA requirement, but I suppose sources can't be released due to obvious licensing issues. I'll get to this in a moment, but first... It seems it has been fixed so that it reports you as the aircraft you're currently using, but I'm not sure. Just to be clear, sb747 hasn't been fixed to report the proper aircraft but, rather, a workaround has been found whereby you file your flight plan via simroutes.com and then once that's done you file a blank flight plan with sb747. Since your simroutes.com flight plan contains the aircraft type, that's what is reported on VATSIM, Now, back to the whole licensing/NDA issue... IMHO, and with all due respect to those who might disagree, while the ideal would be that an FG--VATSIM broker (to use VATSIM's term) would be open source, I do not understand why this has to be mandatory? If VATSIM were saying that FG itself had to become closed-source for it to connect to their network, then I'd be in total agreement. However, that's NOT the case. Correct me if I'm wrong, but what VATSIM seems to be saying is that they don't want just anybody trying to connect to their network, hence the only approved clients policy, and in order to enforce that policy they want to be the only source for releasing the source code. I'm not aware of them wanting to extract licensing fees (i.e. earn income) for access to the source code (right?), and it seems to me they're merely trying to protect the integrity of their network. Is that so wrong? What we have here is an opportunity to take FG to a whole new level, and I'd *really* hate to see that opportunity rejected out-of-hand over this issue. We say on one hand that FG is a serious flight simulation environment (as opposed to merely being a game) and, yet, when presented with the possibility of
Re: [Flightgear-devel] VATSIM support?
Hi, Hmmm, I would take it one step further... You write and operate an FG/VATSIM server running on a dedicated machine(s) and publish the FG open source interface and protocol. The VATSIM side and source in the server is closed and operates with an approved NDA. Anyone may join from the FG side with any approved user name and password and connect to the VATSIM world. Users would be governed by the same rules for flight operations as defined by the VATSIM procedures and regulations. Intentionally violate the rules -- first offense; a warning, 2nd offense; banishment -- go play with the kiddies. Just as an aside, last year the MITRE corporation ( where I had the pleasure of a short stint from Northrop ) conducted a study on runway incursions ( see http://forums.vatsim.net/viewtopic.php?f=78t=51419 ) using VATSIM and FSX. ATM I need to keep my calendar free for a possible contract to build a 737NG FTD that will be FAA certified a Jack HI Chris, Here are a couple quick comment in reply ... My sense is that there are very few people who would outright oppose a vatsim interface to flightgear. I think most people would consider this is a good thing. Here is my question/concern. If some developer gets approved by vatsim and signs the appropriate NDA's and then builds an interface from vatsim to flightgear, then sure, that could be an external closed source application that bridges the communication gap between FlightGear and VATSIM. But here's the problem. Now anyone (good or evil) has a wide open, public, unsecured route into the vatsim network. The flightgear API's are open and you can inspect all the code and structures. So anyone could take the vatsim-flightgear interface and leverage it to interject any kind of nonsense into the vatsim network. This is exactly what vatsim is trying to avoid by protecting their communication protocols. As soon as they allow a translator to be written with an open/published/documented protocol at the other end ... this is the very next best thing for someone wanting to do mischief. Please notice: this isn't me being negative about vatsim, or being negative about the idea of a vatsim interface for flightgear. I'd personally love to have it available one way or another. But I'm trying to place myself in the perspective of what the vatsim folks would think. Hopefully I'm way wrong, but if we lay it all out for them open and honestly up front so we aren't trying to sneak something past them, what do you think they would say? FlightGear doesn't have a binary plug in system so it's not possible for someone to write a closed source plugin to implement the vatsim protocol. It would have to be done as an entirely open-source module within FlightGear, or as an entirely separate external application that communicates with flightgear through some network protocol. So all that said, here's one more thing to ponder. FlightGear is a volunteer driven project. The people that pitch in and do the work get to decide what they will work on and how they will do it. We can discuss vatsim back and forth all day long, but until a volunteer steps forward who's willing (and able) to build the vatsim interface to flightgear, and who is willing to sign all the vatsim nda's, and who is willing to do whatever discussion and negotiation and strategizing and design work that is required to make the system function satisfactorily from the perspective of both vatsim and flightgear ... until such a person emerges, really all we can do is talk about it theoretically. Best regards, Curt. On Tue, Jan 25, 2011 at 11:01 PM, Chris O'Neill wrote: [PREFACE: I'm a FG end-user who's not a programmer, nor am I an intellectual property rights attorney. My sole desire is to use FG as a realistic flight similator, as opposed to using it as a fun game. Please consider the remarks below in that context. Thanks!] On Wed, 2011-01-19 at 19:15 -0300, Victhor wrote: VATSIM requires any developer to sign a NDA before having access to their network, so it's not possible to make a open source client. SB747 was made before the NDA requirement, but I suppose sources can't be released due to obvious licensing issues. I'll get to this in a moment, but first... It seems it has been fixed so that it reports you as the aircraft you're currently using, but I'm not sure. Just to be clear, sb747 hasn't been fixed to report the proper aircraft but, rather, a workaround has been found whereby you file your flight plan via simroutes.com and then once that's done you file a blank flight plan with sb747. Since your simroutes.com flight plan contains the aircraft type, that's what is reported on VATSIM, Now, back to the whole licensing/NDA issue... IMHO, and with all due respect to those who might disagree, while the ideal would be that an FG--VATSIM broker (to use VATSIM's term) would be open source, I do not understand why this has to be mandatory? If VATSIM
Re: [Flightgear-devel] VATSIM support?
NUTS!! was working on a draft and hit send by accident. to finish my comments. waiting on word for a proposal to build a 737NG FTD certified by FAA at Level 5. Should know within the next few weeks, hopefully. That wil wipe me out for the next six months, but can still find some time to get the ball rolling with the VATSIM folks. How about a show of hands? Is there enough interest and volunteers to organize a team to tackle the problem? I can provide a dedicated machine and IP address to host the server and possibly a T1 line. Jack Original Message Subject: Re: [Flightgear-devel] VATSIM support?From: Curtis Olson curtol...@gmail.comDate: Tue, January 25, 2011 10:26 pmTo: chrison...@yahoo.ca, FlightGear developers discussionsflightgear-devel@lists.sourceforge.netHI Chris, Here are a couple quick comment in reply ... My sense is that there are very few people who would outright oppose a vatsim interface to flightgear. I think most people would consider this is a good thing. Here is my question/concern. If some developer gets approved by vatsim and signs the appropriate NDA's and then builds an interface from vatsim to flightgear, then sure, that could be an external "closed source" application that bridges the communication gap between FlightGear and VATSIM. But here's the problem. Now anyone (good or evil) has a wide open, public, unsecured route into the vatsim network. The flightgear API's are open and you can inspect all the code and structures. So anyone could take the vatsim-flightgear interface and leverage it to interject any kind of nonsense into the vatsim network. This is exactly what vatsim is trying to avoid by protecting their communication protocols. As soon as they allow a translator to be written with an open/published/documented protocol at the other end ... this is the very next best thing for someone wanting to do mischief. Please notice: this isn't me being negative about vatsim, or being negative about the idea of a vatsim interface for flightgear. I'd personally love to have it available one way or another. But I'm trying to place myself in the perspective of what the vatsim folks would think. Hopefully I'm way wrong, but if we lay it all out for them open and honestly up front so we aren't trying to sneak something past them, what do you think they would say? FlightGear doesn't have a binary plug in system so it's not possible for someone to write a closed source plugin to implement the vatsim protocol. It would have to be done as an entirely open-source module within FlightGear, or as an entirely separate external application that communicates with flightgear through some network protocol. So all that said, here's one more thing to ponder. FlightGear is a volunteer driven project. Thepeoplethat pitch in and do the work get to decide what they will work on and how they will do it. We can discuss vatsim back and forth all day long, but until a volunteer steps forward who's willing (and able) to build the vatsim interface to flightgear, and who is willing to sign all the vatsim nda's, and who is willing to do whatever discussion and negotiation and strategizing and design work that is required to make the system function satisfactorily from the perspective of both vatsim and flightgear ... until such a person emerges, really all we can do is talk about it theoretically. Best regards, Curt. On Tue, Jan 25, 2011 at 11:01 PM, Chris O'Neill wrote: [PREFACE: I'm a FG end-user who's not a programmer, nor am I anintellectual property rights attorney. My sole desire is to use FG as a"realistic" flight similator, as opposed to using it as a fun "game."Please consider the remarks below in that context. Thanks!] On Wed, 2011-01-19 at 19:15 -0300, Victhor wrote: VATSIM requires any developer to sign a NDA before having access to their network, so it's not possible to make a open source client. SB747 was made before the NDA requirement, but I suppose sources can't be released due to obvious licensing issues.I'll get to this in a moment, but first... It seems it has been fixed so that it reports you as the aircraft you're currently using, but I'm not sure.Just to be clear, sb747 hasn't been "fixed" to report the properaircraft but, rather, a workaround has been found whereby you file yourflight plan via simroutes.com and then once that's done you file a blankflight plan with sb747. Since your simroutes.com flight plan containsthe aircraft type, that's what is reported on VATSIM,Now, back to the whole licensing/NDA issue...IMHO, and with all due respect to those who might disagree, while the"ideal" would be that an FG--VATSIM "broker" (to use VATSIM's term)would be open source, I do not understand why this has to be mandatory?If VATSIM were saying that FG itself had to become closed-source for itto connect to their network, then I'd be in total agreement. However,that's NOT the case.Correct me if I'm wrong, but what VATSIM seems to be saying is that theydon't want
[Flightgear-devel] [FWD: Re: VATSIM support?]
OK, here's the first part, apologies for the screw-up Original Message Subject: Re: [Flightgear-devel] VATSIM support?From: cas...@mminternet.comDate: Tue, January 25, 2011 11:36 pmTo: "FlightGear developers discussions"flightgear-devel@lists.sourceforge.netHi,Hmmm, I would take it one step further...You write and operate an FG/VATSIM server running on a dedicatedmachine(s) and publish the FG open source interface and protocol. TheVATSIM side and source in the server is closed and operates with anapproved NDA. Anyone may join from the FG side with any approved username and password and connect to the VATSIM world. Users would be governedby the same rules for flight operations as defined by the VATSIMprocedures and regulations. Intentionally violate the rules -- firstoffense; a warning, 2nd offense; banishment -- go play with the kiddies.Just as an aside, last year the MITRE corporation ( where I had thepleasure of a short stint from Northrop ) conducted a study on runwayincursions ( see http://forums.vatsim.net/viewtopic.php?f=78t=51419 )using VATSIM and FSX.ATM I need to keep my calendar free for a possible contract to build a737NG FTD that will be FAA certified aJack -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Wednesday 26 January 2011 01:34:35 Curtis Olson wrote: The other implication here is that it would be extremely handy to have multiple branches checked out simultaneously for other reasons. git makes branching easy, yes, but if you find yourself bouncing between branches with changes for separate projects, and external events may require you to jump to a different branch at a moments notice, It's a major PITA to have to commit every little thing you are in the middle of to switch to another branch. Well you don't. Often you just can leave modified files in place while switching branches. If it's not working, you still can simply git stash before switching. git stash creates a temporary branch and commits your local changes to that branch. git stash apply lets you get back those changes, even if you're on a different branch than before (it's just like a git merge stash). I found the book Version control with git quite useful. Yes it's somehow strange to need a book for a simple tool like a VCS, but git's features are IMHO worth having to read a little. Stefan -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
