Precision landing pad

[Pthigrivi]

I'll only add that I think everyone here would agree that tools like visible trajectories factoring drag and time to impact/burn info to help players land more accurately would be awesome and welcome. 

[Guest]

1 minute ago, Pthigrivi said:

I'll only add that I think everyone here would agree that tools like visible trajectories factoring drag and time to impact/burn info to help players land more accurately would be awesome and welcome. 

And also a ton of the tools that normally fall under the umbrella of what people usually call an "autopilot".

Nobody is going to debate about SAS, or an altitude, hover or heading hold.

[Mahagon]

Oh my, this went quite far from the time I last had a look.

Let me tell my story: I am Playing KSP Enhanced Edition on PS4. - No Mods obviously. So everything that was not in the Core I do not have... Without the Breaking Grounds expansion being available later, no robotics, no moving parts, no action groups (all science had to run completely manually) - that was a huge hurt for larger crafts, limiting the objects I did want to visit.

Landing on the Moon was already very painful, as back in the days you had only Elevation over Sea Level. I included a stage that would drop just the decoupler to the ground. Just in Order to get the Distance to the decoupler on the ground, to know how far above I was. This was really showing me, I need something in the UI I do not have access to, and almost discouraged me from playing any further.

Next I tried Planes. I simply could not gather the information where I am in relation to the runway, until I was already over it - which is to late for a maneuver. I tried to set up markers again, but still could not land on the runway. So I started to land next to the runway on the Grass - much easier, but much less satisfying.- Again a big disappointment for missing some UI features that would allow me to do tasks that should have been simple.

And Flying Planes is always annoying - you do not have a stability assist that allows you to retain a certain angle to horizon & bringing back the plane to the ground. So if you wanted to fly one around Kerbin, it would be all manual, as there was no stability assist for planes - which would have been great, because flying once around Kerbin took mostly longer than the average time between bluescreens, bringing you back to the last auto safe, rushing to the tracking station and selecting the vessel, trying to re-stabilize it before it crashed. That could have been a so much smoother experience, by just a simple feature - at the same time I often wished for a Zenith and Nadir lock mode.
(I think Dev diary covered the fun of building a plane already pretty well. Another feature that I wished for here would be to be able to see the CoM full and Empty at the same time, or even to get the coordinates of these.)

In this Game Information is Key, and getting the Velocity Components, or with my trajectory suggestion knowing 10km away from the landing that you are 20m left of the Runway, and at the right descent velocity - invaluable. Then it would feel like you drove some high tech plane, and not a badly folded paper plane. However introducing all this numbers to early, will scare the players off, and for most of the time many of the numbers are not relevant, so there has to be a possibility that the player can adjust the UI with different Presets of numbers he wants to have shown.

With this in mind I think the game should reach people, get them invested, and allow them to set themselves more and more challenges. But it should be fair - like it was said in the Dev diaries. KSP2 will equip the player to do the stuff instead of being frustrated about the UI. That should not be automation, but putting them in control. And encouraging them to learn in a playful manner, which could also mean looking up the basic math, and strategies to solve this.

My thoughts on the different Topics:

Resource Penalties:

This is a Physics Simulation, I understand perfectly, that recovering a Vessel from far away costs Money in Career Mode (For the Launch of some Recovery Vessel and its fuel consumption, crew, time and effort), however I would not understand why suddenly the content of the vessel should change. So the further away I land, I need potentially more fuel (or Energy - for a Electrical Powered Rover Recovery), and obviously the cost would scale with the vehicle size. But 500t of ore being annihilated into nothingness, sound for me like a very nasty thing in a Physics simulator (E= m c² tells us that has some consequences). Additionally, a game should be rather with rewards, than making the penalties a nuisance, so I do not think anyone would want to do such a thing like the feared penalties.

Precision Landing:

For the challenge, and for some mission parameters selected (Landing on high enough elevation on Eve to make it back, getting into a mountain Ridge, to get Optimal Solar Output, placing a lander into an interesting Biome, Getting to Visit an interesting ?-Location) precision may be key, so players will attempt it. I would be thrilled if KSP2 would no longer feel, that you fly on sight alone once you leave the orbital view.

The main satisfaction is managing a difficult task, making a plan and executing it. More tooling to execute the task would be appreciated, and would even give the players deeper understanding and situational awareness, while keeping the challenge to a level that an achievement stays an achievement.
 

How to implement the additional information:

I like the concept that the UI evolves with the tech tree. The Idea that something like a Precision Trajectory and Information being tied to some infrastructure sounds also great for me. I would imagine, to get precision position data, you would need some kind of telemetry & communication - so a RADAR and Comms to the vessel. That RADAR could be the base also to set up a trajectory (similar to the Controllers) in the range of the structure (giving the possibility of having different technical tiers with wider range). - This would make physically sense, and players would do their first missions without it, learning the basics, before getting more and more information and capabilities (which might be overwhelming for a beginner). This being similar to the Delta-V Simulator during Rocket building and Advanced Orbital Information would perfectly fit into the concept, and would give a sense of achievement unlocking the next level UI, having even more information and control.

 

 

[shdwlrd]

@Master39 Would you consider advanced SAS functions an autopilot? I'm referring to the pilot assist functions that I've used in the old Microprose flight sims I use to play. They took very limited control of certain flight characteristics to make flying easier. 

What I'm thinking is a VTOL and aircraft modes for the SAS function.

So, what you would have is the standard old SAS function that we all know and have a love/hate relationship with. No changes to it, the way it behaves ok and has it uses.

Then the VTOL SAS function that doesn't allow any un-commanded or un-warranted changes to your velocity or craft orientation. Let me explain what I mean by un-commanded changes. When doing the controlled fall of a tail landing in a vacuum, when you thrust to reduce your vertical velocity, your horizontal velocity and direction will not change (if any). Or you when you build a VTOL (helicopter, jump jet, hover chair, etc.) as long as the CoTh and CoM is reasonably well lined up, take off and settle into a hover, you craft will not move. The only perceived motion should be from the Cornelis effect (unless you correct for it). Warranted changes are; contact with an object or craft with enough force to change the velocities or orientation (a Kerbal walking into the craft shouldn't affect anything about the craft, a rover will cause disaster); touching the ground with enough horizontal motion; and if added, wind, if strong enough.

Aircraft SAS, it doesn't exactly pertain to this thread, so I won't explain the functionality. 

[Guest]

4 hours ago, shdwlrd said:

@Master39 Would you consider advanced SAS functions an autopilot? I'm referring to the pilot assist functions that I've used in the old Microprose flight sims I use to play. They took very limited control of certain flight characteristics to make flying easier. 

What I'm thinking is a VTOL and aircraft modes for the SAS function.

So, what you would have is the standard old SAS function that we all know and have a love/hate relationship with. No changes to it, the way it behaves ok and has it uses.

Then the VTOL SAS function that doesn't allow any un-commanded or un-warranted changes to your velocity or craft orientation. Let me explain what I mean by un-commanded changes. When doing the controlled fall of a tail landing in a vacuum, when you thrust to reduce your vertical velocity, your horizontal velocity and direction will not change (if any). Or you when you build a VTOL (helicopter, jump jet, hover chair, etc.) as long as the CoTh and CoM is reasonably well lined up, take off and settle into a hover, you craft will not move. The only perceived motion should be from the Cornelis effect (unless you correct for it). Warranted changes are; contact with an object or craft with enough force to change the velocities or orientation (a Kerbal walking into the craft shouldn't affect anything about the craft, a rover will cause disaster); touching the ground with enough horizontal motion; and if added, wind, if strong enough.

Aircraft SAS, it doesn't exactly pertain to this thread, so I won't explain the functionality. 

That's basically what I meant when I said "hover hold", not exactly the same but usually it keeps you from flipping upside down or slamming into the ground or shooting upwards with a single input, it tries to keep the craft at a fixed altitude (or vertical speed depending on how it works) and it doesn't allow you to tilt enough to flip.

Just watch the first minute of that, that's what I meant by hover hold and that's probably what you're thinking too (thanks again Bahamuto for the best VR game out there).

As for aircraft altitude, speed, heading hold are just QOL features, keeping a plane withing 19000 and 20000 meters for an hour is not flying skill, it's just plain old patience.

[The Aziz]

Speaking of information being a key, you can bet that there will be a body with a thick, opaque atmosphere, something like on Titan or Venus. Which means, in essence, an IFR flight. Having enough data present in front of you when you can't see what's outside is a must.

[shdwlrd]

12 hours ago, Master39 said:

That's basically what I meant when I said "hover hold", not exactly the same but usually it keeps you from flipping upside down or slamming into the ground or shooting upwards with a single input, it tries to keep the craft at a fixed altitude (or vertical speed depending on how it works) and it doesn't allow you to tilt enough to flip.

Just watch the first minute of that, that's what I meant by hover hold and that's probably what you're thinking too (thanks again Bahamuto for the best VR game out there).

As for aircraft altitude, speed, heading hold are just QOL features, keeping a plane withing 19000 and 20000 meters for an hour is not flying skill, it's just plain old patience.

We're talking about different methods of SAS. What you're showing is active control to keep the craft in place.

What I'm describing is isolating the craft from errors from the physics engine and certain types of craft updates. And also adding a dead zone where the CoM and CoTh is considered centered. (Basically enough to account for discrepancies with the calculated CoM and CoTh from tick to tick.) But keeping the basic rudimentary control the stock SAS.

Active control is very useful for unexpected or unusual circumstances. The isolation method doesn't account for unexpected or unusual circumstances. (A sudden asymmetric thrust situation from a loss of an engine for example.)

[Mahagon]

12 hours ago, shdwlrd said:

We're talking about different methods of SAS. What you're showing is active control to keep the craft in place.

What I'm describing is isolating the craft from errors from the physics engine and certain types of craft updates. And also adding a dead zone where the CoM and CoTh is considered centered. (Basically enough to account for discrepancies with the calculated CoM and CoTh from tick to tick.) But keeping the basic rudimentary control the stock SAS.

Active control is very useful for unexpected or unusual circumstances. The isolation method doesn't account for unexpected or unusual circumstances. (A sudden asymmetric thrust situation from a loss of an engine for example.)

SAS is also an active control,  just missing all the lock on points you would need outside an orbit and the basic stability assist is not locking on to anything - that is why it it prone to long term drift, so having a few more lock-on points would help greatly.

I think @Master39 showed some more advanced Controls. Stability assist is just about the Orientation, velocity, altitude and position holds are more advanced features, that could greatly help with the micromanagement.

That should make maneuvers like Skycrane deploy, flying long routes - while not having to manually adjusting everything for a long duration - achievable for everyone. Without altering the laws of physics. The active control will use the given steering options (gimbal, increase/decrease trust, active surfaces) to take of this micromanagement, so the player can concentrate on something else.

Keeping a Plane in the air for 5 hrs straight, to travel round Kerbin is usually not challenging, but plain boring - however due to not having an assist, you would need to go manual.

I would love an advanced UI where you could basically do a programming like the controllers, but take as an input other variables, like velocity, height, bearing, ... With this option you could however build an autopilot, Killing velocity in x, and y direction, and keeping descent rate at 1m/s*(1+height above ground/1000m)^2 or something.

However I would have build this into the vehicle (and would still need to make sure, that I do have enough Delta-V and TWR to make this maneuver - in this sense it is nothing different from the maneuvering nodes planner.

[shdwlrd]

@Mahagon Yes, what Master39 is showing is more advanced. I can't disagree on that.

What I find is that KSPs physics bobbles and timing of craft updates causes unexpected movements of your crafts. (All the times your VTOLs flips over for no good reason. Or your VTOL starts drifting in an unexpected direction. (South instead of west from the KSP runway.)) What I would like to see is to stopping the weird physics interactions with your craft. And instead of balancing your craft on a pin head, you're balancing your craft on an unsharped pencil. It's still hard to do, but a lot more forgiving than a pin head.

For stock functionality, the orientation hold for the SAS and isolating your craft from erroneous updates from the physics engine would make life easier when it comes to VTOL craft. (Basically all the mirco forces don't effect your craft.)

[Mahagon]

@shdwlrd I have also tried dabbling in the VTOL (Helicopter Type) Crafts. Came to a different conclusion though. The issue I saw, that with sensible VTOL several rotors would be coupled to one engine, that the stabilizer has just the right frequency to stabilize. With the current setup this is impossible to achieve. This causes then little differences in friction forces to translate into huge torque forces as the rotors try to compensate for the friction.

(And torque forces tend to be unexpected: https://youtu.be/fTwPpgBPa2w) For me it seemed again that the Physics is about right, but missing the gear part that kept you rotors going from different speeds, and hence avoiding this catastrophic torque changes. 400rpm tend to be quite unforgiving, tuning down the rpm the lift is smaller but the craft far more stable - but still for me also not stable enough to fly. I even tried test crafts that were symmetric, to be on the pin head, that does not work either.

 

So my assumption would be: If one could couple several rotors to a group, onto which the friction is jointly applied - there would be a much better chance to get something that is stable enough to fly. However my understanding was Helicopters are inherently unstable in the physical sense - without actively stabilizing them they do not work.

Tweaking the Physics for this, may lead to situations where your controls do not work, as some weirdo physics is stabilizing your craft - I would expect docking might be such a case where ever tiny torque counts.

[shdwlrd]

@Mahagon If you ever built a lander, you've made a VTOL.  I've made single engine and multi engine landers. Landers to transfer Kerbals to hundreds of tons of cargo. Varied the vertical location of the CoM compared to the CoTh. All to the same affect, the lander will flip for no good reason. 

You can see this for yourself. Download Angel-125's KFS mod. Make yourself a basic Flapjack with the gravitic engine. Set your hover at 20m. Now don't touch the keyboard. The craft will flip after about 30 sec. If you balance the craft beforehand, it will take about a min, but it will flip. You can cheat the craft to any planet, you will see the same behavior. Just the timing will change. (The reason for using KFS for this test. The gravitic engine will hover in place despite the craft's orientation. It's the best way to study the odd effects of KSPs physics interactions on the craft.)

The only reason is can think of is rouge forces acting on craft. It's these forces that make it very difficult to control a lander and can explain odd behavior when landing a tailsitter.

[EnderKid2]

IRL you're never going to get the COM and COT exactly aligned. People move around, fuel drains, wind applies forces, manufacturing tolerances means the thrust vector of the engine is a fraction of a degree off from ideal. That's what SAS is for. Also from your concern with the vertical position of the COM, I believe you are subscribing to the pendulum rocket fallacy.

[SciMan]

With the joints in KSP not being totally rigid, that introduces some elements to the equation that render the "pendulum rocket fallacy" at least partially valid, if not in its conclusions than in the idea that there are higher-order dynamics at play than just "a rigid body supported by thrust above an infinite plane".
This is because the engines are no longer rigidly fixed to align the COM with the COT (aside from the differences intentionally introduced by engine gimballing).

Instead, you have a flexible coupling between the two.

That means that now the force of gravity and the force of acceleration due to thrust don't act the same on every part of the rocket, which makes the math a whole lot more complex but the gist of it is that it makes things even less stable.

And I'm sorry to inform you that no configuration of thrusters and masses and fuel tanks is statically stable when supported only by thrust. Yes, it will always tumble after some time. No, this isn't because you designed it wrong.
That's why we design our craft with attitude control systems other than purely the pod's own torque and the gimballing of the engine.

Also, if your engines are above your COM and firing downwards, you MUST disable the gimbal on them, or your rocket will spiral out of control in incredibly short order thanks to the game NOT inverting the gimbal inputs to them to compensate for their position above the COM. In this case, it is also mandatory that you have those other means of attitude control that I mentioned.

 

Landing in general (not even precision landing, just "getting on the ground without breaking anything") is not easy, you can't do it if you need to think about what button to press every half second.
The only solution to this is to keep trying until it makes sense and your physical coordination gets to the point that you can handle it (maybe try using a joystick instead of the keyboard, the reason I can't fly planes in KSP is because I use keyboard only and that's just not enough fine-grained control for landing an aircraft on a runway without slamming it into the ground).

Speaking of planes, I hate that all the aircraft I ever make seem to have this habit of "never stopping flying" meaning I can't do a proper touchdown with the REAR landing gear on the craft, I instead have to "fly it into the runway" which is entirely unrealistic because I didn't intentionally design the aircraft that way (and the only way you can make that happen IRL is if you design it in very intentionally).
That means that the front landing gear is what makes contact first, and there's no "skid" to the dang landing gear either without messing with the settings (and the settings might as well be "Tokyo Drift" (no control whatsoever) or "Driving thru thick mud" (control yes, but also so much friction that it will always flip your plane). There's no nice comfy middle ground where it just "skids a little but still obeys steering inputs", at least not that I've found.

So I entirely gave up on the idea of using aircraft, let alone landing them any and everywhere. All the VTOL aircraft I build end up not being aerodynamically stable, and all the conventional aircraft I build end up exploding on landing, so I just gave up since I was already good enough at rockets.

Maybe if you're having trouble with VTOLs and landing like that, you could try horizontal landings? At least on Kerbin it seems like it would work reliably.

[shdwlrd]

41 minutes ago, EnderKid2 said:

IRL you're never going to get the COM and COT exactly aligned. People move around, fuel drains, wind applies forces, manufacturing tolerances means the thrust vector of the engine is a fraction of a degree off from ideal.

Well duh... I know that IRL there are tolerance inconsistencies, mass shifting, weather forces, and general physics that affects rockets and aircraft. But KSP isn't a "real life" simulation, it's a "game" simulation. So being a game simulation, they can fudge a few things to make the craft a little easier to control. That's the point. No unexpected weirdness with a properly designed craft. 

[SciMan]

And what happens when they "fudge" things the wrong way? Or even, the "right" way? Suddenly the physics engine has all these extra knobs to turn, and that means 10 to 20 times the bugs that we already have to deal with.

Goodby Kraken, hello Cthulu.

My point is that making the physics more "forgiving" also makes them less accurate, and without accurate physics the results of a single craft from run to run will be different, and with a game that's all about physics simulation that just seems like a direction they will never go in.

You're not stopping the problem, you're just changing how it's going to manifest.

And to be honest, for what it is, KSP's physics are pretty dang accurate. When I design landers, they don't spontaneously flip.

Would help if you could post a picture of one of your landers that flips so that we can figure out what's going wrong (it might not be the game's fault, convinced tho you may be that it is).

Edited February 28, 2022 by SciMan

[Guest]

Now, every single quirk and bug in the physics engine needs to be squished out and burned to the ground, learning KSP bugs and how to design around them has nothing to do with the difficulty of the game or with flying BUT!

@shdwlrd you seem to be encountering some sort of lack of control authority, when hovering you need all the RCS or reaction wheels you can get. Other than that you need on the SAS to use the radial out and not the retrograde if you want to stand still and not flip in a random direction as soon as you kill your vertical speed. 

[shdwlrd]

10 hours ago, Master39 said:

Now, every single quirk and bug in the physics engine needs to be squished out and burned to the ground, learning KSP bugs and how to design around them has nothing to do with the difficulty of the game or with flying

Yes, it must happen.

10 hours ago, Master39 said:

 you seem to be encountering some sort of lack of control authority

Yes I am, it's called a keyboard. I usually use a gamepad, joystick, or hotas for flight, driving, racing, big stompy sims. If I'm stuck using the keyboard, my control goes from competent to spazzy child that doesn't know what they are doing. (I've never been able to competently control anything with a binary on/off control scheme.)

That's why I rely on autopilots for KSP1. For KSP2, I'm hoping for better control of crafts with the keyboard by adding assists that 1) insulating the craft from physics inconsistencies, 2) by taking some of the very fine control aspects out of the hands of the player

[Guest]

5 minutes ago, shdwlrd said:

Yes I am, it's called a keyboard. I usually use a gamepad, joystick, or hotas for flight, driving, racing, big stompy sims. If I'm stuck using the keyboard, my control goes from competent to spazzy child that doesn't know what they are doing. (I've never been able to competently control anything with a binary on/off control scheme.)

I got used to the keyboard in KSP before starting doing it, but I understand the problem, I recently started to use my DualShock4 controller in combo with mouse and keyboards just so I can pick it up to drive when I get on a car in Cyberpunk, it makes driving way better (while I still prefer m+k for the combat and walking around).

 

7 minutes ago, shdwlrd said:

That's why I rely on autopilots for KSP1. For KSP2, I'm hoping for better control of crafts with the keyboard by adding assists that 1) insulating the craft from physics inconsistencies, 2) by taking some of the very fine control aspects out of the hands of the player

Why not better controller support then? I don't know what are the problems with KSP1 and controllers that precludes you from hooking up your HOTAS to KSP (I honestly never tried to use mine with KSP) but sincerely I hope KSP2 has all the input options it can because I'm totally going to at least use a DS4 with it. 

[shdwlrd]

3 hours ago, Master39 said:

Why not better controller support then? I don't know what are the problems with KSP1 and controllers that precludes you from hooking up your HOTAS to KSP (I honestly never tried to use mine with KSP) but sincerely I hope KSP2 has all the input options it can because I'm totally going to at least use a DS4 with it. 

I'm making the assumption that Intercept will add decent controller support in KSP2. But that doesn't help you if you're traveling with a laptop or don't have access to, or the ability to use a controller to play the game. (Cost, system permissions, or just not allowed.)

My Xb1 controller or joystick don't show as valid controller options for KSP1. I don't have the patience to set them up. Without a button map for my Saitek X-52 (the Steel Series X-52 button layout is different and the software is incompatible) it's painful to setup. A lot of trial and error.

Edit: Let me clarify, I'd rather spend the time setting up my X-52 with full functionality than spending the time setting up the XB1 controller or generic joystick I have. All are just as difficult.

Edited March 1, 2022 by shdwlrd

[SciMan]

There's also such a thing as a landing being TOO precise.

You know, when you set your colony as your landing target, and then instead of killing off your last bit of horizontal velocity right above the landing area for your colony, you do that, but right above all your carefully-constructed colony instead.

EDIT:
On further consideration, that's another point in favor of a "designated landing pad" colony part (or just a "landing pad bulls-eye" that you use other normal colony road/runway/launchpad building tools to build your own pad from, or we could get both several sizes of "pre-set pads" as well as the bulls-eye marker for custom and/or very large pads).

This type of colony/base part would force the target indicator of any vessel that targets the colony to be placed on the coordinates of that landing pad (or center marker) instead of the "root building" of the colony itself (or however else you'd be able to target a colony that as-yet has no landing pads).
If a single surface colony has multiple pads placed, it gets a little more complicated, but from the point of the user it's not that much more to deal with.
Instead of the pad being selected instantly, you will be prompted to pick one from a list of empty pads (out of those that the colony has), with that list also giving you information such as the landing pad's name (which you can set as part of placing or editing the landing pad colony part), and the dimensions of the pad as well as (potentially) its shape (if it's not a "pre-set pad", the game will show "Custom" or when placing the pad down you will be able to set a word or short phrase to indicate the shape of the pad).

I don't see a reason that this system wouldn't be able to do runways as well, now that I think about it. You'd just need a different type of "bulls-eye" indicator (instead being the touchdown markings of a runway), and the addition of various kinds of lights to make it act like a real runway (PAPI, Glide-slope indicators, you know, the things you think of when you think of an aircraft runway that's illuminated at night). They could even potentially include ILS and glide-slope antennas if cockpit instruments are sophisticated enough to let you fly on instruments in cockpit view.

Edited August 1, 2022 by SciMan

[Ember12]

As a potential compromise, what if the trajectory prediction tool had an option to factor in atmospheric drag?  Something that you can tell "I'm going to keep my ship pointed retrograde/prograde" and it will give a rough estimation of the effect of atmospheric drag, based on the drag force that your ship would experience at that orientation.

Of course, it would present only a rough estimate of where you're going to land, which might make it a good solution.  You use this tool to aim roughly at your colony- maybe even from a flyby- but you still have the challenge of braking in the right manner, and executing the landing.

In my view, this would provide a substitute for the intuitive knowledge needed to aerobrake well, without negating much of the interesting challenge of making a precision landing.

[Guest]

8 hours ago, Ember12 said:

As a potential compromise, what if the trajectory prediction tool had an option to factor in atmospheric drag?  Something that you can tell "I'm going to keep my ship pointed retrograde/prograde" and it will give a rough estimation of the effect of atmospheric drag, based on the drag force that your ship would experience at that orientation.

Of course, it would present only a rough estimate of where you're going to land, which might make it a good solution.  You use this tool to aim roughly at your colony- maybe even from a flyby- but you still have the challenge of braking in the right manner, and executing the landing.

In my view, this would provide a substitute for the intuitive knowledge needed to aerobrake well, without negating much of the interesting challenge of making a precision landing.

That's not much of a compromise, it's granted that if we have a trajectory tool it has to take atmosphere into consideration.

The argument here was more about some people asking for completely atuomated landings.

 

9 hours ago, SciMan said:

There's also such a thing as a landing being TOO precise.

You know, when you set your colony as your landing target, and then instead of killing off your last bit of horizontal velocity right above the landing area for your colony, you do that, but right above all your carefully-constructed colony instead.

EDIT:
On further consideration, that's another point in favor of a "designated landing pad" colony part (or just a "landing pad bulls-eye" that you use other normal colony road/runway/launchpad building tools to build your own pad from, or we could get both several sizes of "pre-set pads" as well as the bulls-eye marker for custom and/or very large pads).

This type of colony/base part would force the target indicator of any vessel that targets the colony to be placed on the coordinates of that landing pad (or center marker) instead of the "root building" of the colony itself (or however else you'd be able to target a colony that as-yet has no landing pads).
If a single surface colony has multiple pads placed, it gets a little more complicated, but from the point of the user it's not that much more to deal with.
Instead of the pad being selected instantly, you will be prompted to pick one from a list of empty pads (out of those that the colony has), with that list also giving you information such as the landing pad's name (which you can set as part of placing or editing the landing pad colony part), and the dimensions of the pad as well as (potentially) its shape (if it's not a "pre-set pad", the game will show "Custom" or when placing the pad down you will be able to set a word or short phrase to indicate the shape of the pad).

I don't see a reason that this system wouldn't be able to do runways as well, now that I think about it. You'd just need a different type of "bulls-eye" indicator (instead being the touchdown markings of a runway), and the addition of various kinds of lights to make it act like a real runway (PAPI, Glide-slope indicators, you know, the things you think of when you think of an aircraft runway that's illuminated at night). They could even potentially include ILS and glide-slope antennas if cockpit instruments are sophisticated enough to let you fly on instruments in cockpit view.

That's another great gameplay portion that risks to be cut out of the game by automating the landings.

Landing pads and runway placement respective to other nearby tall building is going to be a huge design consideration if landing is manual, same for ground recover vessels if the supply route system can support multiple crafts (I'd love to have my spaceport with landing pads and runways be a Km or two away from my colony and connect the two via trucks).

"Missed a landing? No problem, this colony is equipped with a state of the art SAR plane specifically designed for such emergencies."

[SciMan]

I think that if you DO get automated launch and landing capabilities, it should be something you earn.
Not by a colony milestone. But instead it should be something that a colony can invest in to enable the functionality for all vessels within that SOI. Such as a "local traffic coordination center" sort of thing to act as a "Space ATC" for incoming and outgoing craft.
And then the automated launch and landing functions would further only work with craft that have compatible equipment fitted, as well as a compatible landing site.

So you'd need the specialized building, the landing pad would have to be built with the idea that you're going to want to land automatically (which could, as you said for manual landing, introduce design constraints regarding what you can build around the landing pad), and the vessel to be landed or launched would also have to have a compatible control element of some sort.

You know the more I talk about it the more it sounds like just MechJeb, but that's not a bad thing.
I like how MechJeb unlocks different capabilities as you progress thru the tech tree. It doesn't let you do all the autopilot things right from the start unless you edit the config files to tell it to do so, which I don't think is the intended way to use that mod.