Skip to content

Instantly share code, notes, and snippets.

@gotmachine
Last active June 26, 2025 14:27
Show Gist options
  • Save gotmachine/a31e6f10cf2cc641d4c3976b0ee28f86 to your computer and use it in GitHub Desktop.
Save gotmachine/a31e6f10cf2cc641d4c3976b0ee28f86 to your computer and use it in GitHub Desktop.
KSP RessourceFlowMode breakdown

Flow modes

There are 4 ways a resource request from a specific part is handled. The ResourceFlowMode enum has more values, but there is no difference between some of them.

NO_FLOW

  • Only the resources on the part the request originate from can be reached
  • The resource can only be used if flowState is true

ALL_VESSEL / ALL_VESSEL_BALANCE

  • The request will reach all parts on the vessel, excepted those for which the resource flowState is false
  • The request is split evenly between all reached parts able to fullfill the request (not empty if pulling or not full if pushing)

STAGE_PRIORITY_FLOW / STAGE_PRIORITY_FLOW_BALANCE

  • The request will reach all parts on the vessel, excepted those for which the resource flowState is false
  • At a given time, the request will only reach parts of the same priority, starting with those having the highest priority
  • It will move on to parts of a lower priority only once all parts of higher priority are empty (if pulling) or full (if pushing)
  • The request is split evenly between all currently reached parts able to fullfill the request (not empty if pulling or not full if pushing)

Note on priorities :

  • The game automatically assign the same priority to all parts belonging to a same stage.
  • A stage here refer to a set of parts separated by a staged decoupler. If the decoupler isn't staged, it is ignored.
  • The crossfeed setting of the decoupler is ignored.
  • The assigned priority depends on the order of the stage in staging list. First stages get the highest priorities.
  • Priorities can be overridden by the user on a per-part (but not per-resource) basis using the "priority offset" button in the PAW.

STACK_PRIORITY_SEARCH / STAGE_STACK_FLOW / STAGE_STACK_FLOW_BALANCE

  • The request can only reach parts connected to the requesting part and not separated by a "no crossfeed" rule.
  • Crossfeed between parts is disabled by being connected to a part that either :
    • Disable crossfeed by itself, like decouplers, some structural parts, wings...
    • Has an attach node (can be a stack or surface node) for which crossfeed is disabled. As far as I can tell, this isn't used anywhere.
  • Amongst all parts that can be reached, this use the same rules as for STAGE_PRIORITY_FLOW

Usage

The default ResourceFlowMode for a resource is primarily set at the resource definition level. However, a resource request can be done with any flow mode. For example, it is possible to define an alternative resourceFlowMode in the PROPELLANT node of a ModuleEngine or a ModuleRCS, or an alternative FlowModein theINPUT/OUTPUT_RESOURCEof aBaseConverter`.

A note on fuel ducts

The only thing a fuel duct is doing is creating an additional one-way connection between the parts it is attached to. The intended usage is in conjunction with the STACK_PRIORITY_SEARCH mode. If you place a fuel duct so that it cross two stages separated by a decoupler, this effectively bypass the "no crossfeed" rule as far as the STACK_PRIORITY_SEARCH rules are concerned, but only in one way. One stage will draw from the other (assuming priorities are set adequatly), but the other won't be able to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment