Razgriz1

It stands for "Human Landing System", which is the name of the NASA program that is in charge of selecting the lander portion of the Artemis Program.

Programatically determining the staging for your rocket via kOS is not a trivial problem, and relies on various assumptions about how a user sets up staging. It also pretty much entirely breaks down in non-traditional staging cases like the booster skirt jettison for the Atlas rocket, which isn't reflected in the stock dV readout at all. You also can't assume any other parameters such as engine ullage requirements or hotstaging requirements (useful in RSS/RO) and so having the user define their vehicle parameters is a much cleaner way to do this.

Yes this allows you to simulate n-body physics

The split rudder is the primary thing that makes this not play nicely with FAR. If that was split into 3 parts (vertical stabilizer and two rudders) then it should be possible to get it working with FAR just in general.

Realism Overhaul does actually have SOCK configs, and you can manually define the wing parameters to get around the issue with node-attached wings. The rudder is not configurable with FAR because it cannot handle multiple control surfaces in a single part. All that being said, I've never flown it in RSS/RO so I can't comment on how good the configs actually are. The Space Shuttle System Expanded mod is supposed to be a lot better for RSS/RO.

No, not really. There are a few parts (especially the split rudder) that can't be configured correctly in FAR. That being said, it will fly, but the aerodynamics aren't remotely right.

One suggestion I would make is to increase the EC capacity of the BDB probes (or really all of the probes tbh), especially the early battery powered probes. Kerbalism removes the hibernation mode, and the early battery powered probes just don't have enough to be very useful. The early Pioneer probes only have enough EC for about 6 hours, which is not enough to reach the Mun, their intended target. In the past, when I was messing with my own Kerbalism configs for BDB, I just multiplied the EC capacity by 6 and that seemed to give them a pretty decent battery life without lasting too long.

Ooh I was just about to start setting up a very primitive version of this with a plugin. Beat me to it It would be great to be able to get this sort of information for FAR as well, though I am currently unaware of any way to export data like this from FAR. Booots has previously stated that FAR integration into Kerbal Wind Tunnel is on the roadmap, but last I saw is that there were some roadblocks that have made FAR integration more difficult than initially assumed. I do know that you can output live flight data using FAR, though that obviously doesn't allow for 3-dimensional interpolation so it's use would be somewhat limited. The FAR analysis tool in the VAB is able to produce the same kinds of sweeps that you'd need, but I am unaware of any way to export the data, other than manually setting up sweeps and recording some data points from them to then build a very coarse map by hand.

It changes the control point to be more aligned with the thrust vector from the SSME's and the OMS. It is useful for controlling the vehicle after booster separation up until reentry.

RO has support for a lot of BDB already built in. It does not have any of the Saturn rework stuff yet since that's still in development right now.

Honestly, I'm amazed that you're still working on and improving this thing. Thank you so much for your effort!

But... I just started learning...

I believe it's in KSP Features on the main Principia window. There should be an option somewhere there to "Select Target" which after clicking that should let you click on a vessel or planet/moon to set it as a target as you would in stock.

You have to click the "Show on navball" button on the Principia Flight Plan window. That will put a maneuver marker on your navball for you to follow.

Yeah, I just pulled them from Google. I haven't been to the USSRC in a little while, so all of my own pictures are a bit old. Yeah its a great place. I hope they start doing the Biergarten again this year.

The Huntsville area already has not one, but TWO Saturn I's on display, as well as a Saturn IB a few miles away: One Saturn I, as well as a bunch of other rockets, at the US Space and Rocket Center (a.k.a. Space Camp): One Saturn at Marshall Space Flight Center itself: And even one Saturn IB at a rest stop several miles north of the city: Also note that the two Saturn I's as well as the one on base that was recently destroyed were test articles. The one at the US Space & Rocket Center was a dynamic test article, meaning it was designed to mimic the expected vibrational characteristics of the full stage, and the two others (the one at Marshall, and the one recently destroyed) were static test articles, meaning they only mimic the expected structural characteristics of the stage, and are not full versions of the stage. In the case of the Saturn I static test articles, they're little more than just the tanks bolted together, with essentially none of the plumbing, or other things that would exist in the actual vehicle. Most static test articles are also destroyed during the normal course of testing, as a chance to see how far engineers can push the structure. The one on display at the rest stop north of Huntsville is the only flight article of the 4 discussed here, though only the first stage is real. The S-IVB and the payload are mockups. Edit: Apparently, Static Test Article meant something different back then than it does today. Turns out that the Static Test Article was indeed used to perform a fair number of static fires, meaning that it was in fact a more complicated article than I originally thought. My bad .

One interesting thing to note with the R2022a version is that when using the slider to scroll through and visualize a mission in LVD, it seems to be slower at drawing the updates than previous versions, resulting in the displayed frames being behind what is currently selected on the slider. Not really an issue, just an observation.

This is definitely what I was looking for, thanks! All great advice though!

This looks amazing, and I can't wait to try it! I can finally start to characterize gravity turn information for different payloads without just trial and error! I also wanted to ask if you could point me to any reference material on mission design/optimization? Like "What constraints are better than others for given goals" and things like that. I've also never really understood the constraint scaling all that much and just kind of brute forced my way through it, but I would definitely need to get better at setting up the initial mission before even attempting to use this new feature.

I believe what @dababykerman was referring to was the SRB Waterfall Effects mod, which does now have partial support for BDB solids. That being said I agree that they don't really give the right look for SRB's in atmosphere, but to each their own.

Happy to help! R2021a: R2022a: CPU: AMD Ryzen 5 1600 Six-core RAM: 24 GB After the Initial setup time, the 2022 release does indeed seem to run the script a bit faster.

@lemon cup beat me to it, but gravity assists are where it's at! Another interesting case is the New Horizons mission. The Atlas V 551 had enough performance to send New Horizons on a direct transfer to Pluto, however using a gravity assist at Jupiter cut down the travel time by ~4-5 years. Table 2 on page 10 of this paper shows various launch windows and trajectories proposed for New Horizons as well as the arrival time at Pluto for each one. As far as planning something like this in KSP, there are several tools that can help calculate these sorts of trajectories. My favorite, and one that works on any planet pack (though it requires a little bit of setup to work on anything other than stock) is the KSP Trajectory Optimization Tool. This thing can basically do full-on mission planning and optimization, but it also has simpler tools like a porkchop plotter, and of relevance here, a multi-flyby finder where you can put in any arbitrary sequence of planets, and it will find the lowest dV trajectory to follow that sequence within a defined time window.

No worries. I have a template save that has the frames set to Earth, and that's good enough. I figured it was probably hard-coded to look for Kerbin, but didn't want to dig through the source to find out myself Edit: Now I'm gonna have to put a launch pad on the Sun, just to make LVD more convenient...

Is there some way to trick KSPTOT into using a body besides Kerbin as the default for things like reference frames? Using RSS it defaults to the Sun instead of Earth (presumably because Kerbin isn't present so it just picks the parent body). I have tried changing various things in the bodies.ini file to try and do this, like setting Earth's id to 1 (same as Kerbin's) and putting it first in the config file, but no luck