In the situation that you would be drifting more than circling, you can't reach the goal according to the computer, and the final glide bar shows a solid cross indicating this.
Making the behaviour configurable is a poor solution --- with two possible behaviours, users are not certain which way they have it set up, discussions about how the program work become more complicated because it introduces ambiguity as to how one's personal setup is configured, and finally, it adds burden on the users, many of whom are not confident in how the program should be configured. Far better to have set behaviour. Please enter a ticket, marked as 'enhancement'. Also kindly take note that threats to abandon xcsoar if your request isn't taken up is not a good motivator for developers, nor a good rationale for change. On Tue, Nov 22, 2011 at 9:11 AM, Ramy Yanetz <ryan...@yahoo.com> wrote: > Sounds like most of the repliers prefer the conventional way of calculating > arrival altitude without assuming that the only lift I will find along the > way is 0.5 knot since I am using conservative STF and that I will be silly > enough to circle in it while drifting more than climbing. I can't imagine > why someone would prefer it this way but I realize that there will always be > opposite opinions. > So the conclusion is to make it configurable. I am concerned that such a > critical change was made without making it an option. > I would like to request that any enhancement made going forward will be > *always* made configurable if it will change any existing behavior. This is > crucial to make XCS safe and reliable. > Turbo, please let me know if I still need to open a ticket. I think this > should be fixed ASAP, I personally wouldn't want to fly with it again this > way, after almost picking up an alternate landing believing XCS which was > telling me there is no way I can make it... I may need to switch back to my > old PDA running WinPilot until this bug is fixed.. > Ramy > > On Nov 21, 2011, at 7:05 PM, Sascha Haffner <s_haff...@yahoo.com> wrote: > > Hi, > > regarding speeds to fly - I use my LX5000 for speed to fly indication (beep > sounds) and therefore I set my best guess for MC at the LX5000 (Cambridge > etc). XCS I use with a safety MC value (higher, than the MC in the LX) > with Vers. 6.0.10 (old solver) to give me conservative values of AltRequired > / Arrival Height. While comparing the arrival heights of the two > instruments it gives me a nice redundancy (using even two GPS sources, Flarm > and LX) and ease of mind. > But again, I understand not everyone flies that way or has two instruments - > therefore please please make the solver use configuable. > > Thank you guys. > > Cheers, > Sascha > Von: Evan Ludeman <tangoei...@gmail.com> > An: xcsoar-user@lists.sourceforge.net > Gesendet: 17:52 Montag, 21.November 2011 > Betreff: Re: [Xcsoar-user] About MC and tasks > > No, you're certainly not alone. I've been trading email with JW privately > this morning. > > Ramy, I agree with everything you've said here. I fly the same way. > > FWIW, I never use a PDA for final glide... there's too darned many ways to > get it wrong and XCS seems to be exacerbating the trend here. I rag on > other aspects of the 302/303, but one thing it does pretty well is calculate > a glide to a turnpoint. It will also do a final glide with HW/TW component > wind which is *really* useful. and yet to be picked up by XCS. > > Another thing I pretty much never do is take speed to fly information from > any instrument. You understand why! > > There's a critical need in soaring software to separate speed to fly from > glide calculation that so far hasn't been met by anyone. It is often the > case that the fast (and safe) way home is Mc 1 or 2 speed to fly and Mc 3 or > better on final glide. Likewise, speed on task need not be calculated by > your speed to fly Mc setting. > > -Evan Ludeman / T8 > > > > > On Mon, Nov 21, 2011 at 11:24 AM, Ramy Yanetz <ryan...@yahoo.com> wrote: > > After using XCSoar for a while I am very impressed with it but at the same > time surprise that it assumes that everybody fly according to MC theroy and > with pre defined tasks. Most pilots I know, which are serious XC pilots, do > not set tasks and do not fly according to MC theory, which is way overrated. > In most place in western US you will want to fly at low MC to stay at the > sweet spot above the mountains and near the clouds. But it looks like XCSoar > insists that if you don't fly according to MC you can't go anywhere since > you can't climb, and that if you fly for OLC than you also have a task pre > declared. > Flying strictly according to MC is a guarantee way to land out often. An > example from my last flight: release at 1500 feet, made 3 turns in 3 knots > and hit the inversion at 2000 feet, next thing you know XCSoar tells you to > dive to the ground at 80+ knots at MC 3. Instead of flying at best glide to > stay aloft. And if I change to mc zero it assumed I can not go anywhere > upwind since I can not climb. If so, how did I manage to fly 200km tip > toeing from one thermal to next at MC between zero and 0.5? > I think this is a flaw to assume this. Am I alone thinking this? > > Ramy > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
