Hi everyone,
Perhaps a way to manually set the start time after the begging of the task
would allow XCSoar to continue with the appropriate calculations after a
crash has occurred. Better yet, every time XCS detects a start it writes a
temp file containing the start time height and speed as shown on the screen,
if a crash happens the pilot can choose to load the task start data from the
file, this file should never grow as it is overwritten each time a task is
started/restarted. A simple button "load last start" could be placed
somewhere in the Nav/Task menu.
Luke
On Tue, Jul 19, 2011 at 8:14 AM, Simon Taylor <simon.taylor...@gmail.com>wrote:
> On 18 July 2011 22:53, Tibor Arpas <ti...@bidforfix.com> wrote:
>
>> Hi guys,
>>
>> I would like to ask those of you that fly competitions if you are happy
>> flying AAT tasks with XCSoar? During the two competitions I used XCSoar I
>> came too soon too many times. Once I made a user error and a couple of time
>> XCSoar crashed during the flight. I don't think that the crash itself is
>> anything that bad and I can live with that. What makes XCSoar unusable for
>> me for my AAT tasks is that the start time is lost when the program or the
>> device crashes.
>>
>> After experiencing the problem I was trying hard to notice/remember my
>> start time and do my calculations manually. But my conclusion is that it's
>> too difficult and distracting. How many people here fly AAT tasks on
>> competitions? I find it surprising that hardly anybody asks for the
>> functionality mentioned in subject.
>>
>>
> Crashes are as important as it gets! :) After all, if the bug causing the
> crash happens to be in the AAT code and the AAT state is restored at
> startup, what's to stop XCSoar entering a continuous loop of crashes?
>
> The feature request is valid, but it's a good time to point out that if
> crashes occur it's important they are reported quickly and with as much
> detail as possible about the device, XCSoar version and the setup during the
> flight, preferably with the IGC log of the flight up to that point
> attached.
>
> The reason it's important that they are reported quickly is that when a bug
> is reported the developers will look through the recent changes to see if
> there is an obvious cause. If the bug has not been reported for some time,
> the search area is that much wider.
>
> The reason it's important to provide an IGC is that the developers can use
> the IGC file to replay your flight and hopefully trigger the cause. Once a
> problem can be reproduced, the trigger can be isolated and a solution can be
> found.
>
> Simon
>
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Xcsoar-user mailing list
> Xcsoar-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>
>
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
