Razgriz1

Answered by an easy read through the original post.

RP-1 includes Hypersonic Flight (> 1.5 km/s & Flying Low) and High Altitude Flight (> 650 m/s & Flying High) for the X-15 cockpit. These are, however, using the Kerbalism science system. I'm not sure if that sort of thing is possible with stock science.

Atlas 8A at the Strategic Air Command and Aerospace Museum has conical booster nozzles, though for some reason they also stuck a sustainer engine on it for display. I agree though that it probably isn't worth doing for Atlas.

Why? CKAN >>>>>> CurseForge for KSP mods.

It's not a bug, the satellite payloads now use their own dedicated part, which is found in the "Satellite Era Electronics Research" tech tree node. Also I believe that WeatherSat payload no longer exists at all. The Weather Satellite missions now use NavSat payload.

Aim for like a -800km perigee and you should be able to do it with just one heatshield.

The next thing you'll really want to start looking at is the science you get from the lunar flyby/impactor missions. If you have heat shields, then you should have more than enough tech to get a probe out that far, you're probably just going to have to work on your launch vehicle some. You're probably going need a rocket more around the 60t mark to get it there. A 30t launch vehicle really can't do anything beyond the first couple of orbital contracts. Edit to add: The first generation heatshields (heatsink-style) actually require a steeper reentry than you might think. They also need to make up a substantial portion of the mass of whatever you're trying to bring back.

First, the included BDB craft files will not work at all in RO, they are built using the standard parts and thus part placements will not get rescaled when you move to RO. You will have to build your own from scratch. Second, RO essentially creates their own parts using the BDB models, and rescales them appropriately, so I don't even thing the part names would stay the same. They don't rescale the fuel tanks at all, but they do include a select few of them, mostly the Saturn V tanks, in the modular fuel tanks that are a part of ROTanks, which is a part of the Realism Overhaul suite of mods.

I'd once again like to request a version of the vertical stabilizer with the split rudders as separate parts for FAR compatibility.

It's in reference to the Chrayol Design Bureau mod, which has stockalike ISRO rockets: Now as to what Chrayol means in that context, I haven't the foggiest.

FWIW, the default thrust curve is the most realistic one, where it ramps down around Max Q and then back up.

12.9 doesn't exist

Might be asking about splitting the rudders and the vertical stabilizer into separate parts so that they can work with FAR?

To be honest, PEGAS isn't actually particularly well suited for stock KSP, as it can't do a coast. Stock rockets generally have fairly high TWR, which when combined with the Earth-like atmospheric density and the relatively low orbital velocity, often makes a coast to apoapsis the best ascent path. The RP-1 wiki actually has a section on MechJeb's PVG, which is a similar algorithm to PEGAS (though it can incorporate a coast) and it explains a bit why the rocket it doing what it is: https://github.com/KSP-RO/RP-0/wiki/TroubleshootingMechJebPVG#my-rocket-is-burning-down-not-a-problem You could probably fudge it a little bit by either setting a pretty low g-limiter in PEGAS, or actually set the throttle limiter on the engine to a lower value, just don't forget to tell PEGAS what the maximum limited throttle is.

You probably can (you can do a lot of things with delegates in PEGAS) but I'm not sure you'd really want to do that. The open-loop guidance portion, a.k.a. before "active guidance" is mostly to get you high enough in the atmosphere so that the closed-loop portion can take over. Your open-loop portion should be over fairly quickly before you'd really want to control your time-to-apogee. You'd probably be better off setting up a pitch program instead of a simple pitch angle. You can make a okayish ascent profile without too much effort.

The IRL shuttle isn't designed to be used for anything other than low earth orbit, and this one is modeled fairly realistically. It does not contain any ablator. I doubt this shuttle can survive any interplanetary reentry speeds, though I will caveat that I have never personally tried.

I would assume so, pretty much every SRB in RO simulates thrust tail-off.

The RSS/RO group is responsible for the RSS configs for this, not Benjee. As for the "Thrust is off" errors, that's due to the fact that the RSS configs simulate the tail-off in thrust that occurs toward the end of booster burn, but MechJeb doesn't know about that. It assumes solid boosters burn at 100% thrust all the time. As for what you could do about it, you can force MechJeb to wait to start the PVG until after the boosters separate ("PVG after stage X", or something similar) The PVG settings in the user manual are also designed for stock-ish sized systems, and the stock shuttle. RSS will likely require different settings to work correctly.

I believe that it's Skyhawk Science System.

If you look at the mission time, you start the engines at 1:35, and MJ lifts off at 1:44. This, as you mentioned, is due to MJ waiting for the engines to reach 99% rated thrust before liftoff. BDB does simulate engine spool-up time, and this is pretty darn consistent with the actual F-1 engines. On a Saturn V launch, the engine ignition command was given at t-10 seconds before liftoff.

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.