OHara

RemoteTech (with the delay option enabled) implements signal delay between probes and KSC or the nearest manned "Command Station". RemoteTech does allow the player to control Kerbals in the Command Station or elsewhere, as if by instant telepathic communication. If KSP2 has probes automatically execute maneuver nodes, maybe that could enable signal delay to work with a reasonably simple user interface. We could set/cancel maneuver nodes only a signal-delay or further in the probe's future. But then probes could only land by parachute/aero/lithobraking unless there is a system for programming them. Has anyone used KSP1 RemoteTech's signal-delay option, or seen posts from players who have explained how they get things done using it?

There is a natural place in that gap that KSP2 might have chosen: let the planets and moons feel gravity of the single parent body only, in Kepler orbits 'on rails', but let our craft feel gravity of all nearby(*) celestial bodies. That would seem to let players do the interesting things, like park craft near Lagrange points and play with tidal forces on orbits, without any worries about the orbits of planets being unstable. (*)I suspect the criteria for 'nearby' might be rather strict, maybe only Rask and Rusk, so that satellites in low-Kerbin orbit are not perturbed by the gravity of Mun. Or maybe not. It is not obvious to me whether very weak effects of far away celestial bodies would be interesting or just frustrating.

by default, the Δv indicators in the VAB show the results you would get in atmosphere. The nuclear engine does not work very well in atmosphere. You can press the Δv button and select 'vacuum'.

I was also unable to get that aircraft to take off. Before taking off, an aircraft needs to rotate the nose up a few degrees (unless it already is raised by the landing gear) but the I couldn't do that with the elevators trimmed (alt-X) fully pitch-up. There just isn't enough lever arm to the main landing gear for the elevators lever up the mass of the craft. At 100 m/s (223.604 miles per hour) the wheels start to shimmy. If I move the landing gear forward, closer to the centre of mass, then I have enough lever arm (barely). So probably try more of these adjustments, going further than I did. Sometimes it is nice to rotating the wings up a little (giving them angle of incidence) or rotate the rear stabilisers down, until the centre of lift is right above the centre of mass. CoL behind CoM is good advice for beginners, to make the aircraft stable, but once you know it is stable you can adjust to make it easier to fly. and also real aircraft (wheel-barrowing) .

and you do not need to do that rescue right away. The game KSP made Kerbals perfectly happy to sit in space for long periods of time, so you can + rendezvous to get the 'Science' and leave the Kerbal there, or + repeat the mission with another Kerbal, repairing any mistakes so it succeeds, using quick-saves to re-try as many times as you like, + do different missions to build up Science, until you can build a bigger craft to bring that Kerbal home.

True. Turning the rocket about 45° from vertical on the way up is the only way to survive this tutorial. When you build a rocket in the VAB you have the option to reduce the thrust on a booster, so it burns slower (but usually you want them at full thrust or just use a smaller one). In the tutorial where they built it for you, you do not have that choice. A few other tutorials have bad instructions. I made a list here that I think has all the problems; at leas no-one has corrected me yet

KSP1 provided some helpful options, for people using regular computers, as opposed to gaming PCs. I hope KSP2 does similarly. I use a laptop that I bought in 2016, which is the only time I ever bought any more than the integrated graphics : CPU i7-6500U at 2.5 GHz GPU AMD R7 M360, 2 GB memory and with this I turn most graphics settings down, but keep shadows to help in landings, and use Environmental Visual Enhancements with a simple configuration file to give me clouds to help with situational awareness. This laptop performs better with KSP 1.10 than it did with 1.0, maybe due to streamlining in KSP or maybe in Unity. (For example, KSP 1.0 would often miss key-up events, so if I pressed the key to rotate the view it would oven continue rotating after I released the key. I learned to make extra keypresses as a workaround.) One setting useful to people with slower GPUs and faster CPUs is: Maximum physics delta-time per frame: 0.1 second of Kerbal-time (default is 0.04) It is explained at length here, but I think of it the other way around, 10 fps rather than 0.1 s: "let the GPU go as slow aa 10fps without making the CPU and physics simulation wait on the GPU." My frame-rate drops when the ocean is in view (which doesn't bother me much) but with the default setting, the physics simulation slows (indicated by the yellow clock) which bothers me more. Allowing more time to pass between display-frames keeps the physics smooth even when my GPU struggles. It is also nice to have the option to reduce the resolution in KSP. I use 1900×1080 for work, when I'm slowly poring over details, but don't need that to play a game, so I use 1600×900 for KSP. (Unfortunately, either KSP or Unity or Windows10 intermittently resets the resolution to whatever Windows10 uses, so I try to remember to change the resolution in Windows before starting KSP.)

Don't ask me; I looked for an explanation but couldn't find any. Since I get reasonable behaviour in 1.11.1 with a similar pod, maybe there is something special about yours that you can find,. Maybe one of FleshJeb's ideas above leads you to the cause. The shield might be offset up so that the pod peeks through (KSP gives you some margin here). Maybe you attached it inverted, and then rotated it, fooling simple KSP into thinking the pod is connected to the ablator side. Maybe your later trajectory spends much longer in the upper atmosphere than I was able to do. The Kerbalism mod has considered requiring a 0°-40° (270K--320K or so) for manned pod interiors, which would be difficult to maintain during re-entry, but I don't think they ever added this to the mod. Maybe some mod (like my old mod that I linked above) has made the pod overhang the heat shield slightly.

The answer to the top-post question is, no, they did not change re-entry heat, anytime since 1.2. At least not on purpose. There was a bug in 1.8.0, for example, where lots of parts lost most of their drag, so different parts would overheat than before; they repaired that in 1.8.1. The images in the top post show the stock cabinet icon, but not the alarm clock, so I guess those images are from version 1.11. For me, in stock KSP, the heat shield barely survives a 7km/s re-entry of the 3-kerbal pod. I don't use ablator because it doesn't help much; the T4 radiative cooling of a 3300K heatshield (hotter than incandescent light bulbs) is enough to cool it. If you stay perfectly retrograde, the capsule is completely protected. A small imbalance that tilts the craft would let a bit of the capsule feel compression heating, and in KSP if part of the skin overheats the whole part gets the warning thermometer and is destroyed. The skin of the pod has a 2400K temperature limit. I posted a patch once to make the mk1-3 pod fit the other 1.25-m parts at its top node, and this patch causes some of the pod extend beyond the heat shield, and feel some heating. Maybe some other mod does similarly.

True, I wasn't quick enough to point the capsule retrograde, and the capsule interior reached 322K in version 1.3.1 and 344K in 1.7.3. I should have set SAS retrograde just before entering the atmosphere, and made that the quicksave to try across versions. Having bit of recent practice, I did better and kept it to 318K in 1.10.1 and 314K in 1.12.1. The pod stayed cooler in later versions, but only because of my different flying, which difference I wasn't considering significant. I also forgot about the Mk1-2 getting auto-upgraded to Mk1-3 in version 1.4, which decreased its mass, and thus its thermal mass. If the heat-shield weren't so well insulated, the Mk1-3 would heat up faster than the old pod of that size. All the images in the original post, though, show the Mk1-3 pod and version 1.11 or later, so maybe version 1.11 had a bug with heat. Off topic, in hindsight, I like the thermal model that KSP had before the ISRU and 'core heat'. Even the pre-core-heat model was a bit complicated a little mysterious to me as a new player. If we had different temperature gauges showing which temperature is getting dangerous, maybe vertical thermometers for internal temperature, horizontal for skin temperature, that might have been enough to make it transparent. The distinction between skin and internals, and different thermal conductivities, seems to be enough to make radiators do their special job. Most parts have good insulation between skin and internals, except radiators have a good thermal link between skin, internals, and the internals of their parent part. So maybe that was just complicated enough to enable all the interesting behaviour. I never learned the rules about which parts are cooled by the various radiators, or about core heat regarding the ISRU system, so I ignored that part of the game.

I have old versions sitting around so I thought I would compare (Imgur album link) but I couldn't see any significant difference between versions.

There was a thread recently about which recent version of KSP is the best one to keep I chose version 1.10.1

There is something wrong with the KSP 1.12 Alarm Clock => Transfer Window setter --- or at least none of us can figure out how to use it reliably (thread link) I get KSP 1.12 Alarm Clock Kerbin->Eve Year 1 Day 113 Eve->Kerbin Year 2 Day 139 if I try it on Year-1 Day-1 Kerbin->Eve Year 1 Day 336 Eve->Kerbin Year 2 Day 140 if I try several days later KSP 1.12 Maneuver Tool Kerbin->Eve Year 2 Day 158 Eve->Kerbin Year 2 Day 90 alexmoon.gitup.io/ksp/ using 'ballistic' without a plane-change burn, as Maneuver Tool does Kerbin->Eve Year 2 Day 160 Eve->Kerbin Year 2 Day 90 or with a longer window, Eve->Kerbin Year 2 Day 195 is a bit more efficient. The ballistic transfers, using no mid-course plane-change, tend to have locally minimum delta-V solutions on either side of the window (because getting directly into a transfer-orbit plane that intersects planet-orbit planes with different inclination, is very expensive if the intersections are close to 180° apart.) Someone posted on the bug tracker that it is "just backwards" because the Alarm Clock date given for Eve->Kerbin is a reasonable time for Kerbin->Eve, but that is just how transfer windows work: You leave the starting planet half a transfer-time before a conjunction between the two planets; the conjunction time relates to the pair of planets, and the transfer-time is the same either way. The online planner still works fine, and the mod Planning Node gives a more visual method that is very much in the style of KSP

The alarms in the screenshot were set from the built-in Alarm Clock, which for some reason sets an alarm 20--30 days before the ideal transfer (thread link). The online tool at https://alexmoon.github.io/ksp/#/Kerbin/100/Duna/100/false/optimal/false/1/1 still works great. The first minimum-delta-V transfer is on day 231, so @terrendos has 40 days to wait, so probably easier to set a new node. Leaving at the time in the image, it might cost another 200 m/s from low Kerbin orbit to get into a higher-energy transfer to catch up to Duna. Doing that in a mid-course manuever would cost even more, as you say.

It is not likely that the thread-starter is still adjudicating points after nearly five years (and they also started the very popular "what did you do to day in KSP" thread must get a flood of response notifications there) but the rest of us reading will still appreciate seeing a minimized craft. I'm thinking Mojo being so close to the sun might be enough motivation to be patient and use ion engines.

One way of implementing saturable reaction wheels, is to build them with rotating masses, and connect them to controls so that they stop rotating when the user releases the pitch/yaw/roll command. (KerbalX link) The saturation never becomes a problem because the control hook-up does not leave any rotation in the wheels that might accumulate to eventually saturate the capability of the wheel. They are also easier to use for orienting a probe or pod, because rotation stops when the control-input stops. The mod Ferram Aerodynamic Research has a nice way of generalising the inputs to control surfaces. If you select a button in the right-click menu of a control surface, you see sliders to determine how much, and in what direction, that control surface should respond to pitch, yaw and roll. The picture at right shows an airplane where the rudder responds to roll commands enough to perform what they call 'coordinated turns'.

The tutorials are possible to complete, by following their instructions, in version 1.7.3. Based on when the bugs were reported with the tutorials, it looks like the bugs appeared in version 1.12 There is a thread about which KSP version is the best.

Work has stopped on KSP, so it is up to the players to repair the tutorials. I don't see a way to repair them through modding, myself. There are workarounds, including the one @Blaarkies alluded to. 1 Basic Construction 2 Flight Basics Problem: Since version 1.12 if you follow the instructions exactly, the parachute is ripped off during descent Workaround: Steer to tilt the craft 45° off vertical during the thrust portion, so you are not so fast when you re-enter the atmosphere 3 Intermediate Construction Problem: Since version 1.12, the Hopper craft is not found in the VAB craft loading menu Workaround: Place a pod and parachute on top Problem: Since version 1.12, the Swivel engine is not found on the left side of the VAB Workaround: Click on the " <<||" at the upper left to open the other sorting methods. Find the swivel under Filter by Technology Level, ②, LVT-45 Swivel. 4 Suborbital Flight 5 Advanced Construction Problem: The Swivel engine is not found on the left side of the VAB Workaround: Same as in Tutorial 3, using one of the advanced sorting categories to find the Swivel engine 6 Go for Orbit Problem: Since version 1.12 if you follow the instructions, the training fails with "off course" Workaround: After you drop the sustainer stage at 30km altitude, the instructions say "Upper stage lit. Go to map view". Notice that the upper stage is not yet lit. Hit the staging key again to light the upper stage, before you go to map view. 7 Orbiting 101 8 Science 9 to the Mun 1 10 to the Mun 2 11 from the Mun 12 Docking 13 Asteroid 1 14 Asteroid 2

The plan in 2019 was to integrate thrust (under "automation") and continue rotation ("persistent rotation") during time-warp and when focused on another craft: The realistic possibility of thrusting while rotating would, I think, frustrate new players so much that I doubt KSP2 implements that. I guess they will implement at least a constant thrust holding a constant direction. Maybe they will implement thrust while holding prograde, although in this case they might need to auto-zero the thrust upon SOI changes. I don't want to worry in advance about exploits, like tricking KSP2 to hold prograde during time-warp on a craft with insufficient control authority, because now is the time for the KSP2 developers to handle those worries. The way time-warp freezes rotation in KSP1 is a little un-fun. When I was a new player it was very difficult to stop rotation in early career without SAS, so a quick time-warp is a tempting cheat that makes the player feel guilty. Better to have rotation-damping SAS come earlier in the game, I think. More complicated loopholes, like maybe holding thrust orientation despite insufficient battery power, might not be worth preventing. When KSP1 tries to enforce rules about sufficient power and cooling for its ISRU systems, I suspect it does so wrongly, or maybe I don't understand the rules, resulting in my simply cheating my ore tanks full because the ISRU maintenance mini-game is no fun for me.

The sun is still 100× brighter when seen from Pluto, than a full mon is from here (5 steps difference in apparent magnitude) according to the numbers at wikipedia (which look right to me.) But on a journey between here an alpha-Centauri, the sun will dim until it looks like just another star. The interstellar aspect of KSP 2 might have prompted the developers to simulate some of the varying brightness of stars and all the other things in view.

Maybe you are noticing what was partially explained here: If that is not what you are talking about, maybe it is something discussed here:

Very early (2019) KSP 2 gameplay showed a bendy rocket (youtube link) but I have not seen any bending in later examples (youtube link). I think the idea in KSP 1 was, if it is easy for rockets to fail, then making a successful rocket is an achievement. Two ways that real rockets break up are aerodynamic wobble, and pogo-stick bouncing (but pogo-ing of fuel in tanks rather than tanks against each other). They may have wanted to give players some indication of what was going wrong with a rocket, before it explodes, so players know what to make stronger or what forces to balance. Making the joints bend a lot before breaking would be a way to show what is going wrong early. But probably KSP 1 made the joints bend too much. I like KSP 1's regular struts, because I can see what they are doing. Autostruts are okay for when you cannot connect a regular strut, but they feel like a cheat and have an awkward UI. For more flexible placement of struts, I like the UI of the quantum struts mod, and of the EVA struts mod. (The new versions of KSP 1 might let EVA Kerbals connect struts, but I haven't tried the new version yet.)

For my VTOLs, gimbal does not help with attitude control, because the gimballing engines tend to be close to the centre of mass. Even when the engines are spread out, mine tend to be spread horizontally, at the same vertical height as the centre of mass, so that even if an engine rotates on its gimbal it still provides the same torque trying to turn the craft. Threads on VTOLs (link link) tend to suggest other ways to control attitude, like RCS or the mod throttle-controlled avionics. The more recent versions of KSP let you connect the 'thrust limit' of an engine to 'Axis Groups' including the steering axes. (The SAS control, however, only steers with the hardwired steering controls, not the ones you connect using the axis-group feature.) That being said, if some engines gimbal opposite the way you want, you can set Pause Menu => Settings => Advanced Tweakables : Enabled and then manually edit under the right-click menus for each engine to selectively disable whichever of the pitch/yaw/roll responses are not what you want.

That seems like sound logic to me. Nuclei with a proton/neutron ratio much higher than the stable line will happily toss out a proton. Probably @Lo.M meant something else by "Helium-2", (possibly He2 as a molecule?) or maybe mistyped.

Well, we might first wonder how you got your camera to Europa! Oh. Space Engine 0.9.8.0 Space Engine with that option enabled shows the brightness of illumination fade as we get further from the star, and then the illumination from alpha-Centauri get brighter as we approach it. That might be nice for KSP2, but might risk disorienting players, depending on how it is implemented. I notice that Space Engine's default settings give a less-realistic but easier-to-understand rendering. That version of Space Engine has some quirks in its auto-brightness. If the closest star (a.k.a. the sun) is in view the other stars are dimmed, but the planets are not. (With auto-brightness off, the default, the stars are always brighter than in the images above.) They changed this whole system in 0.99 when they moved releases to Steam. You game me an excuse to do more math. The bright bulge in the Milky May is apparent magnitude 20 per square arc-second, 0.001 lm/m²/sr. Jupiter is illuminated with 3000 lm/m², so if it Lambert-style scatters 50% over π solid angle, it has luminance 500  lm/m²/sr. I can see how the brightest stars (8 lm/m²/sr if blurred into a typical pixel or human photoreceptor) could be seen with Jupiter in view, but I would have to spend time blocking Jupiter and dark-adapting before I could expect to see the Milky Way.