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]

2 hours ago, 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.

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 ‎28‎.‎10‎.‎2017 at 4:57 PM, Snark said:

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

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.

2 hours ago, 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.

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]

8 minutes ago, 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.

 

If you don't mind mods:

 

[Eric S]

7 minutes ago, Spricigo said:

 

If you don't mind mods:

 

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]

7 hours ago, 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

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]

8 hours ago, 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.

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]

6 minutes ago, 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

 

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]

9 hours ago, 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. 

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]

23 minutes ago, 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

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]

1 hour ago, 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.

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

[Snark]

23 minutes ago, linuxgurugamer said:

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

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]

11 minutes ago, 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.

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]

23 minutes ago, linuxgurugamer said:

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

... 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]

32 minutes ago, 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.

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

[swjr-swis]

6 hours ago, linuxgurugamer said:

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

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]

21 minutes ago, 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?

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]

6 hours ago, 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.

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