AVaughan

From memory RP-1 uses it as an rcs fuel. (I'm guessing it is defined in Real Fuels, and probably available in RO, but I only ever use those mods as part of RP-1, so I'm not sure whether it is available without RP-1).

No. You misread that. Starship should fly before ksp 2 releases. With luck it will reach orbit before KSP 2 releases. (If they are really lucky and/or KSP 2 sees further delays, they might land one from orbit before KSP 2 is ready to launch). However Martian colonisation flights won't launch until after the KSP 2 release. (If KSP 2 sees further delays, then the lack of development software might delay Starship colonisation flights to Mars. KSP 1.10 is good for orbit, but for colonisation, you want KSP 2).

I'm guessing "Real Kerbal System", the same way RSS is "Real Solar System".

I'm pretty sure there is no released version for 1.9.0. There is a link to the 1.9.1 version in the first post.

The latest version of KSP is 1.10.1

I'm assuming the above is with superheavy vertical, and without any thrust vectoring? There is the option of thrust vectoring which should get you a little closer to hovering, even with superheavy upright. Taking the centre diagram you should be able to tilt the 40-55% pair away from each other. 8 degrees of thrust vectoring mean the cosine loss is about 1%, which would allow the third engine to throttle lower. That gets you a little closer to hovering. There is also the possibility of hovering with superheavy canted over. Taking the centre diagram, tilt SH so its COM is offset slightly towards the bottom pair of engines. If you have the right amount of tilt, then the third engine should be able to throttle to match the bottom pair. (I'm not sure how much tilt that is, but I'm guessing it is around 5 degrees). This should also give you the full throttle range of all 3 engines, so 2640-6600kN. (A 2 engine hover should also be possible).

Any theories as to why such a big discrepancy between the thrust of the outer 20 and the central 8? Surely thrust vector control wouldn't affect max thrust that much? Is this because they want those central engines to deep throttle for landing, and they don't need deep throttling on the outer 20? Or maybe because they don't want to stress engines that need to relight for landing as hard as the the outer 20? Also welding engine bells together and/or to the skirt worries me. It seems like a recipe for extra stress when the engine bells expand during launch. I hope they get their models right during design, and that this doesn't come back to bite them later.

Assuming 1.3 metre engine bells in contact with each other, I make it a circle of 9.61 metres. That should be the diameter of the circle touching the outside edge of the engine bells, so also add any gap between the engine bells and superheavy's outer skin/skirt, plus the thickness if that outer skin/skirt (if any). (Note it's been a long times since I've done any trig, so take that figure with a grain of salt, especially if someone else disagrees).

I would expect that the thrust puck (and the thrust simulator during tank tests) will need to be significantly heavier to handle the loads for a superheavy with 30+ sea level raptors. Of course they could build a test superheavy with a starship thrust puck for a quick test hop, but I don't really see the point, (unless they are in a rush to build a super heavy for publicity reasons). (Also if super heavy still has 7 gimballed engines in the center, then I would expect that to be a central engine, plus 6 surrounding engines. Shouldn't that arrangement result in a visibly different thrust puck from starship?)

I doubt they would get more customers, since they can always launch in expendable mode and/or use Falcon Heavy if the payload mass is an issue. But 40% more payload mass to GTO might allow them, to co-manifest more payloads, which would save money by reducing costs. (Of course real reuse with cheap refurbishment also reduces costs even more significantly. But a ULA led refurbishment would probably involve a teardown and rebuild, which isn't going to be cheap. And that is before even mentioning the need for a redesigned rocket and all the associated development costs).

If they are concerned by the amount of dust/gravel blasted off the surface during landing, then they might prefer to keep the thrusters as high as practical to allow the exhaust to expand further before it hits the surface. Also since all cargo will be loaded, secured and launched with starship in a vertical orientation, it will make payload design, planning and handling easier if starship also lands vertically.

I'm pretty sure that the screenshot was taken with testflight installed, whereas you said you have TestLite installed. (TestLite is a newer replacement for testflight, and doesn't have the same display). Are you trying to run that engine for more than it's rated burntime? If so by how much, and what settings are you using for testlite?

i haven't looked at KER's code, but the half burn time it should be using is not half the time for the total burn, but the time it will take to do half of the burn's deltaV, ie half of the burn from a dV perspective, rather than a time perspective. So in your example it should be however long it will take to do a 979.56 * 0.5 m/s burn.

@Arco123 Only post a recompile if you actually want to take over maintenance of Kopernicus. Also see https://forum.kerbalspaceprogram.com/index.php?/topic/181547-181-1-kopernicus-kittopiatech/&do=findComment&comment=3729953 for a summary of how to post a recompile that complies with the forum rules.

@Qwarkk @pt1243 I'm not using TACLS atm, but you do realise that food contains water and both carbon and hydrogen, so in reality (for an astronaut that is alive and both eating and drinking), the equation is really food + water + O2 -> waste water + (atmospheric) water vapour + CO2. So the eat, drink, respire, recycle water cycle producing a net amount of water seems reasonable to me.

Well done. Just think how much some rich collector would have paid for such a flag.

A part could run a self test periodically even when disabled.

I wasn't meaning to suggest actually adding kerbal health to an RP-1 install. Instead I was meaning to suggest you want closer integration between Kerbal Health's training mechanic and KCT, then it might be worth looking at how RP-1 achieves the that.

RP-1 also implements training. (I'm pretty sure it somehow prevents untrained astronauts from boarding capsules. It also has its own UI for displaying training status and can optionally add an alarm to KAC. And of course it is fully integrated with KCT).

My understanding is that Ckan should work on a Mac. (But I don't have one to test with). See https://github.com/KSP-CKAN/CKAN/wiki/Installing-CKAN-on-OSX. I'm not aware of a guide to installing RO/RP-1 manually. But it should just be a matter of manually installing the same mods. The tricky bit will be making sure you get the right versions and don't forget any dependencies.

I can't speak for the RO/RP-1 devs, but they can't really start working on a 1.8.1 release until after there is a Kopernicus release for 1.8.1. (Kopernicus is being worked on, and will hopefully release soon. But every time somebody says they think it is almost ready, somebody seems to find a new bug). So my personal and unofficial opinion is don't expect a 1.8.1 RO release anytime soon, and definitely nothing before Kopernicus releases for 1.8.1.

The recommended way is via ckan. Indeed the recommended way to install RO/RP-1 is to follow the install instructions, which uses ckan to install as much as possible. https://github.com/KSP-RO/RP-0/wiki/RO-&-RP-1-Installation-for-1.7.3 . (And I mean really follow those instructions. Over 90% of installation support requests on discord are caused by people not following those instructions).

@KnedlikMCPE A number of exceptions in that KSP.log, but I'm not sure which ones actually matter. (Principia in particular is throwing exceptions during load but I've never used it, so I'm not sure how significant those are). Regarding KCT. Are you sure it is properly installed? From the log, there is no KerbalConstructionTime directory in gamedata. The dll wasn't found either. (You are also appear to be missing ClickThroughBlocker and ToolBar controller, which are two of its dependencies).

The possibility that you might have a valid reason to use 1.3.1 was why i said you should probably be using 1.7.3. If you really want to stay on 1.3.1 then you could download 7-zip. https://www.7-zip.org/download.html . That should be able to unpack the .zip. But be aware that if you have other problems, you probably won't get any support from the RO/RP-1 devs beyond them saying use 1.7.3. (I know that one of the RO devs has already said that the only supported version of RO atm is the version for 1.7.3).

@Drew Kerman That looks like the control surfaces over-reacting rather than aerodynamic turbulence. Turning down control authority might help. Personally I never use moving fins on rockets, and just use engine gimbal for pitch control, and if I need roll control on a single engine stage I add either rcs or vernier thrusters (or in stock use a reaction wheel).