Fuel Transfer

[erendrake]

I think that now that docking is possible I would like to tackle fuel transfers. This would involve two structures

• Part
• Element

The goal of elements ( one that has never worked becuase i was stubborn ) is to give you access to a list of the docked 'elements' of a craft. Something like

I know that this can work because of an old mod that dissapeared in the Spaceport apocalypse called vfm fuel panel that looked like this

http://imgur.com/a/xbpIu

i saved the code from this mod and i am almost finished getting the element list working in kOS

once you are able to get a handle on some combination of part/part element/element part/element it would be nice to have a function to the effect of.

// Transfer whatever you can
TRANSFER(oxidizer, PART, ELEMENT).

// Transfer X amount
TRANSFER(water, PART1, PART2, 50).

VFM had other types of transfers for "reserve this amount" and "transfer x%". I think that users can calculate how much to transfer.

There would have to be some kind of transfer rate and because it is not instantaneous there would have to be a way to figure out if you are done

 TRANSFER(oxidizer, PART, ELEMENT).
 FOO:FINISHED

or the craft would have yet another suffix

TRANSFER(water, PART1, PART2, 50).
SHIP.TRANSFERS  //this would hold only the transfers that arent finished yet?

Anybody have any thoughts?

[Dunbaratu]

If I recall, I think the GUI has a fixed transfer rate that varies depending on the sizes of the tanks or something. I know I've seen it where large tanks transfer fast and small tanks transfer slow.

But the point is that there is probably a max rate we should support so we don't just instantly teleport fuel immediately around.

I'd prefer an interface like this:

Return an object representing a particular resource movement, like so:

// Setup a Transfer 360 units of liquidfuel from
// part1 to part2 at a rate of 0.5 meaning "half of max speed"
SET thisMove TO TRANSFER(liquidfuel, part1, part2, 360, 0.5).

Then actually control the start/stop of the transfer like so:

SET thisMove:TRYING to true. // transfer starts happening
wait 5.
thisMove.TRYING to stop. // transfer stops

And of course you can query the transfer for how much resource it has to go yet.

WHEN thisMove:REMAIN = 0 THEN { SET thisMove:TRYING to false. }.
SET thisMove:TRYING to true.

thisMove would have the following information taken right from its constructor:

:RESOURCE // name of resource
:FROMPART // PartValue of part
:TOPART // PartValue of part
:REMAIN // how much hasn't been transferred yet
        // (initial val = amount passed into constructor, but it decrements as GO() does its work.).
:RATE

And it would have the following values for its current state

• boolean :HASROOM True when the destination has capacity to hold more of the resource being transferred. False when the destination cannot hold any more of the resource. Note that a destination that is incapable of holding the resource at all (trying to store fuel in a girder) should always be reported as having no room for the transfer.
• boolean :HASPATH True when the transfer is possible through a path. False when there's no suitable path through which the transfer is allowed to take place. (i.e. trying to transfer fuel between parts on two different vessels might do this.)

I picture the algorithm being that a TRANSFER is an object that responds to Update()s, or FixedUpdate()s, and each update, we have it do this pseudocode:

If TRYING {
    if HASROOM and HASPATH {
       attemptedMoveAmount = (maxMoveRate * userRateCoefficient /*the :RATE suffix*/) * updateTimeDelta;
       actualMoveAmount = MIN( attemptedMoveAmount, roomLeftInDestination );
       Move actualMoveAmount from source to dest.
    }
}

[erendrake]

Do you think anyone is going to want to actually configure the rate? I thought about adding it too and then wondered if i was doing what engineers do :)

This is going to be a fun bit of code.

[Dunbaratu]

The only reason for allowing a slower rate is when you want to do the fiddly job of balancing two tanks and making them equal. Trying to do that via the user GUI is such a PITA because it moves too far in each little click. I imagine a script would have an easier time of it if it could slow the rate down and thus catch it exactly at the right moment.

Wait, no that's not a problem - because we can tell the transfer to only transfer the desired amount of fuel and just run it until it's done.

[pdbogen]

I, for one, would definitely use proportional control to set the rate relative to the amount I want to transfer at any given moment.

(But, I'm an engineer, and that probably also counts as doing what engineers do.)

(The immediate use case I envisioned for this, as Dunbaratu mentioned, would be for balancing of fuel tanks.)