AVaughan

I have played with a i7-860 desktop with HD 5770 graphics (so both 10+ years old) with 12 GB of ram. I have seen other people who get RO to load on systems with 8GB of ram, but with very long load times, probably caused by windows paging.

Real fuels and procedural parts should work together. Proc parts will let you configure tank diameter + length in the VAB/SPH

From memory, Mechjeb -> settings, toggle 'module disabling does not kill throttle'. If I recall correctly, after you have enabled that, disabling ascent manager will leave the throttle in whatever state it was before you engaged the autopilot. So make sure you throttle up before launch (or set ksp to always throttle to 100%). There are also some settings in utilities you might want to toggle. (Prevent unstable ignition, rcs to ullage). Also you probably want to be using mechjeb PVG, and might also want the mechjeb dev version.

I've never seen it myself, but it has been reported occasionally for years in RO/RP-1 threads (and I think I've also seen reports in other planet pack threads). From memory the normal suggested workarounds are things like entering the tracking station, or doing a save/load cycle.

I think an 1.11.2 is unlikely. 1.12.0 is due is roughly 7-8 weeks, so I doubt they will do a 1.11.2. Indeed at the time they announced the quarterly updates they were hoping that with the new process they would be able to reduce the number of updates below 6 per year. See https://forum.kerbalspaceprogram.com/index.php?/topic/178756-ksp-weekly-the-moon-race/&do=findComment&comment=3463071 . My personal opinion is that the only way we will get new updates without new bugs is if they switch to an open beta style of release. They apparently don't have enough automated test coverage to catch all the regressions, and an open beta is the only other way I can think of for a small team to get enough testing of everything in a game as complex as KSP. (Please do consider it Squad, at least for the point releases).

A week or two ago I read something on social media (not sure where, maybe in this thread), that suggested that SpaceX had loaded more fuel in SN8 than they were authorised to. Maybe that is what the FAA was upset about. Personally I'm worried about the downcomers and header tanks. Especially that long downcomer from the nose. Fluid mechanics is complicated. With a fluid that is already close to its boiling point, it might only take a small (potentially localised) pressure drop to cause some of that fluid to potentially boil and create gas bubbles. Turbulent flow in the downcomer or even just sloshing as starship flips might be enough. You also need to consider heat transfer from the downcomer pipes to the fuel. I have no idea how well the downcomers are insulated, but there is probably going to be at least some heat transfer from the support brackets to the downcomer, then to the fuel/oxygen. If the liquid is already at its boiling point, then that means that gas bubbles might form in the downcomers. (If that happens during re-entry, then how do you get those bubbles out before the engines ingest them?) If SpaceX is using superchilled Methalox, then given the short flight duration of the test flights, this might not be an issue atm. But something keeps happening the engines during the flip, and I'm guessing they are ingesting gas. That might be a good idea from a reliability perspective. It might not even be much heavier than the current design. For a theoretical spherical pressure tank, tank mass is actually proportional to volume, (https://en.wikipedia.org/wiki/Pressure_vessel#Spherical_vessel). So 3 small tanks with shorter and simpler plumbing to the engines might not add a significant mass cost. It would mean a higher surface area to volume ratio, which suggests higher heat transfer, which implies more boiloff. (Assuming the header tanks are located within the main tanks, if those tanks are depressurised and hence effectively a vacuum, then the surface area to volume ratio might be mostly insignificant. Thermal transfer via the mounts/pipes might be the dominant concern). I wonder whether carrying more fuel and doing a single engine flip at a higher altitude would allow them to successfully land and hence run more tests per prototype and get better data on how the fuel is behaving (sloshing?) in the tanks and downcomers during the flip. (If needed they could do the flip, then ignite a second engine to decelerate after fuel has stabilised). Plus they probably want to inspect some Raptor engines after a flight. Of course, there is still the issue of whether one engine can provide enough torque to flip in a reasonable time. If they are willing to consider a redesign, then maybe 3 sets of header tanks. One set for each engine. (So 6 header tanks total). If you still do a 2 engine flip, then that gives you a spare engine and header tank/downcomer set, for partial redundancy. It also implies a 50% increase in fuel/header tank mass. Next rearrange the plumping. Dedicated piping between each set of header tanks and their associated engine. Make that piping as short (and straight)as practical. (Although not vertical, because we also want to move the header tanks somewhat dorsal of vertically above their engine). Consider a Starship in the bellyflop position at roughly terminal velocity. At that point the fuel is experiencing roughly one G, directed roughly dorsal. Next consider a Starship that is in the process of executing the flip. Again the fuel is experiencing acceleration from the engines, directly rough aft. So you want the downcomer oriented so that it slopes down from the tank to the engines at all times when in the lower atmosphere. That way any gas bubbles that do form, will rise into the header tank, and not end up trapped in the downcomer. My guess-estimate from this overly simplistic analysis is that you want the downcomer oriented roughly 45 degrees dorsal of vertical. Obviously SpaceX could do a better analysis and design a solution that optimises the ability of any gas bubbles that do form to migrate back into the tanks, baffles to make sure that gas is never sucked into the tank outlet from fluid sloshing around, and good fluid flow rates after ignition. Or a slightly slower average ascent rate, to a lower altitude before the transition to skydiving. (Or a combination of course). They probably don't even care. Most media outlets, only care about page (read ad) views per dollar spent on wages/salaries. So an unresearched but sensational article churned out by someone with zero knowledge in the field is cheaper and faster to write, and will probably earn about as much money as better article that is properly researched. (There are exceptions, but they are generally written by authors who are already knowledgeable in the relevant field and targeted at audiences who are actually want decent information). Maybe more like "because of what happened to the Hindenburg, we shouldn't use hydrogen airships"? Personally I think Starship's flip and propulsive land manoeuvre will be more dangerous than a well designed and tested capsule landing under parachute for many years. (Probably permanently). Sort of like comparing hydrogen filled airships to helium ones. If an engine ingests gas during the flip, then there is a high chance that engine will fail, and if all engines share a common downcomer, then attempting to emergency start another engine risks feeding it the same gas.

Everyone on a boat, and go watch the launch from 5 miles away. (Or whatever distance is considered safe). That will do for the initial testing phase. Long term they probably want a better solution, but for Superheavy's initial test phase, 1 hour or so to evacuate everyone is simpler than trying to design something that would allow the crew on the rig to survive a worst case launch failure.

KSP version? Mod versions? If it is on 1.11 then it sound like it might be

1.11 ? Do you see the same thing in earlier versions? Crewed part? Sounds like it might be https://wiki.kerbalspaceprogram.com/wiki/1.11 mentions a minimum part mass, but my reading of that means it shouldn't affect dV/acceleration. Another possible cause might be whatever function is returning vessel mass is ignoring crew mass or maybe the mass of eva attachable things in crewpods/containers.

Superheavy should be able to hover, so a suicide burn shouldn't be necessary. Assuming adequate fuel reserve, it should be able to gently lower itself into the waiting arms. But yeah I can see them losing a few launch towers trying to get this right. Might make more sense to use a retracting arm launch tower for launch. Then use a specially designed crawler setup with tracks at 4 corners to catch the booster. Can grab Superheavy from 4 sides. Can be designed to withstand lateral and vertical shock loadings. Over engineered to hopefully cope with an imperfect landing. More stable and less likely to tip over in the event of higher than designed loads during an imperfect landing than a tower with an arm sticking out the side. Then use the crawler to move the booster back onto the launch clamps. Can land far enough away that a RUD on landing doesn't damage launch infrastructure. Might take more than 1 hour to get back on launch clamps, but better to build a system that works reliably than lose multiple launch towers struggling to get a more advanced system working. (Once it is working reliably you can reduce turnaround time by landing closer to the launch mount, at the cost of making launch infrastructure vulnerable to damage during a landing failure).

SN9, after its test flight.

I think there are a lot more mature KSP players/forum members than in many other games. One of my earliest memories is of my parents getting me out of bed in the middle of the night to watch a moon landing on TV. I would have been about 2½ during Apollo 11 so it was probably that landing. (That dates me).

What is that max acceleration of Starship + Super heavy? I'm guessing around 30-40m/s2 shortly before separation? What is the load path? My guess is through the skirt, but that is just a guess. What is the acceleration of a fully fuelled and loaded Starship? About 10m/s2 or so isn't it? So the thrust puck only needs to be designed to cope with stresses equal to a fully fuelled and loaded starship at just over 1 gee, whilst if my guesses above are correct, the skirt needs to support a fully fuelled and loaded Starship at around 3-4 gee. Additionally, in the event of a heavy landing, if any damage is confined to the bottom of the skirt, then there is less risk of a fuel leak and subsequent fire than if the thrust puck is deformed or the downcomer is damaged or the bottom of the lox tank is damaged.

Where I live (Australia) land is zoned residential/commercial/industrial etc. Zoning affects council rates, permitted use, and is also relevant when you need approval for development etc. Does a similar thing exist in the USA? Could it be simply that those creek beds are zoned rural, since they are unsuitable for residential/commercial/industrial use? Also politicians tend to vote for proposals that they think will help them get re-elected. So it doesn't matter how badly written a proposal is, if enough rural voters think the proposal is good, then that might be enough to get the appropriate legislation passed, even if it also funds internet in areas nobody lives.

Have you followed the install directions? https://github.com/KSP-RO/RP-0/wiki/RO-&-RP-1-Installation-for-1.8.1

Because of the way Squad choose to simulates the physics of individual parts (including the values they choose for stiffness and damping of joints. If you made the same choices in Unreal engine, I expect you would get similar results). I expect they decided that bending/flexing rockets add to the comedic appeal of the game, the same as waddling Kerbals, and so didn't want to change the physics simulation. So in my opinion the Kraken is probably the result of choice made by KSP's developers. You keep pointing to the flaws in KSP/Unity games in general, and using that to claim that Unity is bad. I think in many cases a lot of the blame for poor graphics in Unity games is simply because it is used by a lot of small, inexperienced game developers. Small inexperienced game developers are going to struggle to make top quality graphics regardless of which engine they choose because they lack the time, money and experience of larger more experience teams. That is the way life works, and not a reason to blaming the game engine those smaller developers choose. (Also remember that the initial release of KSP was back in June 2011. You should expect that the sequel will have updated graphics).

3 flights a day for starship on a regular basis doesn't seem plausible to me, at least until they get more launch/landing sites (or alternatively an equatorial launch/landing site). Just think about orbital inclinations and their existing launch/landing sites. Once you launch starship, and it achieves its mission, how long will it need to wait for its orbital track to pass over its intended landing site? Then once it lands, cools down, gets a cargo, and is mated to superheavy, how long do they need to wait for the launch site to pass under a target orbit again? Regularly having even one vessel do all that 3 times a day from their existing launch/landing sites? That doesn't seem likely to me. I can see them being able to get starship back on the pad and waiting a launch window in under 8 hours (especially for tanker flights), but starships performing 3 orbital flights a day on a regular basis seems unlikely, at least without a lot more launch/landing sites or alternatively an equatorial launch landing site (and zero inclination target orbits). If they get enough missions happening, then flying the same booster 3 times a day is more reasonable, but even there if you have that many flights happening on a regualr basis you need some spare boosters simply so that if on does have issues/needs maintenance, you can simply slot in another available booster without affecting flight cadence. At which point I would have expected them to be rotating the boosters anyway. (eg if you are launching 3 flights a day from Boca Chica I would expect them to have 4+ boosters sharing the launch duties, and so that they can take one or even two out of the roster for maintenance without affecting scheduled missions). If point to point suborbital missions actually happen, then 3 suborbital flights a day for the same starships is more reasonable.

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 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?)