re-planning a planned dive

Dirk Hohndel dirk at
Tue Aug 19 19:42:01 PDT 2014

This was one of the outstanding features that we didn't get done in time
for 4.2. And it turned out to be on the one hand not very hard, on the
other hand fairly instrumental to finding quite a few bugs that were still
lurking here and there in the planner code. I think more of the commits in
this series end up fixing old issues than adding new capabilities. And
certainly 3/4 of the time working on this was spent on observing the
issues, understanding their causes and coming up with reasonable fixes for

That said, as usual I have hidden some very cute bugs in the new code,
just to make sure that you guys read what I commit and test it. So please
get started, as always the first one to find a bug in my code will win a
valuable price!

So where are the limitations of the current implementation?

It seems to work quite well in my testing (but who knows once Henrik,
Joakim, Robert and the other usual suspects start doing their testing).

But there is one rather interesting issue: right now we don't save whether
a sample was manually entered or created by our deco (or ascent)
algorithm. Or more precisely, we've never saved this in the past and we
still don't save this information to disk. Which means that when you
re-plan such a dive the dive points table will contain ALL waypoints of
the dive, including the ascent and deco stops (and all such points will
have handlers in the profile). This is of course undesirable (even though
it isn't really hard to get rid of them - especially in the dive points
table it's really easy to just delete them all and they get automagically
recreated by the planning algorithm).

For now I have only implemented an in memory solution. The idea is that
while you are planning a dive you may go back and forth and try multiple
things. And as long as you don't save the planned dive, restart Subsurface
and read it in again, you can continue to make changes as you'd expect.
Only the dive data points that you entered before are in the table and
have handles in the profile. All the other poinst (gas changes, ascent,
deco stops, transitions) will get recalculated on the fly as if you never
left planning mode.

But once the planned dive is written to disk and read back we are back to
what I describe above - ALL waypoints are treated as if they were user

I have a hunch that this is sufficient for most reasonable use cases, but
the simply fact how hard it is to explain this makes me wonder if we
shouldn't save this data to disk, anyway. It obviously would be easy to
add to both XML and git save and parse routines... but I didn't want to
add this until the likely users of this feature have commented if that
would be important to them.

And until all of you had some time to poke holes into my architecture and
implementation for this.


More information about the subsurface mailing list