Suggestion: one-way crossfeed setting for decouplers

[linuxgurugamer]

I think I know how to make this work, @Snark

So, when using Advanced Tweakables, you can set fuel flow priority, correct?  I believe that fuel flows from tanks with the highest number to the lowest, right?

So,  create a part module which gets added to radial decouplers which ensures that the attached tank (and all children of it) have a flow have a priority at least 1 higher than the tank it is attached to.

This way the game itself will control the flow.

[Eric S]

  On 10/30/2017 at 6:15 PM, linuxgurugamer said:

I think I know how to make this work, @Snark

So, when using Advanced Tweakables, you can set fuel flow priority, correct?  I believe that fuel flows from tanks with the highest number to the lowest, right?

So,  create a part module which gets added to radial decouplers which ensures that the attached tank (and all children of it) have a flow have a priority at least 1 higher than the tank it is attached to.

This way the game itself will control the flow.

Expand  

That already happens, because the stage the part is in affects the priority, so any part that stages causes this effect.  It still doesn't fix the issue in all cases because once the radial tanks are drained, radial engines will feed off of center stack fuel tanks (or any other fuel tanks that aren't empty).  On the rare occasion that I still use cross-feeding or even more rare, asparagus staging, I still use fuel lines specifically to prevent this, as the engines cut out when the fuel tanks they're attached to empty, giving me a very solid "time to stage" effect that I don't get if I depend on enabling fuel flow across the radial decouplers.

 

[sebi.zzr]

  On 10/28/2017 at 2:57 PM, Snark said:

I don't believe so, no.  I don't think that would even be physically possible.

Expand  

In earlier version of KSP they used to had:

fuelCrossFeed = True
NoCrossFeedNodeKey = bottom

while this could work with stack decouplers there is no way to achieve it with radial ones.

  On 10/30/2017 at 6:15 PM, linuxgurugamer said:

I think I know how to make this work, @Snark

So, when using Advanced Tweakables, you can set fuel flow priority, correct?  I believe that fuel flows from tanks with the highest number to the lowest, right?

So,  create a part module which gets added to radial decouplers which ensures that the attached tank (and all children of it) have a flow have a priority at least 1 higher than the tank it is attached to.

This way the game itself will control the flow.

Expand  

I think you have just described how the game currently handles fuel flow.The outer tanks always have higher priority,but when they are empty,the engines attached to them still consume fuel from center tank,if crosfeed is enabled.

While i'm not against this idea,i think the current solution provided by the game is more than satisfactory and that is the main role of fuel lines!
Simple as:disable fuel crossfeed on decoupler and attach fuel lines to control the fuel flow direction.

[Spricigo]

  On 10/30/2017 at 8:36 PM, Eric S said:

I still use fuel lines specifically to prevent this, as the engines cut out when the fuel tanks they're attached to empty, giving me a very solid "time to stage" effect that I don't get if I depend on enabling fuel flow across the radial decouplers.

Expand  

 

If you don't mind mods:

 

[Eric S]

  On 10/30/2017 at 9:01 PM, Spricigo said:

 

If you don't mind mods:

 

Expand  

Heh, don't mind, had already downloaded it, just haven't installed it yet.  I'm actually fine with the status quo, I was just explaining why priority by itself couldn't fix the problem.

[linuxgurugamer]

It could still be done.  Part module monitors fuel level in attached tank.  When it reaches zero, or another predetermined value, disable cross feed.

Not difficult at all

Keep in mind that in programming there are always multiple ways to solve a problem

Edited October 30, 2017 by linuxgurugamer

[linuxgurugamer]

Just an FYI, I have this working

Not sure yet if I'll release it separately or as part of another mod

[Snark]

  On 10/30/2017 at 9:43 PM, linuxgurugamer said:

It could still be done.  Part module monitors fuel level in attached tank.  When it reaches zero, or another predetermined value, disable cross feed.

Not difficult at all

Expand  

Sure, but doesn't it need to be more complex than that? The part that's actually attached to the decouplers may not be the only fuel tank involved. It may not even be a fuel tank at all. Wouldn't you basically have to walk the entire tree of parts attached to the decoupler to model the fuel flow correctly?

Not saying it would be impossible, but it seems like a lot of complexity to implement, compared with the benefit.

[linuxgurugamer]

  On 10/31/2017 at 4:51 AM, Snark said:

Sure, but doesn't it need to be more complex than that? The part that's actually attached to the decouplers may not be the only fuel tank involved. It may not even be a fuel tank at all. Wouldn't you basically have to walk the entire tree of parts attached to the decoupler to model the fuel flow correctly?

Not saying it would be impossible, but it seems like a lot of complexity to implement, compared with the benefit.

Expand  

Not really.  There is a function call to do that, called part.GetConnectedResourceTotals

So, what I'm doing is this:

At start of flight and upon staging:

1. Create a PartSet of all the parts connected to the decoupler
2. Get list of all connected resources in the connected part using the function:  PartSet.GetConnectedResourceTotals which have values >0
3. If during the flight, ANY of those values using that call is zero, disable the crossfeed

So, this won't work if there is an engine in the attached parts and there is no fuel in the attached parts, so I need to add some code to look for ModuleEngine and ModuleEngineFX and add those resources to the list of resources.  Other than that, it's working nicely now

Edit:  Turns out adding the resources used by the engine modules was fairly easy

I'll get a demo video out this evening

 

Edited October 31, 2017 by linuxgurugamer

[Snark]

  On 10/31/2017 at 1:09 PM, linuxgurugamer said:

Not really.  There is a function call to do that, called part.GetConnectedResourceTotals

So, what I'm doing is this:

At start of flight and upon staging:

1. Create a PartSet of all the parts connected to the decoupler
2. Get list of all connected resources in the connected part using the function:  PartSet.GetConnectedResourceTotals which have values >0
3. If during the flight, ANY of those values using that call is zero, disable the crossfeed

So, this won't work if there is an engine in the attached parts and there is no fuel in the attached parts, so I need to add some code to look for ModuleEngine and ModuleEngineFX and add those resources to the list of resources.  Other than that, it's working nicely now

 

Expand  

Wouldn't it need to be disabled only if all (not any) go empty?  If I've got a radial booster with three stacked tanks, it should kill the crossfeed only if all three of them are empty.

 

[linuxgurugamer]

Any of the resources, not any of the tanks.  So, depending on the tank, you can still have some resources, but if one of them (say, LF) runs out, the crossfeed will be disabled, even if you still have oxidizer.

[Nicias]

If possible, I vote for "ALL",  What if you have a mix of LF only and LF/OX engines on the craft, you might want to keep using the LF even though the OX is empty. I can't quite think of an exact use case now. 

[linuxgurugamer]

  On 10/31/2017 at 2:48 PM, Nicias said:

If possible, I vote for "ALL",  What if you have a mix of LF only and LF/OX engines on the craft, you might want to keep using the LF even though the OX is empty. I can't quite think of an exact use case now. 

Expand  

In that case, you enable full bi-directional, and use SmartParts to do your control. It isn't possible to only allow a single resource to flow through a crossfeed'd part, it's either all or nothing

[Snark]

  On 11/1/2017 at 12:20 AM, linuxgurugamer said:

It isn't possible to only allow a single resource to flow through a crossfeed'd part, it's either all or nothing

Expand  

Though there are different flow modes per resource, right?  For example, electricity is "whole craft" and doesn't care about crossfeed-- it shouldn't be the case that when the booster's battery conks out, suddenly the LFO won't flow.

[linuxgurugamer]

  On 11/1/2017 at 12:43 AM, Snark said:

Though there are different flow modes per resource, right?  For example, electricity is "whole craft" and doesn't care about crossfeed-- it shouldn't be the case that when the booster's battery conks out, suddenly the LFO won't flow.

Expand  

All I'm touching is the crossfeed.  If EC doesn't care about crossfeed, then this won't touch it

[Snark]

  On 11/1/2017 at 1:47 AM, linuxgurugamer said:

All I'm touching is the crossfeed.  If EC doesn't care about crossfeed, then this won't touch it

Expand  

Right... Just saying that if you've got logic tracking "oh, some resource ran out, I should turn off the crossfeed", make sure that it only looks at resources that care about crossfeed.

For example, if electricity running out in the decoupler's child tree caused it to slam the door, that would be bad, because it would stop fuel from flowing. Wouldn't stop EC flowing, as you point out; but it would interfere with fuel.

Will the PartSet be kept dynamically updated? e.g. suppose someone docks stuff to the child tree, so that there are additional resources available in parts that weren't present when the PartSet was initially set up.

[linuxgurugamer]

  On 11/1/2017 at 2:09 AM, Snark said:

Right... Just saying that if you've got logic tracking "oh, some resource ran out, I should turn off the crossfeed", make sure that it only looks at resources that care about crossfeed.

For example, if electricity running out in the decoupler's child tree caused it to slam the door, that would be bad, because it would stop fuel from flowing. Wouldn't stop EC flowing, but it would interfere with fuel.

Expand  

Good point.

So I've changed it to only watch those resources being used by engines in the attached parts.

A possible problem can occur if you have an engine in an attached part, but no fuel in the part, the crossfeed will immediately be disabled, even if the engine isn't active.  In this case, I think that you would want it to be bidirectional anyway, so I'm not going to add the extra code to watch for engines being activated.

[Snark]

  On 11/1/2017 at 2:24 AM, linuxgurugamer said:

So I've changed it to only watch those resources being used by engines in the attached parts.

Expand  

... though that could still be a problem if an engine uses a resource (like electricity) that ignores crossfeed. Also, conceivably there could be other resource-consuming parts besides engines.

Would it not make more sense to base it on the *resource* properties, instead?  Each resource has metadata describing its properties, e.g. its flow model. Which is exactly what you want anyway, I think. So how about just ignoring engines, and instead, simply limit your "resource census" to resources that *do* care about crossfeed. I think that would be more "correct", and probably simpler to code without so many edge cases.

[linuxgurugamer]

  On 11/1/2017 at 2:44 AM, Snark said:

... though that could still be a problem if an engine uses a resource (like electricity) that ignores crossfeed. Also, conceivably there could be other resource-consuming parts besides engines.

Would it not make more sense to base it on the *resource* properties, instead?  Each resource has metadata describing its properties, e.g. its flow model. Which is exactly what you want anyway, I think. So how about just ignoring engines, and instead, simply limit your "resource census" to resources that *do* care about crossfeed. I think that would be more "correct", and probably simpler to code without so many edge cases.

Expand  

I am checking the flow mode, but no need to watch resources which arent being used by an engine

[swjr-swis]

  On 11/1/2017 at 3:17 AM, linuxgurugamer said:

I am checking the flow mode, but no need to watch resources which arent being used by an engine

Expand  

Ion engines use EC though. Conceivably, one could create multi-staged ion probes. Would that run into problems with this?

Another example might be monoprop-only craft, that use the same flow mode as EC?

Edited November 1, 2017 by swjr-swis
mono too

[linuxgurugamer]

  On 11/1/2017 at 9:54 AM, swjr-swis said:

Ion engines use EC though. Conceivably, one could create multi-staged ion probes. Would that run into problems with this?

Another example might be monoprop-only craft, that use the same flow mode as EC?

Expand  

Read above, EC isn't affected by crossfeed settings

[linuxgurugamer]

Demo time:  

 

Resources which have a flow mode of either ALL_VESSEL or ALL_VESSEL_BALANCE are not monitored.

Edited November 1, 2017 by linuxgurugamer

[linuxgurugamer]

I've released the code, it's integrated with my mod: Integrated Stack Decouplers

 

[FleshJeb]

I applaud the discussion, but I'm of the opinion that decouplers shouldn't have crossfeed at all--Under the theory that basic parts should be as mono-task as possible. I just upgraded to the current version from 0.25, and it took me 20 minutes to figure out why my fuel lines weren't being obeyed.

The simplest solution to all this is to make fuel lines massless and dragless.

[linuxgurugamer]

  On 11/2/2017 at 10:33 AM, FleshJeb said:

I applaud the discussion, but I'm of the opinion that decouplers shouldn't have crossfeed at all--Under the theory that basic parts should be as mono-task as possible. I just upgraded to the current version from 0.25, and it took me 20 minutes to figure out why my fuel lines weren't being obeyed.

The simplest solution to all this is to make fuel lines massless and dragless.

Expand  

Updating from 0.25 to 1.3.1 is a very large jump, you missed a lot of updates, I suggest you may want to read all the release notes to see what's new

And the default crossfeed setting is off, I believe, so if you ignore it, then you should be fine.

Oh, and obviously, don't install my mod

Edited November 2, 2017 by linuxgurugamer