Jump to content

Excors

New Members
  • Posts

    4
  • Joined

Everything posted by Excors

  1. I suspect this may have a different cause: MethaneAir engines will consume methane from anywhere in the vessel, regardless of crossfeed. That's because they're configured with an 'ingredientOverrides' that tells them to consume IntakeAir from 'ALL_VESSEL' and Methane from 'STAGE_STACK_FLOW_BALANCE', but because of the way the ingredient overrides are implemented, it ends up applying ALL_VESSEL to the Methane too. I'm not certain but I think that will consume from all tanks with equal priority.
  2. I think this is caused by the BZ-52 radial attachment point (attachpoint_1v_radial). It has been mistakenly configured with a resource cost, and you have no resources available in the VAB (because that's not implemented in the current release), so it triggers the warning. It looks like that's the only part with a non-zero cost.
  3. The circumference is actually being calculated as pi*r^2, instead of pi*2*r. (With r=600km for Kerbin, that gives exactly the value shown in the tracking station.)
  4. I tried investigating this a bit, with some code that reads the flow graph used for the resource flow calculations. Tested by loading the Kerbal-K2, and adding Wombat landing legs to the upper stage's X200-16 with 4x symmetry. Flow graph before launching: This looks fine. (Each box is one part of the vessel, and the arrows show attachments between parts. Resources flow across those edges, except where crossfeed is disabled etc.) Flow graph after launching and staging: That clearly shows a problem: the landing legs are now attached to two different fuel tanks, in two different stages. That means fuel can flow between the tanks via the legs. Digging a bit deeper, the landing legs actually acquire the second attachment shortly after the vessel is created, but (I assume) the flow graph is not dirtied so the new attachment doesn't affect resource flow until staging forces a graph recalculation. (I suspect this is why launch clamps matter in some people's tests: they trigger the recalculation at an earlier stage.) Those attachments come from Module_ReinforcedConnection, which looks like a kind of autostrut. A few parts (landingleg_0v, landingleg_2v, wheel_0v_rover, wheel_3v_rover) are configured with ConnectionTarget=Heaviest, so they're typically going to strut to a first stage fuel tank and trigger this issue. Most other parts with this module will strut to their grandparent part instead. So, I suspect the cause of this bug is that the flow graph is unaware that resources can't flow over these reinforced strut attachments. (Arguably there's also a bug where the flow graph doesn't get dirtied when these attachments are added, so the effect is not felt until staging.) If my understanding is correct, the workaround is: Don't use the ConnectionTarget=Heaviest parts: Bandicoot (XS) and Wombat (MD) legs, RoveMax S2 (XS) and RoveMax XL3 (LG) wheels, unless you're putting them on the stage that already has the heaviest part. If you must use them, make sure there's a non-crossfeeding connection between them and any fuel tanks. The legs will still be connected to your heaviest tank, so you need to isolate them from any later-stage tanks. For any other landing legs, landing gear, wheels, wings, stabilizers, control surfaces: They will still create an unwanted flow connection between their parent and grandparent parts, but I can't currently think of any situations where that would matter, so you're probably fine. (Either the parent and grandparent will be in the same stage, or one will be a decoupler, and I think all of those cases end up working okay.)
×
×
  • Create New...