<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 30/01/2017 10:28, Robert Helling wrote:<br>
<blockquote
cite="mid:46F5C7B9-C4EB-48AE-A93D-24149630D68D@atdotde.de"
type="cite">
<div class="">
<div><br>
<div>I will have to look into this with more time. Please keep
nudging me until this is resolved. <br>
</div>
<br class="">
</div>
</div>
</blockquote>
<p>I did quite a bit of checking of the planner using Version 4.6.1.
I have three points that I think need attention (marked by <b>**</b>)
and some comments.<br>
</p>
<p><b>Merging dives with dive plans:</b></p>
<p>As far as I can see there are no bugs except for:<br>
</p>
<p><b>** </b>In the dive notes the concatenation of notes for the
real dive and for the dive plan are done as <font color="#ff0000">(</font>Dive
notes<font color="#ff0000">) or (</font>Dive plan text<font
color="#ff0000">)</font><br>
The text in red, above, is actually printed as part of the dive
notes. <i>A clear bug</i>.<br>
</p>
<b>Editing a dive plan using the planner:</b><br>
<p>I save the plan, select it again on the dive list and open it for
editing within the dive planner. <br>
1) <b>**</b> Points with zero time duration have been added in
the Dive Planner Points table. Actually, when re-editing the plan
and the duration of the descent/ascent segment is less than 1 min,
the segment is given as having zero duration. In the dive plan
details before storing the plan, the ascent/descent durations have
correct durations, usually 1 minute. This creates ambiguity in
interpreting the plan being edited. <i>See the attached
Screenshot.jpg. I think this needs to be changed to be
unambiguous. At present, the printed dive plan and its
representation in the Dive Planner Points table actually do not
correspond if one compared the runtime and depths for each row
in the two representations. (This is the 2nd last 26m dive in
the dive log I previously sent you).</i><br>
</p>
<p>2) On the profile, a section on back gas has been inserted. If I
delete the zero-duration-points referred to above, this extra gas
segment disappears: <i> This issue is solved as far as I can see.</i><br>
</p>
<p>3) In the planner, the cylinder pressure is not shown in the
Information Box in the Profile panel. This is a pity because it is
extremely useful to be able to see the expected cylinder pressure
during the different phases of the dive: <i> This issue is solved
as far as I can see.</i></p>
<p>4) Re-opening a dive for editing in the planner, the part of the
dive where the planner initially calculated the deco profile,
(upon re-editing) comes up as hard depth/time milestones (i.e.
fixed and indicated by small white circles as if they were forced
(explicitly specified in the Dive Planner Points table) all the
way to the surface during the initial planning. </p>
<blockquote
cite="mid:46F5C7B9-C4EB-48AE-A93D-24149630D68D@atdotde.de"
type="cite">
<div class="">
<div>
<div>There is (at least currently) no way in our file format
to record the distinction between manually entered points
and computed points. Whenever we go through a file on disk,
the whole profile is considered manually entered. That is a
problem of the file format.</div>
</div>
</div>
</blockquote>
<br>
<i>This is a limitation we have to live with for now, but we need
more elegant treatment of the dive plan. I have a few ideas about
dealing with this within the context of the existing dive
structure, but I think they will be frowned upon. For instance,
the depths of auto-planned points could be represented as negative
numbers.
Basically, outside of the planner, negative </i><b>planner</b><i>
points on the profile are drawn by ignoring the sign. In contrast,
within the planner, the negative numbers are deleted, forcing the
planner to recalculate the plan by using the existing "hard-coded"
time/depth milestones. But I suspect most experienced programmers
will consider such an approach as very ad hoc. The first prize is
the ability of the dive plan to look exactly like it was when it
was saved with no hard time/depth milestones in the part of the
dive that was planned by the software.<br>
<br>
</i><b>Unwanted gas change events:</b><i><br>
<b>**</b> I thought Linus resolved this matter when looking at
Miika's case of two dive computers with clashing orders of
cylinder definitions. At present, if I first define a cylinder
with EAN50, then afterwards a cylinder with EAN32: if the first
segment of the dive plan uses EAN32 (i.e. the second cylinder and
gas definition in the Available Gases table), there is an unwanted
gas change from EAN50 to EAN32 at the very start of the dive. Is
there any way avoid creating this gas change event? <br>
<br>
</i><b>Multi-row edits of dive points table:</b><i><br>
</i>
<p> </p>
<blockquote
cite="mid:46F5C7B9-C4EB-48AE-A93D-24149630D68D@atdotde.de"
type="cite">
<div class="">
<div>
<div>This is (at least semi-) intentional. You get the
behavior you want by right clicking on the waypoint in the
profile and inserting a gas change. I always thought this is
the expected behavior: In the table you change a single leg
of the dive, as this is what a row corresponds to, in the
profile you insert a gas change that stays valid until the
next explicit gas change. One might think about allowing
several rows of the table to be selected simultaneously and
then editing one affecting all selected. Let’s see if we can
do that.</div>
<br class="">
</div>
</div>
</blockquote>
<i>I do not think this has been implemented yet?</i><br>
<br>
<b>Weird gas pressure profiles:</b><br>
There are two anomalies that probably have nothing to do with your
two pull requests, but maybe you understand this better than I do.
There are unexpected horizontal and/or vertical sections in the
cylinder pressures in the plan. These anomalies are associated with
gas changes. <i>I cannot repeat these anomalies reliably. If I come
across this again, I will make contact.<br>
</i><br>
Finally, the planner operates in a much more predictable way at the
moment (V4.6.1) and I have confidence in using it for complicated
dive plans. There has really been some significant progress and I
can see some time has lately gone into this code. Thank you very
much for this time.<br>
<br>
Kind regards,<br>
willem<br>
<br>
<br>
<br>
<p> </p>
</body>
</html>