Change to RCS and Xenon flow rules

[Padishar]

Does anyone know for definite what this line from the release notes means?

* RCS and XenonGas containers on earlier stages are now drained before containers on later stages.

From the ResourceFlowMode enum I would guess that they now use a different mode. They used to use ResourceFlowMode.ALL_VESSEL but now it looks like they use a new STAGE_PRIORITY_FLOW value.

I'll try to work out the exact rules later this evening unless someone has already done so (or someone from Squad could just tell us how it works)...

[blizzy78]

I think I should be relatively safe to quote HarvesteR here:

I've added a new resource flow mode called StagePriorityFlow. This new mode is very similar to all-vessel flow, but instead of draining evenly from all parts at once, it will separate the parts into groups based on their staging, and drain the ones on higher stage numbers first, which are more likely to get jettisoned off earlier.

I've changed the flow mode on Monopropellant and XenonGas to this new mode.

Now, if you build a multistage craft with RCS or Xenon tanks in the bottom stages, those will be used first, keeping the ones nearer stage 0 (and presumably the payload) full until no other sources are found. The recent tweaks to all-vessel flow mode, which prevent tanks from being left with unused 'trace' quantities still inside, should also work in this mode, to ensure tanks are properly emptied of all their resources before moving on to the next set.

[Padishar]

Thanks very much for this, it should be fairly easy to implement in the KER simulation code though the decision of when to stage may also need changing to get more sensible numbers (e.g. it currently won't simulate staging until all the engines that will be decoupled run out of fuel).

Do you have a link to where HarvesteR said that? Sounds like something I should be keeping an eye on...

[blizzy78]

Do you have a link to where HarvesteR said that?

It is not public.

[Padishar]

Kasuha has done an analysis of this flow type in his fuel flow thread and it appears to show that Harvester's description is not correct. Rather than the stage number, it appears to use the count of decouplers between the tank and the root part and this value could have little relation to the stage number.

Is there any chance one of the core devs could give us an official description of how this mode works?

[HarvesteR]

Kasuha has done an analysis of this flow type in his fuel flow thread and it appears to show that Harvester's description is not correct. Rather than the stage number, it appears to use the count of decouplers between the tank and the root part and this value could have little relation to the stage number.

Is there any chance one of the core devs could give us an official description of how this mode works?

Ah, indeed, there is a bit of a catch there. The new stage drain logic does use the staging indices for the part, but the thing is, tanks and such are usually not the kind of parts you would see in the staging list, since they have very little to 'activate' by engaging a new stage.

The thing to keep in mind here is that even though the tanks are not present in the staging list, they are still bound by the rules that control the default assignment of stage numbers to every part. That said, there may be a subtle bug here, which I would rather not poke at without having a better understanding of what's really going on internally. In that other thread, you can see that while the tanks are clearly on different stages, they appear to not have inherited the proper stage index after the decoupler. It's hard to tell any more without knowing in which order those tanks were put together, if they were placed before or after the decouplers, or if that happened before or after stages were edited, or even if you copied the other decouplers instead of using fresh ones, all that could be potentially influencing the situation.

I'll try some experimenting here in any case, ideally, I would expect any part that has no purpose in staging to just inherit the staging indexing from the parent part, manually modified or not. With staging related issues, however, well... let's just say if I could pick any part of the game to go back in time and do over... staging would be right there on top on the list.

Another one for when it's time to pave the tunnel, I suppose.

Cheers

[Padishar]

Thanks for the response. When you say "the default assignment of stage numbers" which member of the Part class are you referring to? Does it simply use that member of the mono/xenon tanks to group them? I can (and probably will) run some tests to see if my "count of decouplers between tank and root" is equal to one of the Part member variables.

The trouble with all this is that the game allows you to create a vessel where the decouplers are not in a simple sequence and/or the root is not in the last stage. The simulation code in KER (and MJ uses something virtually identical) uses a strange function that scans up through the parent links looking for decouplers to determine in what stage a part is decoupled because there doesn't seem to be any member of the Part class that is set correctly. However, this entire approach is flawed because it is possible to create a rocket whose root part is in the initial launch stage and when this gets staged, all the wrong parts get removed from the simulation because it causes the parts above the decoupler to be removed from the vessel rather than the ones below. I've done some thinking about how to fix this (see the KER thread) but, to do it properly will probably require the simulation code to actually split the part tree into two separate vessels when a decoupler is fired (just like the game does) and either decide which is the important one or possibly continue simulating both of them.

I also would like to see the staging mechanism overhauled. It could be very useful if anything that can be added to an action group could be assigned to a stage, effectively making the stages into a list of action groups. I would particularly like to be able to decouple docking ports and extend solar panels using staging. I would also like to be able to remove engines and decouplers from the staging list (there is at least one mod that allows you to do this).

[HarvesteR]

The value in question would be Part.inverseStage.

And yes, staging is a deceivingly complicated piece of logic. You'd think it would be something as simple as recursing through the ship and handling it as a simple tree structure, and then you get to the edge cases, and you feel like you just walked into a room full of zombies.

Having the main 'pod' section of the spacecraft not share the same stage as the root of the ship (the first part you placed) causes a number of mind-bending situations... What happens to the vessel when you drop the main bits that were controlling it?

That's something we call 'root-dropping', although it is a bit of a misnomer. You're dropping the core of your spacecraft, but the root of the vessel was not part of that core, so from the core's perspecting, you've 'dropped' the root of your hierarchy.

We work around that by detecting whether the ship you're now in control of is still more than a piece of debris. If it's not, then we switch focus to the jettisoned bit. You can see that happen sometimes as the camera tends to jump slightly instead of flowing smoothly towards the new center of mass.

Hierarchy shifts happen all the time as you play. Docking is what got that whole thing started, as as you docked, the 'docker' side of the pair would shift its internal part hierarchy so that the docking port itself was the root of the vessel, and everything from there down became children of it. Then upon undocking (assuming the vessel still contained its original root part... man, 0.18 was a pain to debug), we flip the hierarchy back again so the old root is now the parent for everybody else.

Now, with the whole 'we can now shift hierarchies' thing added, we saw that there was no need to enforce that a pod be the initial part on a ship. As long as it was something you could attach other parts to, there was no reason why anything couldn't be the root, but it did create the new problem in which the command pods now were not only optional, they also were possibly placed after decouplers. Hence, root-dropping.

Anyhow, I should get back to work here. Best of luck with your mod.

Cheers