Cailean_556

With the requirements for KSP2 being somewhat out of reach for some people - quite a percentage, according to Steam - why not bring a little update to KSP1? The team have obviously demonstrated they can, as they added the partially uncovered Mun Arch, so it's not outside the realms of possibility. I'm not talking about adding everything KSP2 has but adding some of the parts and changing/modifying some of the values. Example changes: -Change "Liquid Fuel" for rockets to "CH4". -Change/Add "Liquid Fuel" for jets to "Methane". -Change/Add "Liquid Fuel" for the NERV to "Hydrogen". -Add the cylindrical Hydrogen tanks. -Add the SWERV, or a "SWERV-like" engine. -Add the larger solar panels. -Change the ISRUs to be able to make CH4/Methane/Hydrogen. -Add hints of the other anomalies in KSP2 to their KSP1 equivalents (partially uncovered/hidden versions). While this may sound like a small update with very little effort (that's also kind of the point - just a little something to tide players over at no extra cost), it would give those who can't play KSP2 right now a taste of what they could once they can either upgrade, or when KSP2 matures enough for their PCs to handle it in some capacity. Some or all of this can be added with various mods, I know. But having these changes as "stock" means that if support for the mods stops, KSP1 still has something that works. Or, potentially, bring these parts of those mods in as a free official DLC - provided the contributors agree, of course.

Some of those wishlist items I was going to write... But here are some more. - Shrouded landing legs for S and M sizes in addition to the exposed variants: cleaner look, aerodynamic enhancements. - Basic 'autopilot' functions (potentially for when Kerbals have XP and/or for high-end probes) when SAS enabled - auto-dock (if velocity is zero and within 1000m of target - docks 'right way up' with regards to the docking ports, option to rotate through 90 degree increments as needed), kill velocity/rotation (craft manoeuvres to zero velocity and rotation based on target), auto-orbit (set desired altitude via a drop down menu in 5km increments, on launch craft flies/attempts to fly to make parameters, notifies player when done - shuts down), auto-intercept (handy for surface to orbit rendezvous - select target, select intercept, craft calculates the best launch window and ascent profile for the flight, commits when suitable - if it is not able to achieve, due to delta V shortages or target eccentricity, does not engage and notifies player), auto-land (uses waypoints, using a drop down menu (specific to the body being orbited) select the waypoint you want it land at, it calculates the delta V and when to burn and does so - DOES NOT TAKE INTO ACCOUNT TERRAIN ANGLES...so the player better be sure where they want to land is reasonably flat. Or they should attempt a manual landing instead). -More sensor types/better 'KerbNet' (ties in with anomalies and finding them) - Electromagentic spectrum sensor (detects radiowaves - anomalies could emit a signal, giving you a way to refine your search for them such as by altering your orbit or adding satellites in different orbits of the same celestial body), Thermal sensor (detects different heat signatures or lack of them - anomalies could be hotter or colder than their background, making them easier to locate/detect), ground surveillance radar (provides high resolution mapping of planetary surfaces from orbit - the lower the orbit, the higher the resolution). -A 'simulator mode' when you can run tests on designs you intend to fly in a career-mode game - like a basic Sandbox mode.

I'll take on board your advice and give that a try next time I play some KSP2. Perhaps a hyrbid of KSP1 and the current system could work better - where you create the node is considered the "centre" (for lack of a better term, but not the literal centre) of that manoeuvre. The node takes your intended information, calculates it then applies a formula to it so your starting point isn't at the node itself but further ahead/behind as required, the node is just the interactive point at which you tweak your data. It needs to be somewhere along your projected trajectory (rails) because that's how the node is able to be created, but your start point is calculated based on what you want the thing to do, rather than where you want to do it. Works in my head, but there's probably a ridiculous amount of complex calculations occurring in the background to make that a reality.

This would be great. I like it. Also didn't know it was a mod for KSP1.

Manoeuvre nodes (MN). A system designed to assist you in planning an intended orbit or trajectory. The node, once calculated, provides a burn time and a count down to said burn time as well as a visual representation of your intended orbit or trajectory. You orient toward the trajectory/target marker and wait. When the timer reaches zero, you burn along that trajectory until the desired velocity and time is achieved then cut engines. You should now be in an orbit more or less matching your desired altitude or on your way to wherever you were travelling to, along a trajectory that more or less matches what you intended. Yeah, you might be anywhere from a few hundred, to a few (single digit) thousand metres out in an orbit - depending on how you managed thrust and how quick you were in cutting thrust - but it was in the ballpark. With interplanetary (including transit to the Mun and Minmus) intercepts, your periapsis could be tens of thousands of metres out if you timed it wrong or under/overflew the trajectory target marker. But you had plenty of time to turn retrograde (or prograde, depending on what you had intended) and make a slight correction burn, either manually or using another MN. That's the way it worked in KSP1. Maybe I'm approaching MNs in KSP2 wrong, but when I make a MN at suborbital apoapsis and drag prograde, I'm expecting an at least roughly circular orbit. Instead I get a wildly elliptical orbit. Tweaking the radial/normal/pro/retro has no where near the desired effect, dragging the entire node results in wildly differing orbital patterns. I know how to fix it manually, but the point is I shouldn't have to - that's what MNs are supposed to do. Previously, I make a MN from 90km perapsis, that is essentially the "centre" of the node. My 90x90 desired orbit wouldn't be exact - even if I didn't play around with moving the node - but it'd be ballpark and I could work with it. In KSP2, I make an MN from 90km perapsis, to have my desired periapsis in orbit at 90km or anywhere close to it, my apoapsis is now well over 200km. Way worse than anything KSP1 would do, but fixable once I'm actually in orbit. Burn says 37 seconds. Wait to burn, do so when the timer hits zero. Don't look at the map, just focus on the burn time and make I'm point toward my intended trajectory. 37 seconds is up, cut thrust when it reaches zero. Periapsis is under 90km. Apoapsis is now 480ish km... I shake my head, mutter under my breath some things that I know I couldn't do better than the devs, and then try to burn for the Mun - using a MN. My MN projected path is put my periapsis at 2,234km. Can't be bothered tweaking it, already over it. Fast forward to burn and burn. Watch the timer run to zero, cut thrust. My periapsis is...interplanetary. Now if I was following this in map view, I'd have seen this coming and cut thrust early. I could (did) also see the Apo/Peri readout on the main screen go beyond my established parameters, but I still have like 7 seconds of burning to do and I wanted to see just how and why the MNs are so wrong almost all the time. If I'm aimed at the right spot (which I was - according to the nav ball), burning for the right time (which I did, according to the timer), whether I'm looking at a map or not I should be pretty bang on where I intended to be. Now I will admit, and concede, that perhaps I am approaching MNs in KSP2 wrong and there could be a better way of getting circularised orbits (using MNs, doing it manuually isn't that much of an issue but that's not the point) and interplanetary trajectories with the current system. But Mk1 Eyeball Trial and Error Pro/Retrograde burns seems to yield far more reliable results and be far more efficient than using a node. That shouldn't be a thing. In a physics-based simulation game about travelling to other planets why such inaccuracy like this even a thing? Especially when the previous iteration of the game seemingly has a better algorithm for calculating burn times and is relatively accurate with not only those times but effecting the desired orbit or trajectory you were seeking. Sequels are meant to be better, not be actively worse. What am I doing wrong?

They could be constellations - Kerbal ones, obviously. Some of those constellation/shapes are similar (not identical, just similar) to the gyphs on the Stargate (from the Stargate franchise) - which are depictive representations of constellations in the Milky Way galaxy - which also made me think the crown symbols might be referencing constellations. I'm almost certain the concentric circles with the dot in the middle represents Kerbin itself - it's the only planet in the Kerbolar system to have exactly two moons (the circles representing their orbits), the dot obviously being Kerbin. The "Kerbin symbol" is unique in that it is the only one that is drawn using rounded lines (because, circle - duh...I know - work with me) - all the rest are drawn with straight lines at varying angles, and only 3 other symbols on the crown use dots. Interestingly, they all use exactly two dots - while Kerbin only has the one. If you think you've already found some of these constellations in the Duna night sky - you may be on to something. But what is the significance of these 26 constellations? What does any of this mean? Are they a system of coordinates? Specific places to visit seems unlikely - the stars in a constellation can be ridiculously far apart in reality, only appearing close and making shapes based on the position of the observer. Is it intended to be some kind of universal language using a 26 letter alphabet? An equation? I'm hoping this little mystery will allow itself to at least start to be unwrapped when Science! (TM) is introduced. I really miss science.

I like the idea of multiple rockets within a workspace - this is a handy feature I didn't know I needed - but I don't like how the save system works when trying to save several independent rocket/craft designs in the same workspace. I tend to put groups of similar mission-type craft in the same workspace (e.g. orbital comms relays, orbiters, crewed mun landers) which works for now because due to the bugs I experience in KSP2, I've not gone interplanetary - I don't have the time, energy or patience to work through it right now. I would like to see a way to call up individual craft (much like the old sub-assembly system) so I can bring a previously designed craft into a new workspace for use in a new design. EXAMPLE: I have developed a lander that works on any moon/low gravity environment in "Mun Landers" workspace. It has been used successfully a number of times, so I know that staging, fuel lines and everything else on it works. I am developing a craft designed to go to Duna and remain in orbit while some of the crew descend in a lander in "Duna Mission" workspace. I surmise that the lander I developed in "Mun Landers" would work perfectly. Instead of making the craft again, and potentially making an error in the build process of my already proven lander, I can simply call up that individual craft and place it in the new workspace and build my Duna vessel around it. This is something I've just started doing in KSP1 - developing common craft that can work independently but also work as part of an "ecosystem" for other missions. I've shifted to keeping craft in orbit and sending up a refueller and swapping out crews as/when desired (I swap out my crews to distribute experience evenly - career mode, heavy focus on Mun/Minmus landings currently - haven't gone interplanetary yet: have a probe on its way to Eve at the moment), essentially a "dress rehearsal" for true interplanetary vessels. So by having common craft I can design new vessels around my existing designs, instead of developing (usually inferior) bespoke designs for each vessel like I have in the past.

I agree - ILS is a must. I'm surprised KSP1 didn't add it in, to be honest. It would certainly help with landing at KSC from orbit (without having to LITERALLY eyeball it). I think the devs have a bit on their plate at the moment, but I feel at least looking into ILS for the runways is worth the effort.

I don't think colonies strongly implies life support, but I would be very surprised if we didn't get some sort of life support system at some point (Colonies would make sense, so players grow accustomed to it before Interstellar travel becomes a thing) - even something as simple as a part you place on a vessel that requires power to operate. My hunch is we may need to meet a number of criteria for "life support". With the rotating sections we've seen in some of the trailers, I think artifical gravity will be one criteria, oxygen may be another and finally, probably something to do with "snacks". That or the rotating section is just a cool looking high-capacity Kerbal storage and I'm looking too deeply into things. Hopefully the former though. If they don't include something, I think it will be a missed opportunity. Yes, some modder will add it but, while modders are supported and encouraged by the dev team, this is something that should be in the base game in some simple form - allow the modders to go overboard with it, just get something dealing with basic life support functions in the base game for them to expand on if they choose to. It would have to be optional, as some people wouldn't like life support with any serious consequences. However there was some disucssion a while back on the Discord that Life Support would be added however it wouldn't have "serious consequences" (i.e. your Kerbals wouldn't die, they'd just be less effective without it) - however there were no sources cited during that discussion so "grain of salt" with that.

Well, if you're following a logical progression path then yes you will explore and mine the "homeworld" before you can explore the other planets/stars. If I was to hazard a guess, I would probably have a strong argument that Kerbin is the most unexplored planet in the Kerbolar system in KSP1. So if KSP2 bucks that trend and we spend a little more time putting up satellites to map Kerbin and understand that planet before we go to the Mun and beyond, and repeat the approach, I think we'd all be better for it. And, like you, I have also started and restarted quite a number of Career modes - except I do so without mods. If you don't want to follow the full "career mode" path - that's literally what the Sandbox mode is for. Or if you want the campaign minus the "hard stuff" at the start, you'll (hopefully) be able to slider-and-checkbox your way around those starting "first few slow steps". I would also assume that, like KSP1, when starting a new "career mode" (Exploration mode?) campaign in KSP2 you would be able to select what you do and don't have access to via sliders and check boxes - as that "softened the blow" of starting a new campaign in KSP1 and having to build the same 3 mystery goo canister carrying Mk1 pod with a Flea SRB and maybe some winglets and a parachute EVERY, DAMN, TIME you started a new campaign... Unless you're a glutton for punishment. Like I am with KSP. I very rarely tweaked my starting resources to give myself a leg up - the rate at which I gained resources, on the other hand - those I tweaked. Especially Funds. Even if it is a single story, how does that affect replayability? How do games like KOTOR and Mass Effect - which all have a common ending - get replayed time and time again? It's the *players'* mindset and approach that sets each playthrough apart. Plus, when you restart, I guarantee you, you build your "first few" rockets differently than from your very first playthrough - because you've learned new skills, which changes the outcome - by becoming arguably more efficient and/or streamlined. As for a single playthrough approach, considering they're going to be adding more than a few star systems I believe we'll have hundreds of hours (even with time compression) if we play a career mode from start to finish. If there's even a quantifiable "finish/end" to KSP2. While I will admit my impressions of KSP2 are...less than I had hoped...I'm not considering a refund, nor would I as I no longer meet the requirements for one having played KSP2 for more than 2 hours and having owned it for more than 2 weeks. I'm not as concerned about FPS, this isn't a shooter or twitch-based game after all, but I am concerned about putting heavy payloads (thus requiring heavy, large rockets with complex fuel usage, multiple engines and stages) in space and being able to reliably circularise an orbit and/or dock, and reliably navigate between celestial objects. I am, however, also quite interested to see what the first patch brings/fixes. While I'm not expecting it to address all of the issues straight off the bat, I would like to see it address the majority of issues that we have in KSP2 that aren't in KSP1.

My theory on the anomalies is that we have them "uncovered" at the moment, as part of the Early Access. Not sure as to the reason for this exactly - but I suspect it's to encourage players to explore (which was stated by Nate Simpson in interviews during the ESA Creator Early Access event). Once we have Science(TM) introduced, I believe we'll see these anomalies covered, at least partially, and we may have more placed in the Kerbol system. We will need to utilise earth moving (either actual or in a similar method to the upgrading of the KSC in KSP1 - using enough science you can "upgrade" the dig site, that is to remove some of the debris) to uncover the anomaly/monument. Once it is fully uncovered, I believe we will need to conduct long-term research on the anomalies in order to yield some kind of narrative direction, thus creating a goal for us. To me, the Mun Arch and its map of the Kerbol system is the "youngest" anomaly. It's in the best condition and is the only one that acts as a map. As the Mun is the closest body to Kerbin, it would make sense that a low-tech spacefaring species would attempt to reach it first - so having a map of the star system on the Mun to give such a race an idea of what's in their solar system makes sense. The Minmus anomaly suggests that Kerbals are not the original inhabitants of Kerbin. The "Krakenoid", as I call them, in the centre represents Kerbin and their form share some similarities with the Kerbals. The larger and smaller circles on the floor of the anomaly represent the Mun and Minmus respectively. The spheres along the outside potentially represent the other major planetary bodies in the star system however it is interesting that they do not differentiate between the planets like the Mun Arch (which leads me to believe the Mun Arch was made *later*, after these Krakenoids built the anomaly on Minmus and after they had explored the star system). The Duna anomaly suggests contact between an advanced species and lesser species OR it could suggest an evolutionary stage in the life cycle of Kerbals (i.e. Kerbals eventually become Krakenoids). Either way, there are (or were) representations of 4 species, 2 we have seen, the other 2 are missing or damaged. One is definitely a Kerbal, the other a "Krakenoid". The head on which they reside appears to be either an older and wiser "Krakenoid" or is viewed as some kind of deity as their features are more defined and less "cartoonish" compared to the Kerbals and the "Krakenoid" figures on that anomaly and as depicted on Minmus. The central planet and its gold device around its circumference, and the fact that its the same colour/material as the anomaly on Minmus suggests it's either referring to Kerbin (as the home to potentially not just two, but perhaps 4 species - or as a place of reverence to all 4 species) or its referring to the planet where this deity resides, or at least resided, as sort of an invitation ("If any of the species find this monument, you can find us on this planet", perhaps). The Tylo anomaly is the odd one out to me, more so than the Duna anomaly. This does not depict your usual Krakenoid, as it appears to have much more defined tentacles than the "cuter" Krakenoids. The eyes are different as is the body shape compared to Kerbals or the Minmus-style Krakenoids. It also appears more like a care-free "Buddha"-type depiction as opposed to the leaner, more serious looking, "Wise Old Krakenoid" on Duna. Which suggests they could be an evolutionary stage, as opposed to another race (Kerbal > Kerbal/Krakenoid > Buddha Krakenoid > Wise Old Krakenoid). If its representative of another race, why are there 3 "Krakenoid" specices and the Kerbals are distinctly not Krakenoid but somehow involved with these species? I do have a theory on this as well, which I will share later in this post. The "Buddha" is hold two stars. I have seen some say this represents a binary star system (in which case it's potentially saying "Find this place, go there"). However I believe it's representative of two different stars. The larger orange one is Kerbol, the other is another star (Debdeb, maybe?) and the Buddha is holding them far apart - perhaps indicating they are very distant to one another. Either way, I believe it's an invitation, or at least an "address" at which you can find the Krakenoids, or what remains of their civilisation. I believe the Krakenoids are a precursor species that, potentially, either evolved on Kerbin alongside the Kerbals or discovered them on Kerbin and visited them. There may have been a technological exchange and these anomalies were all built by a "pre-cataclysm" spacefaring Kerbal species (hepled by the Krakenoids). At some point, Kerbals experienced technological regression (my best guess is some kind of cataclysmic event) and the Kerbals were either abandoned by (or the Krakenoids felt as though they should isolate themselves for some reason), or perhaps the cause of the disappearance of, the Krakenoids. And, until Kerbals began to gain the ability to return to space over a span of time, they have remained forgotten. An alternate theory is that the Krakenoids have devolved (or perhaps evolved) into Kerbals, whether due to time spent in space or some unknown cataclysm, and forgot who they were originally. Perhaps they came from another star system seeking a new home and, while they were exporing Kerbol, discovered Kerbin and decided to stay (or perhaps were forced to, maybe the Krakenoid version of Jeb was a little too eager to land their interstellar ship), over time evolution shaped them into a form that was better suited to Kerbin. I think KSP2 will have a much more pronounced narrative for players to follow in the 'Exploration mode' that functions as KSP2's "career mode". I think it's going to provide us with lore and reasons to explore other planets - more closely than landing in a biome to collect some science points, having a bit of a look around and then leaving again to potentially never return unless you get a mission contract to return or decide to make an outpost on/around said planet at your own cost. I think, by the time we're ready to go interstellar, we'll have an understanding of what we're looking for and why. It's obviously a BIG reason, the resources we'll probably have to amass to develop and produce an interstellar-capable ship will be considerable effort just to say "Hi". At the end of the EA trailer, the veritable armada of interstellar ships suggests either a mass exodus or is a representation of what multiplayer is going to look like. Given that the devs have said KSP2 will not have weapons added, I don't think our Krakenoids are going to be hostile. If anything, they may be extinct. However I feel that, if not on any planets in Kerbol, we are going to discover both lifeforms and intelligent life in KSP2. Thank you for reading. What are your thoughts on the overall "story"/lore of KSP/KSP2?

Settings like this would (or at the very least *should*) definitely be a feature you could turn off (like Kerbal deaths and the Comms network in KSP1 or the "infinite fuel" in KSP2).

I have heard that life support is going to be a thing in KSP2 (source: Discord discussions so "grain of salt"), however it wasn't going to kill Kerbals if it failed/wasn't present - it would just reduce their effectiveness (how wasn't discussed, not that I read). I imagine a "simple life support system" would require power and just be a module, or series of modules, to provide "quality of life" to Kerbals on a craft. We have seen rotating sections (in trailers and pictures) - which would suggest that artificial gravity (via centrifugal rotation) is important (if they're not simply just larger capacity Kerbal storage). I'm guessing Life Support parts are either going to come with Colonies or with Interstellar parts - if I were the devs (and Life Support is going to be a thing), I'd release Life Support parts with Colonies so players can get used to them before we start going interstellar (so incorporating them into designs isn't "new" when dealing with designing an interstellar ship).

Yeah, that was my point. And I know we've had female Kerbals for years (2015 they were added, I'm pretty sure) - my astronaut roster in my current save is 2/3 females.

*Looks at my current roster of Kerbals in KSP1, which is 2/3 female - my team clearly didn't get the "exclusively for men" memo* Need I remind the OP that, without the contribution of women to the (especially US, as I am more familiar with that) space program, Apollo would never have launched. Google 'Apollo mission coder', 'Apollo mathematicians' and also Google 'Judith Love Cohen'. While you're at it, show your daughter. And, while a woman hasn't landed on the moon yet, a woman and a person of colour will be among the first, if not the first, astronauts to set foot on the moon when we return in the coming years with Artemis 3 being the first crewed landing (scheduled for launch in 2027 - definitely make sure you and your daughter tune in for that one: it will be historic). I would, very loudly, counter your statement that KSP1 suggests space is exclusively for men. I would also maintain that notion, even louder, for KSP2. "The Kerbal Effect" would like a word with you... They were initially just meant to be the little green aliens with a love of space flight and explosions with potentially no self-preservation instinct. They very obviously have a less risk adverse culture, at the very least. I didn't play KSP1 for the gender of the Kerbals, I was - and still am - here for space flight. Since the introduction of Valentina Kerman (so named due to the first female human in space being Valentina Tereshkova), female Kerbals are common (maybe not 50/50 but definitely more than 33%) in the roster of Kerbal recruits available at the Astronaut Complex at the KSC. Their stats (Courage and Stupidity, regardless of archetype) are applied at random and in my Space Agency, it's a meritocracy - the more courageous and less stupid you are, you're hired. There are female Kerbals in KSP2 already - you need only pay attention to the art style of the Kerbal portraits. At the moment, outside of aesthetics, gender has no bearing on capability as Kerbal XP is not yet implemented (if it's even going to be). And even in KSP1, Kerbal gender has no bearing on how "good" a Kerbal is. It's easier to see in the EA Release Trailer, highly recommend watching 5, 6 or 7...maybe even 8 times. Song is catchy... Basically, if they have eyebrows and a more rounded jawline - they're female Kerbals. Not as sure on the hair department, however the female pilot in the trailer (who I assume is Valentina - in which case, where are Jeb, Bob and Bill? If not, who is she? And who are the scientists?) has a shorter hairstyle (at the back) with a fringe, while the female scientist has pig tails. The male scientist, by comparison, has no eyebrows, a squarer jaw and what I can only describe as a 'Rick Astley' hairstyle (though the 'traditional' Kerbal Widow's peak is also an apparent male Kerbal favourite). Having said that, I'm sure someone will correct me if I've assumed something I shouldn't have - but I feel that's the aesthetic the art team were going for. Outside of gender symbology, I'm not sure how one would be able to specifically depict a non-binary Kerbal.

Of course the devs are "in fact working hard". Silence does not equate to the devs not working. In fact, silence is pretty much what you want from devs after a...problematic...release. What that shows is that they are indeed actively developing iterations for release but it doesn't necessarily mean that a patch/update is imminent. Outside of "weeks not months", I'd ease up on those expectations of "quick fixes". There's a lot riding on this first update so I doubt they're going to rush it. If it adds more issues, or fails to resolve "obvious" issues, out come those pitch forks and torches again. So, once they're confident it has its bang for buck, we'll see it drop. Not before.

That was what the Ground Anchor in KSP1 was for - to lock a base/craft to the ground. I was hoping that wouldn't be needed in KSP2. At present though it seems like it might be... I don't even pretend to understand why the surfaces of planets are/have to be slippery but I would like the game to recognise that wheels that are not in motion - on a craft that is not under load - as well as the landing struts - on a craft that is also not under load - should not move/slide/invoke the Kraken's tentacles. By under load, I mean on a significant angle which, based on the craft's weight, would cause it to slide/roll/tilt downward OR (for rovers/ground vehicles) when power is applied to the wheels.

I'll admit I had a similar thought, mainly purely due to the song choice. Some of the lyrics certainly imply the devs could be communicating their thoughts and feelings to us, and their fears of our thoughts and impressions of the state of KSP2 on launch... Truly, things can only get better. But I'd have to go full-on Kool-Aid drinking, with spider diagrams of an analysis of the lyrics, to convey my meaning beyond that. And I'm not there yet. Having said that, my opinion on the devs, the state of KSP2 as it is currently, and the development time it has taken has changed - in part due to a video by "Grey Beard Gaming". According to him, data miners have discovered entire elements/features have been hidden for the public release. Add to that the fact that Nate, in his interview with Matt Lowne (which GBG mentions but I also saw/heard/watched myself), claims he has already played KSP2 multiplayer (a feature which is one of the later features intended on being implemented) - so there's clearly an early build of it over at Intercept Games, which means there's potentially more to KSP2 than we're being allowed to access/see. I'm still not happy with some of the parts/features missing/changed and the bugs we're all encountering (even if there are entire features that have been developed but are being hidden) but, with that being said I don't think your theory (nor mine) is entirely without merit.

I agree in principle. An example of this is the F-5E, which has the capability to extend to increase AOA on take off - and the venerable F-4s of the Royal Navy, whose nose wheels could extend so much they actually looked like they'd break under acceleration. And not just plane landing gear - rocket/lander landing gear could also use a slider to shorten/lengthen, or at the very least landing struts/gear in fairings for XS-M sizes - particularly for the S/M sizes.

The issue with that, at least for me, is that opens yet another window - which is not in the same aesthetic as the rest of the "HUD", I might add - in a UI that already has a lot of real estate taken up by information elements. Having it as selectable mode on the speed indicator - whether it be in Mach strictly, or whether it switches to Mach from CAS over Mach 1 - means it's not invasive and "feels organic". Besides if the game is already tracking a craft's Mach speed it won't take much to add another speed display, as the game already knows where to look for that information and what it does/means (to the game engine).

I'd like to see at least a Mach indicator - whether it be a display that is constantly in the UI (like the Apo/Peri read out) or a speed indicator mode likeSurface/Orbit/Target.

(This was also posted in response to a MN bug report, but as I got carried away, went on a tangent and provided a suggestion - I will also place it as it's own suggestion here) I'm not a physicist, astrophysicist, scientist, rocket scientist, astronaut, a rocket surgeon or even a space shuttle door gunner. My understanding of orbital mechanics stems completely from KSP (and lately also Juno: New Origins...which does some things I like - like auto burn even though I sometimes prefer to do it myself), and I'm not even very good at understanding most of that. So when you all talk about Delta V in the second half of the burn being easier due to less mass, or the efficiencies of burning prograde and not pointing to target or pointing to target and using SAS hold, I'll just smile and nod. I understand the concept of what you're saying, but not the math involved. I know how to get to the Mun without using manoeuvre nodes, how to get into an orbit (in transit) if my periapsis is too low and how to circularise an orbit without them too. Getting an orbital encounter I can do in KSP1 - with nodes, not without...not so great in KSP2 in part because of the node system and it's "intuitiveness". But that's not the point - the point is the manoeuvre node is supposed to correctly and accurately calculate these things for me way better than I ever could. I like the fact that the nodes now tell me when to burn, and grab my attention in some way just prior to the burn however, as it stands, every burn I make "trusting the node" is wrong and I have to fix it manually using what little I know of orbital mechanics. Even getting a circular orbit in KSP2 - starting the node from apoapsis, or even before it - is difficult. I have to make significant correction burns if my intent is for a circular orbit - otherwise I generally just burn out of orbit from whatever kind of orbit I'm in to get where I'm going. "Brute force it", so to speak. What I would like is if the node was "intuitive" enough to figure out I'm trying to burn for Mun (or any planet) periapsis, or get into/circularise an orbit, or intercept/encounter a target and apply some sort formula to compensate when calculating the burn based on the parameters I've set when planning my node - so I don't need to figure out how many seconds three minutes and 49 seconds), what half of that is and then subsequently realise I've missed the start of the burn because I was too slow with my calculations and there's nothing grabbing my attention to start said burn (in KSP1) - and in what direction to burn in order to make the burn I planned work as I intended. What I would also like to see is, potentially in the right click radial menu of the node, a button for calculating an orbital circularisation burn based on the current/intended apoapsis (as we all do this A LOT, so this will save us a lot of time) and a button for calculating an intercept of the target (something else we'll be doing a lot of, I imagine) be that a ship or a celestial body - and if it can't get us a perfect intercept/encounter, it gets us close enough to whatever we're trying to get close to so we can do a mid-course correction burn to get us even closer, rinse repeat until intercept/encounter). I would also like to see a way to manually input our desired apo/peri either in our current or desired orbit (at the desired target) and have the manoeuvre node calculate a burn to accommodate that for us. In "campaign mode", these options would be later-game but in EA sandbox (i.e. what we have currently) they could be implemented and fine-tuned so that come v1.0 release we're all singing off the same sheet of music. It doesn't have to be perfect (or perhaps, 'perfect' course plots can be another upgrade) it just needs to get us in the ballpark so we can course correct or establish an elliptical orbit or whatever our plan is for where ever we're intending to go. In KSP2, I feel that automation of the more common navigational manoeuvres should have "quick access" (circularise, intercept - as this would also cover interplanetary insertion burns) buttons in the manoeuvre node. I also feel that automation of the more repetitive tasks (such as getting a ship into orbit, and/or circularising an orbit, and docking) could (or perhaps as a selectable option, should) be a thing the devs prioritise - especially to make the game more accessible and especially when we have colonies and resource gathering to worry about. Example 1: You've been manually launching rockets for 20 hours - but since you've upgraded to the Level 3 Tracking Station, here's a series of buttons to help you automatically launch your craft, circularise its orbit and, if need be, calculate an intercept of a designated orbital target. Example 2: You've been building ships module by module in orbit with varying degrees of success (if you can get the nodes to work for you) for the last 50 hours - but since you've upgraded to the Level 4 Tracking Station, here's a button that will 'auto-dock' you - right way up, every time - to your target, provided you're within 1000m and your velocity relative to target is 0 m/s. No more twisted, misaligned modules from now on. Example 3: You've gone to Debdeb and back, six times, and docked landers to your orbiting ships 9,700 times in your 120 hours of KSP2 - but since you've upgraded to the Level 5 Tracking Station here's a button that calculates the intercept of a celestial body and more accurately calculates orbital intercepts from the ground - and also plots the trajectory of an interstellar burn. Good job, you've earned it! Does that make it "too easy"? In Sandbox, yeah maybe. But if you wanted the challenge, you'd be playing a career mode. And if you're playing career mode, after doing the same thing a billion times (like you do in career mode), a more efficient way of doing it would be appreciated. You'd obviously have to "do the hard yards" to earn (and therefore deserve) them by the time you've reached the late game. Plus, these are/could be optional, with the unchecking of a box in the Settings menu you can still do these things manually either as good as, or perhaps even better than, the nodes can. But they're there to help players and reduce the micromanagement and monotony of constant launches, orbits and trans-planetary insertion burns and whatever else. But for any of that, we need this manoeuvre node thing looked at because as it stands right now, I'd much rather "do things manually" (yes, I'm aware MechJeb is a thing) in KSP1 than deal with whatever the hell is going on with KSP2.

Well that seems to explain my issues... So the alternative to making a lander is...make a lander that doesn't land?

I'm not a physicist, astrophysicist, scientist, rocket scientist, astronaut, a rocket surgeon or even a space shuttle door gunner. My understanding of orbital mechanics stems completely from KSP (and lately also Juno: New Origins...which does some things I like - like auto burn even though I sometimes prefer to do it myself), and I'm not even very good at understanding most of that. So when you all talk about Delta V in the second half of the burn being easier due to less mass, or the efficiencies of burning prograde and not pointing to target or pointing to target and using SAS hold, I'll just smile and nod. I understand the concept of what you're saying, but not the math involved. I know how to get to the Mun without using manoeuvre nodes, how to get into an orbit (in transit) if my periapsis is too low and how to circularise an orbit without them too. Getting an orbital encounter I can do in KSP1 - with nodes, not without...not so great in KSP2 in part because of the node system and it's "intuitiveness". But that's not the point - the point is the manoeuvre node is supposed to correctly and accurately calculate these things for me way better than I ever could. I like the fact that the nodes now tell me when to burn, and grab my attention in some way just prior to the burn however, as it stands, every burn I make "trusting the node" is wrong and I have to fix it manually using what little I know of orbital mechanics. Even getting a circular orbit in KSP2 - starting the node from apoapsis, or even before it - is difficult. I have to make significant correction burns if my intent is for a circular orbit - otherwise I generally just burn out of orbit from whatever kind of orbit I'm in to get where I'm going. "Brute force it", so to speak. What I would like is if the node was "intuitive" enough to figure out I'm trying to burn for Mun (or any planet) periapsis, or get into/circularise an orbit, or intercept/encounter a target and apply some sort formula to compensate when calculating the burn based on the parameters I've set when planning my node - so I don't need to figure out how many seconds three minutes and 49 seconds), what half of that is and then subsequently realise I've missed the start of the burn because I was too slow with my calculations and there's nothing grabbing my attention to start said burn (in KSP1) - and in what direction to burn in order to make the burn I planned work as I intended. What I would also like to see is, potentially in the right click radial menu of the node, a button for calculating an orbital circularisation burn based on the current/intended apoapsis (as we all do this A LOT, so this will save us a lot of time) and a button for calculating an intercept of the target (something else we'll be doing a lot of, I imagine) be that a ship or a celestial body - and if it can't get us a perfect intercept/encounter, it gets us close enough to whatever we're trying to get close to so we can do a mid-course correction burn to get us even closer, rinse repeat until intercept/encounter). I would also like to see a way to manually input our desired apo/peri either in our current or desired orbit (at the desired target) and have the manoeuvre node calculate a burn to accommodate that for us. In "campaign mode", these options would be later-game but in EA sandbox (i.e. what we have currently) they could be implemented and fine-tuned so that come v1.0 release we're all singing off the same sheet of music. It doesn't have to be perfect (or perhaps, 'perfect' course plots can be another upgrade) it just needs to get us in the ballpark so we can course correct or establish an elliptical orbit or whatever our plan is for where ever we're intending to go. In KSP2, I feel that automation of the more common navigational manoeuvres should have "quick access" (circularise, intercept - as this would also cover interplanetary insertion burns) buttons in the manoeuvre node. I also feel that automation of the more repetitive tasks (such as getting a ship into orbit, and/or circularising an orbit, and docking) could (or perhaps as a selectable option, should) be a thing the devs prioritise - especially to make the game more accessible and especially when we have colonies and resource gathering to worry about. Example 1: You've been manually launching rockets for 20 hours - but since you've upgraded to the Level 3 Tracking Station, here's a series of buttons to help you automatically launch your craft, circularise its orbit and, if need be, calculate an intercept of a designated orbital target. Example 2: You've been building ships module by module in orbit with varying degrees of success (if you can get the nodes to work for you) for the last 50 hours - but since you've upgraded to the Level 4 Tracking Station, here's a button that will 'auto-dock' you - right way up, every time - to your target, provided you're within 1000m and your velocity relative to target is 0 m/s. No more twisted, misaligned modules from now on. Example 3: You've gone to Debdeb and back, six times, and docked landers to your orbiting ships 9,700 times in your 120 hours of KSP2 - but since you've upgraded to the Level 5 Tracking Station here's a button that calculates the intercept of a celestial body and more accurately calculates orbital intercepts from the ground - and also plots the trajectory of an interstellar burn. Good job, you've earned it! Does that make it "too easy"? In Sandbox, yeah maybe. But if you wanted the challenge, you'd be playing a career mode. And if you're playing career mode, after doing the same thing a billion times (like you do in career mode), a more efficient way of doing it would be appreciated. You'd obviously have to "do the hard yards" to earn (and therefore deserve) them by the time you've reached the late game. Plus, these are/could be optional, with the unchecking of a box in the Settings menu you can still do these things manually either as good as, or perhaps even better than, the nodes can. But they're there to help players and reduce the micromanagement and monotony of constant launches, orbits and trans-planetary insertion burns and whatever else. But for any of that, we need this manoeuvre node thing looked at because as it stands right now, I'd much rather "do things manually" (yes, I'm aware MechJeb is a thing) in KSP1 than deal with whatever the hell is going on with KSP2.

Maybe, for all the components to be in place. I'd prefer less than that, obviously. But considering KSP1s life cycle, and the life cycle of other games that enter EA - dev time is measured in years, sadly. You can always hope for the best, but I think it would be unhealthy to expect anything more than one major milestone per year.