[Flightgear-devel] git for dummies
I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? Please explain in simple language. :-) 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/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
What I always do is keep the master (next in FG's case) completely in sync with upstream's master branch. For local modifications I always use another branch. That way, pulling and pushing always works as you'd expect. Merging is easy and cheap with git, i love that! PS, I'm not really a git expert, but this works for me... Stefan 2011/1/4 Curtis Olson curtol...@gmail.com: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected] master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? Please explain in simple language. :-) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
That's probably not a bad tip, but I'm in a situation now where I have local mods that git diff does not report and I'm not sure how to deal with that. How can I find the differences between my local repository and the master ... especially those changes that I haven't committed or pushed yet? Thanks, Curt. On Tue, Jan 4, 2011 at 11:02 AM, stefan riemens wrote: What I always do is keep the master (next in FG's case) completely in sync with upstream's master branch. For local modifications I always use another branch. That way, pulling and pushing always works as you'd expect. Merging is easy and cheap with git, i love that! PS, I'm not really a git expert, but this works for me... Stefan 2011/1/4 Curtis Olson curtol...@gmail.com: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? Please explain in simple language. :-) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ 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/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On 01/04/2011 10:20 AM, Curtis Olson wrote: I'm in a situation now where I have local mods that git diff does not report and I'm not sure how to deal with that. How can I find the differences between my local repository and the master ... especially those changes that I haven't committed or pushed yet? 1) Try this: git stash pop It should undo the effect of the previous git stash. See below for more on this. 2) I generally don't bother with git stash. 3) Constructive suggestion: Never edit stuff on a branch that is tracking a remote. As a common example, if the local master branch is tracking a remote master branch, and if you are sitting on the master branch, do this git checkout mystuff or if necessary git checkout -b mystuff before editing anything. 4) Constructive suggestion: In the all-too-common situation where you forget what branch you are on and edit stuff on the wrong branch, do this: checkout -m mystuff That will take the edits and merge them into where they belong. In my experience, this is wy better than stashing. 5) I have a fancy pre-commit hook that prevents me from accidentally committing something to a branch that shouldn't be modified. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Tue, Jan 4, 2011 at 5:20 PM, Curtis Olson wrote: That's probably not a bad tip, but I'm in a situation now where I have local mods that git diff does not report and I'm not sure how to deal with that. How can I find the differences between my local repository and the master ... especially those changes that I haven't committed or pushed yet? Thanks, Curt. Curt, Try git diff master origin/master or something along those lines. Note that it's also possible to lose your diff within your own local repository, due to the index. I think that git diff shows the difference between your source tree and the index, and git diff --cached either shows the difference between your index and your (local) repository (or maybe your source tree and your local repository, can't remember OTOH). So, try git diff --cached to see if the changes are lost in your index (git status is also good for that), and then git diff master origin/master to see if they are changes between your repository and the remote one (git log and gitk should also make local/remote commit differences clear). Note: I'm also a git newbie, take all this with a massive pinch of salt! Cheers - Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Tue, Jan 4, 2011 at 5:36 PM, Curtis Olson curtol...@gmail.com wrote: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. No. git stash is sort of like a commit + a reset to the previous commit. git stash apply and git stash pop are like applying a patch. A simple thing you can do is git status, which tells you git's idea of the modified files in your working tree. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? As everyone else has said, commit 'em in a branch. Please explain in simple language. :-) Tim -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
Ok, thanks for all the advice. git diff --cached did show me my actual change that git diff had lost. I doubt I'll remember that next time I need it. So I'll look at making changes to a branch in the future. At the moment I'm just trying to unwind my current tree. Apologies if I screw something up in the process ... Curt. On Tue, Jan 4, 2011 at 2:24 PM, Tim Moore wrote: On Tue, Jan 4, 2011 at 5:36 PM, Curtis Olson wrote: I have a git question. I'm trying to git push a new joystick config someone sent me. When I run git push I get the following message: $ git push To g...@gitorious.org:fg/fgdata.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@gitorious.org:fg/fgdata.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. Make sense, so next I run git pull and get the following message: $ git pull remote: Counting objects: 31, done. remote: Compressing objects: 100% (17/17), done. remote: Total 17 (delta 13), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From gitorious.org:fg/fgdata aaef799..4affc2c master - origin/master error: Your local changes to 'Aircraft/f-14b/Nasal/SAS.nas' would be overwritten by merge. Aborting. Please, commit your changes or stash them before you can merge. Ok, I remember tweaking the file Aircraft/f-14b/Nasal/SAS.nas a few weeks ago, and in the mean time I've done a git stash and git stash apply to get around this problem before. I could probably do it again. But here's my question. Now that I've done the git stash and git stash apply commands, when I run git diff, I don't see my local differences. Is a git stash apply similar to a git commit in that it actually commits my local edits to my local repository. No. git stash is sort of like a commit + a reset to the previous commit. git stash apply and git stash pop are like applying a patch. A simple thing you can do is git status, which tells you git's idea of the modified files in your working tree. When I'm just fiddling around, I'd prefer some times to just carry my edits forward as non-committed edits so it's easy to see what I've fiddled with and can clean things up if I no longer need or want my local tweaks. What's the best way now to see what my local changes are after doing a git stash apply? What is the best way to carry local experimental edits forward while I'm still experimenting and aren't sure if I want to keep them? As everyone else has said, commit 'em in a branch. Please explain in simple language. :-) Tim -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ 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/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Datapath name
I haven't pulled from git for a while. I built last night and discovered the name of the data paths has changed from FlightGear to flightgear. I assume this is unintentional? Would someone give me a hint on how to change this back? Thanks Ron (old source Makefile) pkgdatadir = $(datadir)/FlightGear pkglibdir = $(libdir)/FlightGear pkgincludedir = $(includedir)/FlightGear (new source Makefile) pkgdatadir = $(datadir)/flightgear pkglibdir = $(libdir)/flightgear pkgincludedir = $(includedir)/flightgear -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear 2.2.0 changelog (Concept)
Hi All, In anticipation of the next release, I have gone through last year's log of the git repositories for simgear, flightgear, and fgdata, and went though all the newsletters between March 2010 and December 2010 on the wiki. Based on that, I came up with the following summary of major developments Please have a look and see whether I missed anything. Obviously, I didn't want to list every single entry in the changelogs, and for listing the aircraft/scenery improvements/additions, I tried to list just a few highlights. Obviously, some selections are biased towards those entries that I was involved in merging them to git. Please have a look an feel free to comment on any entry. FWIW, I believe that we are very close to having FlightGear in a releasable state. Unfortunately, however, I won't be able to finish the process right now. Starting tomorrow, I'll be heading out on a five week vacation to the southernmost part of Argentina, including a three-week boat trip to Antarctica, so I there's going to be hardly any internet access for me during that time (and even if there were, I probably wouldn't bother. :-). Anyways, I'm about to call it a day, and prepare for a 14 hour plane ride aboard a 747-400. Cheers, Durk FlightGear 2.2.0 ChangeLog The FlightGear development team is happy to announce the release of FlightGear 2.2.0. This new version contains many exciting new features, enhancements, bugfixes, and other improvements. By adopting the newly available shader technology, FlightGear’s graphical quality has been substantially improved, compared to the previous release. Assorted highlights of this version include: new shader based water textures, capturing the sun’s reflection, three dimensional city block textures, more realistic rendering of rocks and mountains, a configurable local weather system, many new and improved aircraft, and numerous scenery additions. Some of the major changes include: Aircraft operations: - Indicated Airspeed (AIS) Limitations can be indicated on the airspeed indicator - Wind-up prevention on simple autopilot systems - Improved autopilots - A new head0up display (HUD) system - Updates to the KLN89 - ATC / ATIS improvements - An in aircraft moving map dialog box AI system - Improved AI ballistics behavior - Ballistic Objects can be slaved to any AI object - Approaching aircraft now follow realistic approach trajectories. - More communication / interaction between AI aircraft and ground. Support for multiple frequencies for AI/ATC interaction. - Speed-up for AI traffic initialization by means of an aircraft usage statistics collection mechanism - A standalone AI FlightPlan generator program AI Traffic - General and Commercial Aviation Traffic at LOWI airport - Malaysian Airways / Kuala Lumpur based traffic - Traffic for Adria (Croatia) Bug Fixes - Inconsistencies in Scenery tile scheduling - Fixed many sources of the infamous NaN errors - Improved placement of random objects - Fixed incorrect METAR weather fetching code - The replay system now works again as advertised Flight Dynamics - A new MIL-STD Turbulence model has been added to the JSB Flight Dynamics Simulation Engine - Environment - Discard of outdate METAR weather information sources and improved METAR parsing - New Fog layers with limited elevation - A Local Weather system to simulate physically correct local weather phenomena - Specific Multiplayer pilots can be selectively ignored Interface - Better integration of separate weather systems - Support fo VNC clients. This allows an external application to output its data to a texture placed within flightgear - Unified runway selection code that is shared between user controlled and AI controlled aircraft. - Autopilot controllers can be used for general purpose processing through a “property rule” system Highlighted New and Improved Aircraft - A new Highly detailed piper Cup - A new and highly detailed IAR-80 (a Romanian produced WW2 fighter) - An improved P51-d, completely remodeled and containing improved flight dynamics - Zeppeling L121 Nordstern - CRJ 200 - Mig-15bis - Improvements to the Boeing 787 - Bombardier CRJ-900 - Douglas A-4F Skyhawk - Short S.23 Empire flying boat - PZL-Mielec M18B Dromader - The Douglas DC-8 Series - The Boeing 737NG Series - Boeing 717 and 757 - Bell AH-1 Cobra Helicopter - The Eurocopter EC130 B4 Helicopter - - The Boeing 747-400 has received night lighting effects - Tire smoke effects on many aircraft Navigation - A new route manager - Autopilots can be driven by NAV or GPS instruments - The beginnings of an EICAS instrument are available on a selected number
Re: [Flightgear-devel] ATIS upgrades
On Tue, Jan 4, 2011 at 5:17 AM, John Denker wrote: I just now pushed a couple more ATIS upgrades to http://gitorious.org/~jsd/fg/sport-model/commits/atishttp://gitorious.org/%7Ejsd/fg/sport-model/commits/atis One of them will, alas, require rebuilding the voice snippet data. http://www.av8n.com/festival/ Mostly this is to improve the internationalization. Hi John, These are committed, thanks! There was one significant change in behaviour which I've reverted for now. Previously, inches were used globally by default, unless /sim/atc/use-millibars was set in which case millibars were used in the UK. Your patch rightly removed the UK-centric nature of the code and expanded millibar usage to all non-US or Canada countries, but also set millibars to be used regardless of that property, with that property forcing millibar usage for the US and Canada as well when set true. I've reverted to the previous behaviour for that property, which means that inches are used globally by default, and if the user sets that property then millibars are used everywhere except US and Canada. I realise that that means that the incorrect units are used in most countries by default, whereas your code used the correct units in most countries by default, but as far as I can tell FG's altimeter setting dialog and most (all?) of the knollsman windows only have inches, regardless of worldwide location of the airplane, so I didn't want to upset the current behaviour so close to a release. If I'm wrong, and FG's aircraft do have millibar support for altimeters, I'll put it back. I'll put it back after the release anyway, to encourage millibar/hectapascal support :-) Cheers - Dave -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: Fwd: Generic Autopilot works by location?
Thought this went to the list. Begin forwarded message: From: Peter Brown smoothwater...@adelphia.net Date: January 4, 2011 11:58:58 AM EST To: Curtis Olson curtol...@gmail.com Subject: Re: [Flightgear-devel] Fwd: Generic Autopilot works by location? On Jan 4, 2011, at 11:38 AM, Curtis Olson wrote: I skimmed through that message but haven't had a chance for a detailed read through. It seemed rather complicated to get to the point where the bug is tickled. I was hoping I could just run ./fgfs --aircraft=someaircraft --airport=someairport and then pull up the autopilot settings dialog and see that things were broken? But it seems like it's much more complicated than that to tickle the bug? Curt. aircraft = MD-81 airport = KBTV --prop:/autopilot/target-tracking/enable=1 Pull up autopilot settings and attempt to change. If unable to change heading, alt hold, or speed to user setting, change /autopilot/target-tracking/target-root = '/ai/models/aircraft[0]' (string) to any number besides [0]. AP should then work. This can be done sitting on the runway. Peter On Tue, Jan 4, 2011 at 10:27 AM, Peter Brown smoothwater...@adelphia.net wrote: Curt, I assume you saw the prior email I sent directly with the screen shots included? If that's what you are referring to then yes, I agree it's strange, but I am unable to narrow it down further due to my lack of programming knowledge. Thanks, Peter On Jan 4, 2011, at 11:23 AM, Curtis Olson wrote: Hi Peter, I haven't had a chance to follow through and try to replicate what you are seeing, but it is strange if there is a link between the hud and the autopilot like that. I'm not sure I've ever played around with target tracking? I've never seen a lock on in flightgear, but I haven't played around with some of the military features much that some of the guys are developing. It seems really strange though if nothing else? If you can condense this down somehow and still feel there is a real problem once you've played with it more, let me know. I can't vouch for how much time I'll have, but I hate having weird obscure bugs lingering around. If too many of them stack up you can end up with an intractable mess. Thanks, Curt. On Mon, Jan 3, 2011 at 5:44 PM, Peter Brown smoothwater...@adelphia.net wrote: Curt, In working it more and more, my general feeling is threefold - 1 - it's likely a case of my not understanding completely how it the AP, HUD, and Target tracking are/were integrated. Meaning that while I assume target tracking allows you to actually lock on to another a/c, most pilots use it as a form of tracking other aircraft, as a visual reference. It appears that this is no longer there in the current git, but that may change when Tat creates a 2.2 build. 2 - I have found that once I enable the target tracking, the autopilot is unchangeable _unless_ I change the mp[x] to at least [8] (at Moffett Field), and then I can change the autopilot numbers to my preference. Once I've done that, I can change the tracking [x] back to any number with no change to the autopilot. At this point none of this matters with the current git files, as enabling target tracking does not bring up the tracking rings on the HUD. Multiplayers on hand while trying this on different aircraft were in the teens. 3 - I have not tried it, but my assumption is now that this same method will work everywhere, provided I keep the current files from git. Why the target tracking is not affected at the northern and southern latitudes is completely unknown. Outside of KSFO all the other airports had no multiplayers within range. So long and short is that seems to be pretty isolated to me. Something changed along the way, for using --prop:/autopilot/target-tracking/enable=1 for tracking ring display did not use to be a problem, and still isn't a problem for another mac user using Tat's snapshot. But obviously it does in what I have set up currently, so now that I know the workaround to get it working I can use it. Sorry for taking up your time. Peter On Jan 3, 2011, at 2:37 PM, Curtis Olson wrote: Hi Peter, I can't think of any reason the basic autopilot functionality would be tied to a particular location. Could you provide a specific aircraft and airport (i.e. command line options) that tickle this bug? Perhaps it's something with your local build? Perhaps it's something really obscure that no one else has noticed? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/
Re: [Flightgear-devel] ATIS upgrades
On 01/04/2011 05:51 PM, Dave L wrote: I've reverted to the previous behaviour for that property, which means that inches are used globally by default, and if the user sets that property then millibars are used everywhere except US and Canada. I realise that that means that the incorrect units are used in most countries by default, whereas your code used the correct units in most countries by default, but as far as I can tell FG's altimeter setting dialog and most (all?) of the knollsman windows only have inches, regardless of worldwide location of the airplane, so I didn't want to upset the current behaviour so close to a release. I agree with all that. I apologize for not thinking enough about the compatibility issues. I'll put it back after the release anyway, to encourage millibar/hectapascal support :-) How about this for an idea: We define a new property /sim/atc/use-inhg to exist alongside /sim/atc/use-millibars with the following specification: -- You always get the native format for your locale. -- You always get the format called for by the properties mentioned above. -- If this means you get *both* the altimeter setting (inHg) *and* the QNH (millibars), so be it. That's a feature. I further suggest that if we make /sim/atc/use-inhg true by default, at least for now, then we can code it this way before the release. There is an upside and no downside. The idea of having ATIS speak *both* formats (when requested) means instrument designers are _able_ to switch without being _required_ to switch, which is the way I like to do things. Or ... does somebody have a better suggestion? -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
