Started doing the Multi - Filter component for dives.

[Anton Lundin]

On 26 September, 2014 - Gaetan Bisson wrote:

> [2014-09-27 01:26:19 +0200] Anton Lundin:
> > There is a wost point, where it would consume the most bailout gas to
> > get the diver to the surface. Thats the point you need to plan your
> > worst case scenario bailout from to size your bailout capacity.
> 
> Maybe you have two bailouts, 6L of air and 6L of EAN80. Bailing out from
> depth early during the dive would give you a deco that uses all the air
> but almost none of the EAN80. And bailing out later during the dive
> while you're shallower uses all the EAN80 but virtually none of the
> air...
> 

Yes?

But the important point to calculate from is in the worst case how much
Air would you need to get to the MOD of the EAN80 to be able to start
using that, and how much EAN80 will you need to use to reach the
surface.

Are your 6L bottles big enough to reach the surface safely?


This concludes that we need to be able to add cylinders for bailout and
use be able to configure where during the planned parts of the dive the
bailout happens. Eg. a 30m dive with 30 min bottom time, the bailout
might happen after say 20 min, but we still need 10 more minutes at the
bottom to get out of the wreck/cave/whatever before we can accent.


> > > Ideally we should give a deco schedule for bailing out at the end of
> > > each planned dive segments. So if you have a multilevel dive with three
> > > segments, you'd have four schedules: the normal one on CCR and three
> > > bailout plans.
> > > 
> > > I think for the moment it'd be good enough to just have a switchbox that
> > > says "compute deco on CCR" and if unchecked on OC.
> > 
> > This suggestion is actually worse than the previous setting a SP on a
> > segment for CCR and setting it to zero for bailout.
> > 
> > How would one calculate a bailout plan with your "compute deco on CCR"
> > checkbox?
> > 
> > How would one switch diluent during a dive?
> 
> Uncheck the box and you would get a deco plan on OC that starts at the
> end of the last planned segment, just like we do for normal OC planning.
> 
> Sure it's not as featureful as you might want; I only suggested that
> option as a relatively simple thing to implement.
> 

Then its easier just to revert dd1dc11cb60ec819d26ae198633546db780dec18
and you have more and better functionality =)

> > I would rather suggest adding a way to choose the sort of dive you are
> > planning, OC by default, CCR and PSCR (maybe), and if CCR be able to set
> > a SP during that leg of the dive, or choose a point during the dive to
> > plan a bailout from.
> 
> Implementing separate UI's for OC/CCR/SCR does not seem like it would
> make things easier to implement or more featureful. If we can implement
> bailout at arbitrary points during a CCR dive why not do the same for OC
> dives?

Planning OC dives vs. CCR dives and SCR dives are fundamentally
different. They really need different types of input.

I say its way better to focus on getting things right than just slapping
some half-baked ccr-features into the oc planner.

> I'm not saying what you propose wouldn't be better. But my goal was just
> to get a basic UI for CCR planning. That's all I can hope to implement
> and I had forgotten it was there before.
> 

If you just want something to semi-do ccr-planning, just revert
dd1dc11cb60ec819d26ae198633546db780dec18 and build subsurface yourself
and you're done.

I would rather see that the project takes steps to build a proper
infrastructure for differentiating OC/CCR/SCR dives and can leverage
that in the planning to.

Willem's work on CCR-logging starts to introduce some of the neccecery
infrastructure to handle the specialities of CCR-diving, and when that
starts to become something we can start to leverage those features in
the planner to.

> > I must have done something bad to my v-planner install because it
> > refuses to compute anything for me right now. On the other hand, there
> > ui looks like a car crash and is the strangest thing I've know, so there
> > is probably no point in looking at it for anything but examples on what
> > not to do.
> 
> On the other hand, that's what many real-life dives are planned with
> every day. It's certainly not perfect, but we could borrow a few ideas
> from it. For instance: its dive plan formatting; it would help planning
> dives with other divers to have some consistency between dive software
> output. See: http://www.hhssoftware.com/images/v-planner_preview_7.png

I really do not agree here. Why should we adapt us to something as ugly
as that? If you like v-planner, fine. By it and use it then =)

I tried to use it for 10 minutes yesterday to figure out how it worked,
but i got so frustrated that i couldn't deal with it anymore.

I currently switch between subsurface and decoplanner to do my deco
planning. There are some features in decoplanner i really like which i
would like to steal and implement in subsurface, but i can't check on
how the CCR-planning is done in decoplanner currently, because i managed
to forget to add 32-bit support in my kernel =(

//Anton - Rebooting to be able to play with decoplanner in wine again

-- 
Anton Lundin	+46702-161604