So let me try to pull together and visualize the status quo and the
suggestions we had so far.If I forgot yours just add it.
(You need to use fixed-width-font in your mail-client so the following
does not look messed up)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Status quo (this is how xcs behaves now):
goto resume
TASK-Mode ------------> Goto-Mode----------> TASK-Mode
TASK-Mode ------------> Abort-Mode ----------> TASK-Mode
abort task resume
ALT1 and ALT2 ----> autoselected by xcs
Navigation only in one mode EITHER of TASK or GOTO or ABORT.
Only few Infoboxes to show info of ALT1 and ALT2
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Pilot selectable ALT1 and ALT2 (suggestion Robert and others)
goto resume
TASK-Mode ------------> Goto-Mode----------> TASK-Mode
TASK-Mode ------------> Abort-Mode ----------> TASK-Mode
abort task resume
ALT1 and ALT2 pilot selectable to Fields, Waypoints (and markers).
Add more Infoboxes for ALT1 and ALT2 data.
Primary Navigation like status quo. ALT1/ALT2 data in additional infoboxes.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
T,1,2 Modes
cycle cycle cycle
TASK-Mode------>NAV1-Mode-------->NAV2-Mode------> TASK-Mode
any mode ------>NAV1-Mode(goto target set)
goto
NAV1 and NAV2 can be assigned with any position which can be navigated to.
Alternate fields, Markers, (Team Postion, Thermal position...)
The primary Navigation Focus lies on the active mode.
Hence quick switching to the two "preselects" on NAV1 or NAV2 is possible.
Navigation data of non-active modes can be displayed in additional info
boxes for monitoring.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ultimately it will be the developers who decide if (or when) an
enhancement will take place.
I agree with the others in the point that any of the suggested options
would be an improvement.
The pros of the pilot selectable ALT1/2 suggestion are:
- integrates good with xcs-status-quo
- no UI change
- no additional screen element
- less code changes
The pros of the T,1,2 suggestion are
- high flexibility
- fast switching of primary navigation once you decide to divert
- makes status quo Goto-Mode and Abort-Mode (and therefore also
Resume-Task action) obsolete
- makes integration of future addons easy
I don't recall the whole thread anymore, so if I missed a whole concept
or something else important just add it but try to keep it short.
If we have the collection complete I will attach it to Horsts Ticket so
the devs have all the information in one place if they decide to work on it.
Greets Henrik
Am 19.01.2013 09:02, schrieb Robert Hart:
> Well
>
> I didn't expect my original email to generate so much traffic! I have
> been reading all the email but as I'm flying in a comp I really didn't
> have time to contribute until now.
>
> There have been heaps of good ideas. What I'd like to do now is to try
> to restate my initial thoughts in the light of all that has been
> contributed.
>
> The "problem" - XCSoar does not allow navigation to more than one point
> to occur simultaneously. Frequently this ability is useful and on
> occasions (crossing unlandable ground) it is of considerable safety
> importance. Furthermore, selecting another way point to monitor should
> not destroy task information.
>
> There have been a number of solutions offered, but at this point I think
> it's important to make sure that any implemented solution does not
> greatly change the UI (as this will confuse users) nor should the
> solution impose significant recoding from our hardworking, volunteer
> developers.
>
> With this in mind, the solution that seems simplest is to create boxes
> for two additional (non task) nav points. The boxes (and their info)
> could be displayed anywhere, just as the existing boxes and their info
> are currently. I anticipate that I would then set up two additional
> pages per point mimicking my 'cruise' and 'circling' pages to allow me
> to monitor these two additional nav points. This seems to be simpler to
> use (and I hope code) than imposing "modes".
>
> It has occurred to me that having a command that 'drops a point' on to
> the terrain below AND allocates it to one of the two new nav points
> would be useful. Using this command, one could tag a landable point and
> set up monitoring to it very simply as one then proceeds across
> unlandable terrain.
>
> The only other thing that occurs to me is that dropped points should be
> allocate the surface elevation, not the glider's elevation (as occurred
> in the old Cambridge GPS nav "thermal marker")!
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
