OHara

What I've read (here, so same as you've read) does suggest that reaching off-Kerbin resources will be what 'unlocks' technologies and opens up design-constraints, rather than a Civilization-style technology tree. The 'Science' system, though, might involve collecting information that we use in the game. In KSP1 the best example is the mod ScanSat, where you need to launch a scanner in an orbit capable of covering the interesting parts of a planet, in order to get an in-game map of the planet. Such maps are required for landing on Eve if you have a mod producing clouds, as KSP2 has natively. ScanSat has players do something useful for their game-progression using the core mechanics of the game (putting things in orbits). Players here have suggested other ways to make 'Science' make sense in KSP: requiring us to send up rockets carrying barometers before we have access to high-altitude jet engines, applying the 'experience points' to the parts rather than Kerbals and unlocking the next parts in the tree once we have enough experience with the existing parts. But, I don't know of any specific mods that use these ideas. Myself, I played only one Career-mode game because I never learned the rules covering the tech tree. I liked having to design within constraints, but whenever the constraints made little sense (ladders come surprisingly late) or when I was ready to move on to new parts, I relearned the unlocking rules from forum searches and didn't enjoy that part of KSP1 very much.

I remember KSP's advertising videos used Spanish phrases, with the recording tape reversed, for Kerbal speech. I convinced myself that KSP2's countdown is this same kind of reversed Spanish, but I'm not sure about the other radio chatter. The sounds of language sound very different in reverse, not how one would pronounce the word spelled in reverse. Can any native speakers confirm? Is there anything interesting in the radio chatter? (I would not guess anything here could be a spoiler you could use a spoiler block if it is.)

Git is a good analogy. `Git merge` highlights conflicts between branches, and helps the user to resolve those conflicts (analogously to what you suggest just above). In discussions of multiplayer with time-warp, people often use the term 'paradoxes' to describe conflicts between timelines that evolved independently when want results from both timelines saved in the same save-game. The mods Luna Multiplayer and FMRS resolve conflicts in simplistic ways, which doesn't bother users of the mod because they generally don't create conflicting timelines. In FMRS, we often launch a 2-stage rocket from Kerbin, put the second stage in orbit, then jump back in time to land the booster. If I wanted to be evil, instead of landing the booster I could use its remaining fuel to crash into the second stage and destroy it before it gets a chance to reach orbit. FMRS has to resolve the conflicting timelines: is second stage destroyed or not? (For this case, the second stage is restored in orbit when I return-to-space-centre after the crash, but maybe other cases force FMRS to resolve in a different way.)

I assumed the idea was that a game about building rockets should have ways for rockets to fail. Joints of limited strength between parts was a simple yet general system that gave a risk of failure on the typical rocket at 'max-Q' (maximum dynamic aerodynamic pressure) and the bending of joints gave some warning of what joint was at risk of failure. The system mostly worked for me, in that I enjoyed building craft under those rules. The original struts let us make loop connections so we could have structural frames. In my experience those struts made the strut-linked parts move as one, constraining all relative degrees of freedom, for purposes of the mechanics simulation. I'm not sure if strut-joining parts reduces CPU load, but I can imagine it may, or at least that it could have reduced it. (I was also lucky in that I used the laptop that I retired from my work, whose CPU easily handled the physics aspects of high part-count craft. ) Simulating individual parts allowed us to build various creative mechanisms ('krakentech') and propeller-driven craft before the robotics DLC. Maybe KSP2 has a more general way to let us mechanically merge parts and make loop connections. We'll see.

Pencil and paper work nicely. Most of it is text, so some way to edit free-form text stored in association with each command pod, would be nice. For understanding experimentally what the delta-V map and pork-chop plots mean,

FAR itself doesn't try to estimate the performance of wings based on their shape; it has numbers in the file FerramAerospaceResearch.cfg for each type of wing or control surface to describe its aerodynamics. I looked through the code a couple years ago to try to understand why. The analysis of the whole-body shape of the craft is too coarse to notice the critical details of a wing, such as the blunt forward edge and sharp trailing edge, that give it so much lift. Wings and control surfaces are largely computed separately from the fuselage. A control surface buried inside the fuselage will still steer the aircraft in FAR. FAR doesn't do a low-level physics simulation, but uses heuristics developed by aeronautical engineering, so it does a good job on craft shaped like normal aircraft and rockets. KSP1 does automatic computation of aerodynamic properties of each non-wing part, including parts from modders who provide no aerodynamic information, and caches the results in PhysicsDatabase.cfg. Then has rules for cancelling some of the drag when you attach two parts. So many people use stock KSP1 for things like challenges, that we ended up learning and sometimes gaming those rules. I would rather if KSP encourages use to learn more real aerodynamics, than the rules of a video game. In hindsight, I think it would have been better if KSP1 took the whole-craft approach of FAR (re-computing every time you eject a stage or un-dock something). I hope KSP2 was able to take advantage of the benefits of hindsight. It might not have been easy. We'll see soon enough. There are aspects of KSP1 stock aerodynamics that make the game easier than with FAR. Lift and drag unrealistically increase at low speeds, allowing our spaceplanes to take off and land on a 2.2km runway without extreme measures. The stall of wings is very soft and forgiving. These adjustments affect curves defined in *.cfg files, so KSP1 players (using computers) can restore realistic low-speed flight with configuration-file changes. I would think that if KSP2 was able to implement more realistic aerodynamics, they could adjust the lift-versus-speed curves in a similar way, to make a playable game.

I would guess KSP2 will plan slow-burn manoeuvres by assuming the craft will rotate during the burn to follow the prograde/normal/radial directions. Principia does this. Very-low-thrust craft that raise their orbits in a long spiral would need to point continuously prograde. A planner that has the burn follow prograde would help to plan such spirals. The other choice could also work well: planning under the assumption that long burns follow a fixed direction in space, and giving us a pointer to that direction analogous to in KSP1. Plane changes are more efficient if you burn while pointing in a fixed direction, rather than always follow the rotating normal vector as your orbit rotates. I would guess that KSP2 will "always simulate non-impulsively" for the sake of simpler UI. To figure the results of an extended-burn, KSP2 will need to know what throttle level we plan to use, but it may just assume full throttle and let us thrust-limit the engine when we need different. The extended-burn calculation naturally converges to the 'single-impulse' approximation when the burn is short enough.

Real helicopters are unstable. If any gust tips one off of vertical, it starts to drift sideways and then swings back and forth in oscillations that grow. 'Dynamically unstable' is the term. Quad copter drones use differential pitch to get differential thrust on the four rotors. This can be done in KSP but is not very convenient. KSP version 1.9 and later let you enable pitch, yaw, and roll, control on the propeller blades, which makes them change their angle of attack as they rotate, giving more lift on one side of the disk than the other (like the cyclic control on a helicopter). This is easier to use in KSP because pitch yaw and roll are controlled by SAS. With four small rotors, the differential lift won't have as much lever arm as differential thrust, but it might still be plenty to stabilize your lifter.

I learned arithmetic in the US in the 1970s, never saw the acronym 'PEMDAS', but was taught effectively P, E, MD, AS where ×÷ share the same priority, computed left-to-right. Nevertheless, when I see the implied multiplication 1/AB, I understand it to mean 1/(AB). In compound units with a product dot in the denominator, like Wb/A·m or W/m·K, I understand Weber per (Amp-metre) and Watt per (metre-Kelvin), as if multiplication was higher priority than division in that situation. I suppose humanity could decide on a convention to take P,E,M,D,A,S literally, but I don't recommend it because: Calculators and programming languages tend to group ×÷ in the same priority, done left to right, and likewise +− . P,E,M,D,A,S taken literally would give 1 − 2 + 3 = −4

The efficiency in terms of thrust per fuel-burn (the ISP) is constant for KSP engines (wiki link). I suppose the idea is that when the ramjet catches more air, proportionally more fuel is burned. So that means you are looking for the conditions to give you the best speed per thrust, which in cruise is the same as speed per drag. The attitude (pitch) for lowest drag in level flight is called the best-L/D angle (best lift / drag). This angle of attack also gives you the best glide ratio, so you can find it experimentally by finding the pitch that lets you glide the furthest with engines off. For typical KSP aircraft this attitude has the nose pointing near the top of the prograde marker. At low altitudes, the best-L/D speed is pretty slow. At higher altitudes, the best L/D angle relative to prograde stays fairly constant until you near the speed of sound, at which point you need to point a bit closer to prograde to reduce the extra parasitic drag (as modelled by KSP). Then to make drag as low as possible to climb as high as you can to the thinner air, until you find you need to pitch up further than best L/D angle just to stay aloft. If That generally means to fly near the ceiling altitude of the aircraft, full throttle. A good fuel-per-distance design would have enough wing area that you are below the speed of sound in this configuration, to avoid the extra drag at and above the speed of sound. There have been some fuel-efficiency challenges (link link link) but none I can see specific to the Whiplash engine.

One well-regarded series is this one. It uses older versions of KSP so the user interface will be slightly different to what you have, but the ideas are all the same. One change with newer versions, experiment storage containers, gives you another option for carrying 'science results' back home, so you might look at that on the wiki and decide if you want to use it as you follow the tutorials made before it was in the game.

This suggestion was made to the KSP2 developers early along, so they probably at least considered making a more flexible attachment system. Given what KSP1 does with struts and docking ports, I think the User Interface is the trickiest part of making a non-tree structure KSP. Any system that has the user place a parts one at a time on an existing craft gives a singly-connected (tree) structure: the new part is connected to the single part on which it was placed. 1) The ReCoupler mod automatically connects nodes that are within 10cm (adjustable) of each other, and uses colour-coded highlighting to show the user what is going on. 2) Stock KSP1 lets us connect struts between parts. These count as extra parts, even though they don't move independently of their parent. They automatically disconnect if decoupling leaves them as the final joint between parts (which is usually convenient, but not always). If we could also make a "weld" between two parts, that would not disconnect, that would have allowed more natural construction of ring structures. Slightly off-topic, the mod QuantumStruts gave a nice variant of the KSP1 struts, which automatically (re)connected upon docking. The same behaviour could be re-imagined as a mechanical (not quantum) mechanism to help us build more rigid space stations.

I believe your expectation is correct. I don't think anything outside the sola system other than stars are bright enough to for human eyes to see in colour. A telescope can collect a lot of light with its big collecting lens or mirror, and send it all through the pupil of an eye, but there is a rule in optics that demagnifying the aperture always comes with magnifying the image by the same factor. So the extra collected light from a nebula is spread over more the human retina, resulting in the same too-weak intensity on each of our colour-sensitive cones. No way to perceive the colour of nebulae with our eyes in real-time; we need long exposures on film or image sensors. The Trapezium part of M42 is near some young bright stars, which I assume are hiding the background starfield in zoomed-in images of those bright stars and nebula. And that silhouette image seems to represent a craft painted a very flat black (or rendered with an inappropriate ambient light setting). The sum of far-away stars does of course produce ambient light in interstellar space (lighting the nebulae, for example). While not having been in interstellar space personally, I would expect a white craft to be look nearly as bright in that ambient light, as a blurred average of the stars in its background. If there was a mirror on the craft, I would see the starfield behind me in that mirror, which on average is as bright as the starfield in the background of the craft. If the mirror is frosted, the starfield is blurred, so I see uniform illumination in the mirror with the same average brightness. If we have white paint instead of a frosted mirror, that paint scatters probably only 80% of the ambient light, so I expect the craft would be a bit dimmer than the average of the starfield in the background.

For each of the mods mentioned in the original post, I know I've seen some version of the mod that will work with any given version of KSP since 1.73. There is also an old thread with discussion on this topic -- after 1.12 was released so recent enough to be relevant.

Felipe Falanghe, who started the game, wrote the main theme. The credits are in the readme.txt: KSP Main Theme: Written by Felipe Falanghe Arranged by Víctor Machado Stratejazz: Written & arranged by Felipe Falanghe Other Tracks: Arcadia, Bathed in the Light, Brittle Rille, Dreamy Flashback, Frost Waltz, Frost Waltz (Alternate), Frozen Star, Groovy Grove, Impact Lento, Wizardtorium Written by Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 Additional Music: Víctor Machado

Yes, the off-by-one bug in the days and years has been there since the manoeuvre editor was introduced.

Well, conceptually the radius of the SOI is related to the central mass, but in the implementation there are separate parameters sphereOfInfluence and gravParameter to express the central mass. (I don't think anyone has set those parameters independently using Kopernicus, so maybe KSP1 computes sphereOfInfluence based on gravParameter behind the scenes.) Someone could program a game to check if a craft is inside an arbitrarily large SoI, and then when it is time to calculate Kepler orbits, apply gravParameter=0, so the potential energy is a flat plateau inside the SoI, and the Kepler orbits degenerate into straight lines in a frame of reference moving with the SoI. Someone else mentioned a harmonic potential, like a linear spring pulling toward the centre of the SoI, so the force gets weaker as you get closer, which also has orbital shapes that you can write out with sines and cosines. I would not guess that either of these SoI solutions would add to the fun of a game. With KSP1 and Principia, I enjoyed trying to get a craft to pseudo-orbit the L4 point, mostly because that pseudo-orbit is so strange. I never considered placing something in an orbit identical to Mun's but 60° advanced and calling that 'L4'. So I agree that Lagrange points require N-body gravitation. Only our craft need to feel gravity from N bodies at once (so the "restricted N-body problem" you referenced). And to play with Lagrange points, and experience other complicated motions around Rask & Rusk, our craft need only feel gravity from N=2 planets at once.

If you want to make them work like aircraft airbrakes, use the orientation your second picture. Actuators don't fail in KSP, but the way that part looks it is easy to imagine the actuator failing, so you might be more comfortable if the airbrakes look like they would retract if they fail. Or, in your case you might prefer them to stay deployed if they fail so might want them in the orientation in your first picture. The orientation makes very little difference in their drag, as implemented in KSP, for this particular part.

The wiki (link) says that the [Option] key serves this role on a Mac keyboard. I can imagine it might be right-Shift (which KSP can distinguishe from left-Shift) if using non-mac keyboard on MacOS

Sorry to see that no-one has recognized the problem yet. Telling us the version of KSP and operating system (Linux, MacOS, etc) might help someone here recognize it. There is a text file "KSP.log" written in the directory where KSP.exe is, and that file might show an error message at the end that. The bug-reporting guide has instructions on where to find another copy of that log file, that sometimes has a few more lines in it : https://forum.kerbalspaceprogram.com/index.php?/topic/83213-stock-support-bug-reporting-guide/

The settings screen does show an apostrophe, with the default settings for an English-language keyboard, but that is a lie. The default key to reset the focus in map mode, is actually ` back quote at the upper left of the keyboard.

There is a suspicious, and very difficult-to-parse, entry in the changelog: * Fix Ap and Pe markers appearing in future patches in space not aligned to current patch rendering when in career games that have yet to have patched conics available. I remember that I depended on switching to map view to see the apoapsis, in order to learn how to get into orbit in KSP. Just to let the OP know, many players here recommend that new players start in "Sandbox" "Science" mode. "Career" mode makes the early game difficult -- and difficult in a not-fun way, when you are still learning the game.

That makes sense to me. The flats could easily be salt flats, left behind from an evaporated ocean. Maybe instead of sodium chloride, the 'salt' could be menthol to fit with some of the EVA reports referencing mint ice cream (or some in-game text; I cannot remember exactly where mint ice-cream was mentioned). There are a few reasonable possibilities, though. The people developing the follow-on game, KSP2, talked about Minmus having been hotter, and the flats being molten and then solidified rock. We talked about the possibilities here (thread link) The one thing that doesn't seem to make sense is simple water ice in the flats, because water-ice evaporates, and Minmus' gravity is to weak to trap the evaporated vapour, so ice flats would not last very long.

Between version 1.8.0 and 1.8.1, KSP stopped protecting separate craft in fairings and cargo bays. Kerbals seated in a command seat inside a cargo bay are protected (as seated Kerbals are not independent craft) and that can be a lightweight solution, if your challenge allows command seats.

KSP1 has the capability for option 3 in the top post, thrust profiles. No stock SRBs use them, but players have written configuration files to do so (link link). The interact in the simplest possible way with the fuel-fraction and thrust-limiter sliders in KSP1. The thrust-limiter reduces thrust by the requested fraction across the whole burn. The fuel-fraction acts as if the booster was loaded with fuel in the same pattern as it has when fuel has burned to that level. The interface is a bit awkward because it works in terms of fuel remaining, so you type the curve in reverse order. I like this profile, similar to picture '3' in the top post, for limiting the g-forces late in the booster phase: @PART[*]:HAS[@MODULE[ModuleEngine*]:HAS[@PROPELLANT[SolidFuel]]] { @MODULE[ModuleEngine*] { %useThrustCurve = true %flameoutBar = 0 %thrustCurve { key = 0.00 0.4 0.0 1.2 key = 0.60 1.0 0.0 0.0 key = 0.98 1.0 0.0 0.0 key = 1.00 0.5 -40 0.0 } } }