Staging

[neuoy]

Find some way to specify which stage will enter atmosphere, and don't use the parts that will be discarded during predictions. Also need to check if FAR aerodynamics is more complicated when staging than just ignoring the discarded parts.

[se5a]

+1 vote for this. The attitude options are not so useful without it.

[PBscoots]

Could this be addressed the same way that for example Kerbal Engineer handles deltaV calcs for various staging in construction? or the way Mechjeb handles it in flight? I think they break the parts into stage groups and then do a simulation from there to find the estimated delta V in each stage. This should be simpler? because you don't need to iterate through active engines/thrust levels/blah blah. Maybe the vessel class could be changed to be a custom one that only considers the parts in the relevent stage, and that is what gets passed around the trajectories simulation instead of the full "ship". for the Gui there could be an input box in the settings next to the prograde/retrograde selection where you put the stage that will be going through the atmo. Default is just current stage.

[akors]

@PBscoots I'm affraid it's not that simple. This might have worked when the drag of a craft was the sum of the drag of the parts, but this is not the case anymore.

Nowadays, the drag of a part depends on the parts attached to it. For example, a tank has less drag if there is a nose cone attached to it.

Now imagine that you have a Spacecraft like this: Capsule, decoupler, tank, engine. From retrograde, the capsule is shielded by the whole stack and has very low drag. After you decouple it, the capsule is free and experiences full drag. If you were to predict the trajectory before decoupling, KSP would report much, much lower drag.

[PBscoots]

I think I understand. What about looking at the stage in atmo as a whole new vessel? That way you can run the new vessel through the aero model.

[fat-lobyte]

The critical thing here is a "new vessel". I don't think that you can create invisible/ghost/phantom vessels whenever you please.

AFAIK what is happening now is this:

• KSP, please give me the current vessel
• KSP, please give me the parts of this vessel
• KSP, please calculate the drag on each part in respect to a certain Wind vector

I am not sure that you can a just create magic vessels that allow their drag to be calculated but not be present physically.

@PBscoots , after digging in the code, I am not 100% sure anymore that what I just wrote is true. You might wanna check up on me here: https://github.com/neuoy/KSPTrajectories/blob/master/Plugin/StockAeroUtil.cs#L117

[PBscoots]

Good find! Maybe the _vessel that is passed to those functions could be a new sudoVessel which is basically just the current vessel, with the partlist overwritten with our current vessel partlist minus the parts the would be ejected through decouples. And to find that new partlist maybe we can iterate through the parts the same way KER or MechJeb does it and break them into stage groups.

Incidently I found out while digging through mechjebs code that it also has a trajectory calculation module. I dont use mechjeb really so I never even knew it was there! haha I might try it out tonight for kicks.

[fat-lobyte]

which is basically just the current vessel, with the partlist overwritten with our current vessel partlist minus the parts the would be ejected through decouples

That's my point though: I'm not confident that we can just take copies of vessel objects and manipulate partlists on these copies without affecting a) the original vessel, b) creating a "physical" vessel in the game world and c) null-reffing all over the place. If I'm not mistaken Unity objects in C# contain references to underlying objects in the C++ libs. I don't think you can just go ahead and copy vessels by constructions.

A bug happened once in another mod, where the author thought that the part list that he received was a copy, where it turned out it was just a reference. Upon sorting, the vessel ended up completely garbled up. I also recall a bug in Trajectories, where this mod would blow up wings during reentry.

You're welcome to prove me wrong of course - but in order to do so, you'd have to actually try this out and verify that the original vessel is not being manipulated. But beware that it might get rather icky, rather fast.

[PBscoots]

Hmmm although one sticking point might be that the part list might not be settable. It seems it might only be a get http://anatid.github.io/XML-Documentation-for-the-KSP-API/class_vessel.html#a3fbd809e39b6d8f147cb19ece4478ea0 maybe we could save a new craft file with the reduced part list, and then use vessel.protovessel to get the sim to run without fully loading that craft file. Then at the end of the sim delete it?

[fat-lobyte]

I doubt that it's possible to partially load a craft file. Also the idea of having ghost craft files lying around seems rather yucky.

But like I said, you are welcome to try.

ps.: Since KSP 1.2, there is an official API documentation available here: https://kerbalspaceprogram.com/api/index.html

[PBscoots]

Maybe create a protovessel, then check all the parts to see if they are less than the selected stage using protovessel.protopartssnapshot.inStageIndex and delete everything else from that part list. Then maybe we can run that protovessel through the sim?

[neuoy]

Hi there,

A quick recapitulation of my thoughts on this subject (which are really just thoughts, you are welcome to experiment different approaches if you want):

• For stock aerodynamics, we already do most of the computations inside the mod (i.e. the mod duplicates most of KSP code we need), so it might be possible to adjust that code to work on a partial vessel (adjusting shielding from other parts as fat-lobyte mentioned)
• For Ferram Aerospace Research, we use the provided API to run the simulation, which I think can only run on the current vessel (needs verification). Maybe it's possible to hack something by spawning a new vessel, not sure. Another solution would be to replicate the portions of FAR that are needed (it's open source... but quite complex, and that would become a maintenance hell), or use reflection to call the functions we need (still complicated, and a bit hacky)
• A completely different approach mentioned on the forum, that would work for all aerodynamic models, would be to record the aerodynamic properties of the craft during a re-entry, save that to a file (managed by the user), and then when performing a prediction the user could choose to use the current vessel, or a saved profile. The file would actually contain the forces cache, which we already have in-memory, and is all we need to perform a prediction (plus vessel mass but that's easy to store or re-compute). This solution has gameplay impacts. Some people think it's actually better (you have to run tests on your probe before sending it on a real mission), some would probably find it cumbersome (but still better than nothing I guess).

[PBscoots]

So I just checked out the FAR API, it seems all of the API calls have both ActiveVessel... and Vessel... calls. So an ActiveVesselDynPres is obviously the active vessel, but VesselDynPres can be passed a vessel structure. It also has a function for InstanceCalcVesselAeroForces, which I think is for estimating future possible aero forces based on passed vessel, alt and velocity parameters. You probably already use it though For both stock and FAR, it has to be possible to do calcs on the non active vessel. Think decoupling in atmo and watching the other part burn up and explode beside you. We need to do the same thing, just not load/init the vessel? So maybe we can copy the current vessel into a protovessel struct, delete the non relevant parts from the part list based on instageindex, and then pass that new vessel object unloaded to the relevant FAR/stock functions.

[fat-lobyte]

Sorry guys, I don't have the time to implement this. If I get a magical PR flying my way, I will integrate it - but this looks way too complicated for me.

[PiezPiedPy]

I'm reopening this issue as a placeholder, I have a feeling I could implement staging after I finish the Multithreading #123 since a lot of data is cached and the math for the aero calculations is being reverse engineered and added for thread safety. dnSpy has been very useful in this task. 😁

It should be possible to only simulate the needed parts of a stage, I will have to find out how the occlusion of the detached parts is performed, after that all should be peachy (famous last words lol).

I plan on adding a list of the stages to the GUI where the user can enter their desired deployment altitudes.