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.
On 18 July 2011 22:53, Tibor Arpas <firstname.lastname@example.org> 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.
Xcsoar-user mailing list