Jump to content

Suggestion: one-way crossfeed setting for decouplers


Recommended Posts

Quick suggestion, not sure how practical it is or whether it would add unnecessary complexity, but I was messing with the following craft in the VAB today as an example:

WU9wAzz.jpg

Which initially fires all 3 engines, but then drops the outer tanks and low thrust Terrier engines. With crossfeed enabled on the radial decouplers and fuel flow prioritised to the outer tanks, the Terriers begin to consume fuel from the inner tank if I am not paying attention during a burn, rather than burn out. The workaround for me is to disable crossfeed on the decouplers and add 100kg of fuel lines.

I think it makes sense for the decouplers to have a 4-way switch, 'Off', 'Both', 'In', Out" (or up/down for stack decouplers), though I'm not sure if this would have a negative effect on the menu UI which outweighs its utility.

Also of note is that neither the KER mod or the stock dV readouts register an accurate dV unless the fuel line workaround is applied - I guess the code doesn't anticipate dropping engines which still have a fuel source.

 

Link to comment
Share on other sites

Hello, and welcome to the forums!  :)

11 hours ago, ravensierra said:

I think it makes sense for the decouplers to have a 4-way switch, 'Off', 'Both', 'In', Out" (or up/down for stack decouplers), though I'm not sure if this would have a negative effect on the menu UI which outweighs its utility.

This is an excellent idea.  I've found myself wishing for the same thing.

I'd suggest having three crossfeed options, not four:

  • Disabled (the default)
  • Enabled, one-way
  • Enabled, bidirectional

...just make it so that the UI Iooks the same as now, but clicking the button cycles among three states instead of just two.

By "one way", I specifically mean "drain from outer to inner".

I don't think we need to have another state for "drain from inner to outer", for the following reasons:

  1. I have trouble thinking of a use case.  In every single case I have ever used a crossfeed-enabled decoupler, it's because I want to stage away empty tanks.  And so of course I want to drain the thing-I'm-staging-away first.
  2. Adding an extra state, for a use case I never ever use, would add clutter to the UI:  I'd have to cycle through four states instead of three.
  3. Adding the extra state would make it more likely (for me, anyway) to accidentally pick the wrong one during construction, and hilarity would ensure.
  4. If the very rare edge case does come up when someone wants to drain from inner-to-outer, there's an easy workaround:  just disable crossfeed and add a fuel duct.

But anyway, yes, brilliant idea!  :)

So great, in fact, that I sat down to do a bit of rummaging to see "hmmm, can I make a little mod to do this?"  Unfortunately, it looks like the answer is no.  :(

Technobabble in spoiler section for the curious, but the TL;DR is this:  as far as I can tell, the way that Squad has implemented fuel flow, it's unmoddable in this regard.  So the only way to make this happen would be for Squad to make a code change to enable it, which I'm guessing is pretty unlikely at this point.

Spoiler

Why do I think it's unmoddable?  Because this:

Things that have toggleable crossfeed, such as decouplers, use ModuleToggleCrossfeed.  ModuleToggleCrossfeed has a simple boolean for its status, "on" or "off".  What I was hoping was that the code for doing crossfeed would be a virtual method on the module.

Why did I hope that?  Because then, the crossfeed behavior would be fully moddable.  I could make my own PartModule-- call it ModuleDirectionalToggleCrossfeed, for example.  I would make my ModuleDirectionalToggleCrossfeed look a lot like the stock ModuleToggleCrossfeed, except that instead of having a boolean status, it would be tri-state.  And then I would write my own method to call about managing crossfeed ability, which would be different from stock by introducing the unidirectional limitation.  And then I would use a snippet of ModuleManager config to replace the stock modules with my module on all parts, and Bob's your uncle.

Unfortunately, that's not how it works.

"Crossfeed enabled or not", as a simple boolean, is baked into Part itself.  That is, the Part class itself has a boolean "crossfeed enabled" method, and so all the code that does the calculations for fuel flow is hard-coded down in the guts of KSP.  It doesn't give a wet slap about any PartModules.  I'd guess that all that the ModuleToggleCrossfeed does is to take its own status and use that to set the crossfeed ability on the part.

So, no dice.  :(

Does that mean it's completely physically impossible?  Probably not... but I'm guessing that if it is possible, it would be a monstrously large and complex job, probably requiring re-implementing the entire KSP fuel flow system.  In other words, about a hundred times more work than a simple little feature like this is worth (especially considering that it's possible to work around by using fuel lines).  Certainly not a task that I would ever want to take on, as a modder.

Of course, there may be some clever and reasonably simple way to manage this that I'm missing, and I would love for some modder out there (more clever and informed than I) to prove me wrong.  Because I'd love to have a mod like this.

 

Link to comment
Share on other sites

7 hours ago, Snark said:

I have trouble thinking of a use case.  In every single case I have ever used a crossfeed-enabled decoupler, it's because I want to stage away empty tanks.  And so of course I want to drain the thing-I'm-staging-away first.

An Atlas-A style 'stage-and-a-half' design that drops extra engines used to boost T/W early in flight?

Link to comment
Share on other sites

31 minutes ago, Chakat Firepaw said:

An Atlas-A style 'stage-and-a-half' design that drops extra engines used to boost T/W early in flight?

Okay, but I'm still going to want to drain my outer tanks before my center one, no?  Having trouble picturing the use case.

Link to comment
Share on other sites

11 hours ago, Snark said:

I have trouble thinking of a use case.  In every single case I have ever used a crossfeed-enabled decoupler, it's because I want to stage away empty tanks

9ucGrcY.png?1 Why keep the decoupler if I have no use for it anymore? :wink:

Link to comment
Share on other sites

9 hours ago, Spricigo said:

9ucGrcY.png?1 Why keep the decoupler if I have no use for it anymore? :wink:

Sorry, I don't follow at all. I can see that you've got an upside-down stack decoupler there, but it's not clear to me why, or what the ship design is, or what that has to do with wanting to have a one-way crossfeed that goes "backwards", or anything. Could you explain, and/or provide a screenshot with more context?

Link to comment
Share on other sites

1 hour ago, Snark said:

Sorry, I don't follow at all. I can see that you've got an upside-down stack decoupler there, but it's not clear to me why, or what the ship design is, or what that has to do with wanting to have a one-way crossfeed that goes "backwards", or anything. Could you explain, and/or provide a screenshot with more context?

Yea, off course you don't follow. Let say I posted too fast, took me me less time than what should I use to check if it made sense. :blush: But thrust me, there is a point worth considering there somewhere.:rolleyes:

 

Ok. I see two possible ways to define what is 'inward' and 'outward' for this idea.

1.Where the tank lies in the tree structure of the craft. Things closer to the root part are 'inward'

2. Where the tank is relative to the  part that allow crossfeed.

I assume that the reference should be the part itself*. In that case an upside-down/inside-out decoupler would will get the directions reversed, the drop tank will be 'inward' from that point of view. 

Reasons to have the drop tank 'inward'? I can only think about three: A) why not? :P B)Designing a shuttle replica and attaching the orbiter to the external fuel tank is easier than the other way around. C)  I have multiple (2+) vehicles launched together using a central fuel tank but once in orbit  they they separate.  I think those  cases are likely enough to justify the IN and OUT options.

*mainly because it resemble how fuel lines work and because it maintain the setup if the root part change (let's suppose we dock with something).

 

 

Link to comment
Share on other sites

34 minutes ago, Spricigo said:

Ok. I see two possible ways to define what is 'inward' and 'outward' for this idea.

No, there really aren't.  There's really only one reasonable way to define it:  "inward" means "to the parent"; "outward" means "to the child".

Nothing else makes any sense at all, because there's no meaningful way to define exactly what is meant.

34 minutes ago, Spricigo said:

I think those  cases are likely enough to justify the IN and OUT options.

And I don't.

Let's count up some statistics.  Let's imagine that you count up two things:

  1. How many times over your entire KSP career have you ever hit the space bar to activate a stage?
  2. Of those times, in how many of them did you actually care about (and want to keep, and would want to drain last) the thing being ejected, rather than the thing that's doing the ejecting?

I dunno about you, but for me, #1 would be "many, many thousands".  #2 would, indeed, be non-zero.  I grant you that.  But (for me, at least) it's a tiny fraction of 1%.  In 99.9% of cases, I'm staging away the thing I don't want.

So... is it a good idea to add a new UI option, which makes things worse in 99.9% of cases, so that it can be a bit more convenient in 0.1% or less of the cases?  Especially given that there exists a reasonable workaround for those 0.1%:  just use a fuel duct.

It seems like a no-brainer to me.  The question is not "is it physically possible", but rather "is it prevalent enough to be worth the hit of cluttering up the UI for the cases where it's not needed."  For my own gameplay, the answer is a resounding no.  And I suspect it would be "no" for most players, too, given the way I see most folks designing their ships in all the screenshots I've seen.

Link to comment
Share on other sites

@Snark isn't part of the spirit of KSP making the remarkable and quirky possible? I imagine modders and mod-users could find a lot of ways to use a flow direction toggle even if the stock game doesn't required it, and a UI toggle doesn't need to be intrusive or distracting just because it exists.

Link to comment
Share on other sites

54 minutes ago, The_Rocketeer said:

@Snark isn't part of the spirit of KSP making the remarkable and quirky possible?

Absolutely!  And in the 0.1% use case where someone wants one-directional flow the other way around, that's absolutely possible.  Just use a fuel duct.

54 minutes ago, The_Rocketeer said:

a UI toggle doesn't need to be intrusive or distracting just because it exists.

Actually, that's where I disagree.  Any time you add new UI, that always puts a usability tax on the user, because by definition it's adding clutter.  That's bad.  The reason for UI to exist is not "does it have any benefit at all", but rather, "does it provide a benefit whose value outweighs the 'clutter tax' of its mere existence?"

For me, at least:  having an extra menu item in there so I have to iterate through 4 things instead of 3... and maybe pick the wrong one... and I have to do that all the time every time... and the extra thing is a thing that I would want only 0.1% of the time and have a handy easy workaround for the extremely rare case that it's necessary... that seems like a losing tradeoff, to me.

Certainly the advantage/disadvantage of such a tradeoff would depend on player style.  If there were a player who uses MIRV-style launch-multiple-probes-from-a-central-core ships most of the time, then they'd get use out of this >50% of the time and not 0.1% of the time, so it would be a good tradeoff, for example.

But my impression is that most players' usual playing habits aren't like that.  If it's a thing that's hardly ever used, then it doesn't belong in UI that gets in everyone's face all the time, especially if there's an easy workaround.

But of course the real answer is to make it functionality that's based in the PartModule rather than baked into the base Part class itself.  That way, anyone who doesn't like the default behavior could just use a snippet of ModuleManager to fix it the way they like.  For example, if they did add this functionality with 4 options instead of 3, that would be a major pain to me and would make me hate the feature.  But as long as it's a thing where I can just change the properties on the ModuleToggleCrossfeed of all parts that have the module, so that that option goes away?  Then I'm fine.  :)

Link to comment
Share on other sites

29 minutes ago, Snark said:

There's really only one reasonable way to define it:  "inward" means "to the parent"; "outward" means "to the child".

Nothing else makes any sense at all, because there's no meaningful way to define exactly what is meant.

Well, we don't agree in this one. However it's not the point there and I think we may just move on. Some way need to be chosen so we may talk about how prevalent or not are those possibilities. So whatever, there is IN and OUT directions of flow accordingly to StuffTm

 

55 minutes ago, Snark said:

Let's count up some statistics. Let's imagine that you count up two things

Proceed with care, our 'data set' its quite problematic.*  In any case is what we have to work with.

I'd go for a different sequence of questions:

A.How many craft you designed in the last [period of time]¹ playing KSP?

B.How many times you used crossfeed?

C.How many times you would make it better if decouples allowed one-way crossfeed?

D.How many times the direction of flow would have mattered.

D/A is very low, but so is C/A. (from what I know C/A=D/A=0 for most players) The arguments you are using against Crossfeed IN and OUT also works against only Crossfeed IN. Remaining only your preference for the later. Yes it may as well be the preference of a considerable larger percentage of the player base but we don't have data to prove or deny that.

BTW. I'm no dev/modder, so  can't comment on the technical difficulties to implement the idea. Even then I wouldn't be surprised that, quickly after one option become available ,a MM patch that change it to the other option also appearing.

Also agree with @The_Rocketeer. We are talking about unexplored grounds there, the fact we don't see many uses for the functionality may as well be our lack of imagination.
 

¹choose a period long enough to be significant but short enough to be easy to deal with, since you started playing, since version X, #months...

 

* Oh people can come up with statistics to prove anything Kent. Forfty percent of all people know that. -Homer simpson.

Link to comment
Share on other sites

20 minutes ago, Snark said:

 If there were a player who uses MIRV-style launch-multiple-probes-from-a-central-core ships most of the time

I use it pretty often, but never considered a central tank and crossfeed until this thread.

Link to comment
Share on other sites

2 hours ago, Spricigo said:

I'd go for a different sequence of questions:

A.How many craft you designed in the last [period of time]¹ playing KSP?

B.How many times you used crossfeed?

C.How many times you would make it better if decouples allowed one-way crossfeed?

D.How many times the direction of flow would have mattered.

D/A is very low, but so is C/A. (from what I know C/A=D/A=0 for most players) The arguments you are using against Crossfeed IN and OUT also works against only Crossfeed IN. Remaining only your preference for the later. Yes it may as well be the preference of a considerable larger percentage of the player base but we don't have data to prove or deny that.

My own statistics:

A:  a whole bunch

B:  Very very often.  The presence of crossfeed obviates most (though not all) of my need for fuel ducts.  There are still a few times when I need fuel ducts, but crossfeed-enabled decouplers remove about 90% of my former use cases for ducts, so I use this all the time.

C:  Pretty much all of B.  I use crossfeed-enabled decouplers so that I can get the benefit of fuel ducts without having to place fuel ducts.  Saves tons of time in the editor.  Essentially, I almost never want bidirectional crossfeed.  What I really want is one-directional, with the direction from child-to-parent.  But I use the "enable crossfeed" feature anyway, because for me the inconvenience of "it's bidirectional when I don't want it to be" is less than the inconvenience of having to use a fuel duct when crossfeed works instead.

D:  Virtually always. I basically never want to flow from parent to child, and if that ever did come up (say, once for every several months of playing KSP), then I'd just use a fuel duct.

 

1 hour ago, The_Rocketeer said:

@Snark your argument against a fourth switch is less potent than the same argument against a third. The current problem to be solved by this feature is also already solved with fuel hoses. I think you are being selective in your reasoning.

No, not at all.  Because "I need unidirectional flow" is something that I want all the time.  It's a lot more convenient than fuel ducts.

What I'm saying is:  "add a moderate amount of clutter to solve a problem that happens all the time" is worthwhile.  Whereas "add a moderate amount of clutter to solve a problem that practically never happens" is a poor tradeoff.

The above statement is, I think, objectively correct.  If I came and said to you, for example:  "Here.  I'm going to put forty brand-new buttons on the right-click menu of every single part", and they're arranged in essentially random order so that you have to scan through every single one of them to find the one thing you want every single time you use the menu, and all forty of those are for dealing with obscure edge cases that you never encounter so they don't actually help you, personally", then I'm pretty sure you would not like that.  :)

I don't think "pointless clutter is bad" is open for debate.

What is open for debate (very much so!) is how that gets applied, specifically:

  1. How bad is the clutter being added?
  2. How much benefit does it provide?

That is highly subjective, and will vary-- a lot-- from user to user.  For example, the reason that I, personally, am so vehemently against having 4 states here is that given my personal play style, we're in the worst possible scenario for both #1 and #2.  For me, it would be very cluttery (because I tinker with crossfeed options a lot), and the benefit it provides would be virtually zero (because I basically never have any need for flowing fuel from a parent to a child; it's always the other way around).  "Very cluttery" plus "no benefit" equals "bad idea".

However, for a player with a different play style, the calculation could be very different.  For example, if a player almost never does anything with crossfeed options anyway, then 3-versus-4-states would affect them hardly at all, so the "clutter" would be near zero and having the feature would be fine.  Or if you have a player who actually does do MIRV-style ships a lot, then the benefit for #2 would be considerably larger, enough to outweigh the clutter.  So for both of those two cases, I could easily see a player who wants to have the 4 states.

So, please don't get me wrong, here.  I'm not so egotistical as to think "whatever I, personally, happen to like is the 'right' thing and the game should do that."  :wink:  That's not what I'm saying.

I'm just saying the following:

  • Assertion #1:  For me, personally, it would be really bad to be 4-state instead of 3.  It's not simply that I "don't need" 4.  I mean I actively need there not to be.
  • Assertion #2:  My viewpoint's a valid one.  I'm not being unreasonable.  (And I make no claim that my viewpoint's "better" than anyone else's.)
  • Assertion #3:  "Add more stuff to the UI" is always a tradeoff, and it's important to weigh both the pros and the cons.

Other people will have other answers for whether they'd prefer 3 states or 4.  As to the question of what "should" the stock game do:  well, I think it should do whatever will benefit the most players, and/or hurt the fewest. If my own viewpoint happens to be in a small minority, then the game shouldn't cater to me!

But my guess (admittedly, I'm just hand-waving here, and I'm basing this on the completely unscientific method of "what do most ships look like that I've seen in screenshots here on the forums over the past few years") is that the "want unidirectional flow from parent to child" case would be a pretty small percentage of folks who tinker with crossfeed settings, thus the suggestion.

If I seem to be excessively passionate about this,  my apologies.  UI clutter is very much a hot-button topic for me.  I've seen far too many cases of a UI that starts off simple and usable and nice, and then UI creep sets in (where folks only consider "well it would be nice to do X" without considering the "clutter cost"), and eventually the UI turns up into a cumbersome monstrosity full of features that almost nobody uses and which, by their very existence, make it harder to use the features that people do use.  So that any time I see a proposed feature, I always look at it through the lens of "is it worth the tradeoff", because it's always a tradeoff.  I'm fine if things don't go my way because I happen to be in the minority opinion.  :wink:  ...but only if the folks making the decisions are aware that it is a tradeoff, and have weighed both the pros and the cons.

Link to comment
Share on other sites

Things get pretty crazy in my space plane hangar from time to time. I don't necessarily mean insane part-counts though... Sometimes I have no clue what I'm building until it's done. I just kinda wing it, no pun intended. Every now and then, things work exactly as I intend to! Honestly though, I spend maybe 90% of my time in the hangar working out the troubles with whatever mess I made to make it something useful. The rest of my time is split between reverts and test flight...

I digress. I'm conflicted.
@ravensierra and I both have run into this little "issue" enough times in our game to merit the suggestion, but maybe I wasn't so inclined to suggest it because I don't mind the necessary work-arounds as much? @Snark raised several strong points however, because I too feel that my own design theory is a rare case and would rather not change the game for special cases when those work-arounds are available. And I definitely can't share the same distaste for UI clutter, because I'm an avid user of Kerbal Engineer UI customization. :confused: <-me watching numbers in flight!

Ultimately, I would rather see the fuel lines and decouplers both have the 3-state switch. The addition of priority and fuel request overlays not-so-long ago would make said switch like the cherry on the pie for me. I really like this idea... Can we keep it?! :P


 

Link to comment
Share on other sites

@Snark that's a very well written response. Let me testify my own experience.

I see the crossfeed option button in tooltips, but I never, ever use it. Default to a fault. So, right there, I get your 'unnecessary clutter on the UI' point, because I suppose I'm technically a victim of it having an option I don't need. But at the same time, I am not really bothered by that, because I never need to do anything with it whatsoever - I can completely ignore it. Plus, I know that that toggle is a vital option for some players (like you), and matters a great deal to them, so I'm not going to argue for its removal just so I don't happen on it occasionally and think what a waste of space, I've no use for that! I know that having it is good for other players and so ultimately good for KSP's livelihood and therefore for my enjoyment of it.

Spoiler

It's a bit like the NHS in the UK (not a political point) - ambulances are noisy and annoying and I still have to pay for them in taxes even tho I basically never need one (I live 2 minutes from the hospital, and I'm careful with sharp or heavy objects and don't get sick often), but at the same time I know they provide a (quite literally) vital service to a minority of people every single day. This is analogous to the clutter of an option I never use vs the increase in functionality that other players will utilise, ultimately being good for KSP's popularity and therefore (hopefully) sales and support. So, for me personally the base effect is negative (noise/clutter) but the net effect is neutral or good (what's good for society/KSP's popularity is good for me). And if one day I do need that ambulance/crossfeed... well, dividends!

Because I never use the button, I also don't notice if clicking on it cycles 2, 3, 5, or 10 different options (well, I do because I checked once and I have a good memory for trivial things, but you get my point). Adding more adds no intrusive clutter for me, because all the clutter is in one place.

Spoiler

In fact, having all the options I don't use in one place would probably be great for me, because I'd still get the broad benefit of "other players kept happy" without having to suffer the "other players' preferences messing with my game experience" issue.

I suspect there are a lot more players (like me) who don't know, don't care and don't mind about crossfeed, but appreciate that others do or that they might one day and want to allow facilitation of that, than there are players (like you) who have a specific context in mind and want a very specific improvement to their own experience of it.

Link to comment
Share on other sites

@Snark as a thinkthrough option would it be a way to add a fuelline Partmodule to decouplers with the flowway child to parent? This way the decoupler triangle "up" says wich way the flow is enabled?

This way you have 3 options:

No crossfeed (actual)

Crossfeed(actual)

Fuelline (no crossfeed ModulePart Fuelline active)

You add programmingwise a partfunctionality Fuelline to Decoupler?

And if somebody realy needs a way for viceversa he can install the decoupler on upside-down?

I may be oldfashioned but i realy have respect for using actual crossfeed... it is never a pleasant surprise to decouple a lander and see it has been drained on circularisation before the landing attempt...

Link to comment
Share on other sites

17 minutes ago, Urses said:

add a fuelline Partmodule

Pretty sure that won't work-- the fuel lines are compound parts (i.e. they have two attachment points, like struts) and have quite specific codings involved.  They're special, I don't think you can add their functionality to non-compound parts.

Link to comment
Share on other sites

21 minutes ago, ravensierra said:

How is the crossfeed handled on the stack tri adapters etc.? They're one directional aren't they?

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

Link to comment
Share on other sites

On 2017-10-26 at 7:43 PM, Snark said:

Okay, but I'm still going to want to drain my outer tanks before my center one, no?  Having trouble picturing the use case.

With the Atlas stage-and-a-half there aren't any outer tanks, it just dropped the extra engines.

For an in-game use case:  Wanting to use the engines on attached craft that will need full fuel later on, (e.g. a set of probes that will be sent off to various places).

Edited by Chakat Firepaw
Additional thought after posting.
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...