Flight Automation

[Pthigrivi]

Okay let's talk about something controversial. I know this has come up in the past but rather than necrobump I thought Id see how folks are feeling about this nowadays. I think there are a lot of ways automation could make the game less frustrating, aid in things like milk-runs, stage recovery, cut down on tedious tasks like long overland journeys, etc. but it also has the potential to take the player out of the equation and make the game very boring, where you just click on something and watch the game play for you. It may be that this kind of thing is out of scope for Intercept, but given a lot of the resupply tasks colonies and space stations might require and the desire to control/recover multiple stages at once it might be nice to to see some functionality?

Are you against it entirely? Is there a balance you'd like to see?

[Dr. Kerbal]

I think autonomation should be a big thing in KSP2. But not too big. In real life there are some things a robot cannot do. Or has trouble. I selected the following above because of these reasons. Rovers, yes, its be proven that they can drive from point a to point b. Planes. Ugh, I think real life autopilot would do great. Kerbal autonomation, yes I can make movie now.  And autonomation after tech lock makes a whole lot of sense. In the course of spaceflight most missions were manned. Even with a probe, the probes got commands and not autonomy. Only recently probes can do stuff on their own. 

[Guest]

When we were first speculating about the potential complexity of the colony system the main counter argument was the milk runs and everybody that played a colonization or life support mod knows that.

If you don't solve the milk run problem it forces you to simplify the colonization and resource utilization gameplay down to a couple of mission to set up a fully autonomous system.

Other than that I think both flying manually and unlocking automation with new technology should be part of the gameplay, but I'd like to see some basic autopilot features like altitude or heading hold.

[jastrone]

ok kerbal task automation just makes sense why wouldnt you want it. and i think manuever automation could work as a higher tech as I often find it annoying to turn large ships around since you couldn't timewarp while turning in ksp1. but i dont think you should fully be able to automate colonies atleast if you want to expand them

[Guest]

One thing that's not listed is automation through scripting.

I strongly dislike the idea of out-of-the-box MechJeb style automation (i.e., something like a built-in autopilot that you can tell "fly to orbit" or "land on the Mun at this location"), as that would invalidate one of the main pillars of the game, namely, flying the craft you design.

However, I am very much in favour of scriptable parts with inputs and outputs, so that for example you could write an auto-landing script yourself if it tickles your fancy. If these scripts are easy to share, so much the better.

I am also very much in favour of systems that reduce grind and busywork. An abstracted-out system for supply runs is pretty much a requirement for the mid/late game, otherwise the game would become soul-crushingly repetitive. Tech-level restricted limited automation would fall into this basket. Things I would like:

• Automatic execution of manoeuvre nodes (restricted by tech level and pilot experience)
• Basic atmospheric autopilot (hold straight and level, fly to waypoint, also restricted by tech level and pilot experience)
• Auto-landing if and only if it's well integrated into other gameplay systems and produces emergent gameplay. For example, once at a sufficient tech level, let us build auto-landing support into landing pads and runways, so that craft that also have support for it built in (and sufficient fuel etc) can then auto-land there.

Summa summarum, I'm in favour of automation if and only if:

1. It doesn't invalidate core gameplay systems (e.g. flying the craft you design)
2. It eliminates busywork (e.g. repetitive milk runs)
3. It creates opportunities for emergent gameplay (e.g. researching and building infrastructure for auto-landing, writing and sharing various auto-pilot scripts)

Edited May 18, 2021 by Guest

[mcwaffles2003]

The term "automation" seems to have different meanings between the choices or perhaps I'm misunderstanding what you mean by automation... Does it mean that the task is run in the background and is accounted for (like the stage recovery mod) or is it referring to something more like an autopilot (like mechjeb)?

I will explain my preference with some detail:

The games automation system should start out like KSP did, with none. As a player progresses to obtain certain technologies more types of automation should be allowed. The techs should be balanced in a way that it isn't possible to race through them. And when a player receives the new level of automation they should have a feeling of something like "well that would have come in handy on the past several missions..."

1. The 1st unlock should allow for prograde/retrograde locking and shouldn't be unlockable until manual orbit is achieved. (The player needs to know how to make a passively stable craft)
2. The 2nd unlock should allow normal/anti-normal and radial in/out and shouldn't be unlockable until several orbits have been achieved and an orbital rendezvous has been accomplished. (The player should get a visceral feel for why they point in any of these directions on their own before they discover these directions actually have special names and purposes. Essentially they should get the hang of manually flying to change their orbits)
3. The 3rd unlock should be target/anti-target locking and only be achievable after multiple docking missions in kerbin oribt (The player should learn to dock manually and get a feel for where RCS should be placed so they strafe to dock before they fall into "point at port from awkward angle and go forward") (Also, the game should be able to prevent people from cheesing this mission by recognizing the both craft are from different launches and not simply one craft that undock and boosted to redock quickly)
4. The 4th unlock should allow precision heading locking (custom pitch, roll, yaw) (At this point it is just a treat to aim for before larger automation systems start kicking in and should be awarded after the first mun or minmus landing mission)
5. The 5th unlock should be automated maneuver nodes and shouldn't be unlockable until the player has established their first resonant orbit communications network around kerbin (By this point the player should have had plenty of flying experience and have gone through several of the frustrating moments where precision firing really matters and 0.2 m/s  differences can cause lasting problems with synchronization)
6. The 6th unlock should be crude automated landings systems that operate only without atmospheres and shouldn't be unlockable until the player has landed on both then mun and minmus as well as demonstrated manual precise booster recovery. By this I mean they have landed a booster within the KSC after a full orbit. (The player should have a good understanding of how to land a craft and the difficulty of managing horizontal movement)
7. The 7th unlock should be a maneuver planner (does not include brachistochrone trajectories) and shouldn't be available until they have sent a craft to another planet, established orbit, then returned the craft back to kerbin orbit and safely recovered the craft. (The player should have a good feel for making Hohmann transfers by now and a feel for making interplanetary missions)
8. The 8th unlock should be a docking autopilot and shouldn't be unlockable until several docking missions have been completed in orbit of another planet (By now the player should have plenty of experience  with docking manually)
9. The 9th unlock should be a launch autopilot  that allows the player to plug in a rough ascent profile and should be available after the player completes launches from colony launchpads  from 2 different planets with atmospheres besides kerbin (By now the player should have more than enough experience launching from multiple atmosphere types and has mastered launch profiles)
10. The 10th unlock should be a precision landing autopilot that operates in atmospheres and can de-orbit and shouldn't be made available until the player has landed on every body around kerbol with an atmosphere (The player by now should have mastered de-orbiting and landing in thick and thin atmospheres with high precision in hitting target landing sites)
11. 11th unlock should be brachistochrone maneuver planning and should be made available after an interstellar colony has been established in two other systems. (By this point the player should have a handle on planning interstellar transits)

The autopilots I mention I envision to have many parameters for the player to use to specify what they desire the autopilot to do. Docking autopilots should allow the player to dictate the orientation of the craft as it docks for instance, launch autopilots should have parameters for the altitude of the circular orbit they are meant to achieve, landing autopilots should allow the player to designate a landing site.

I think these are all reasonable checkpoints for people (obviously order and conditions are up to debate). Those that have achieved them should at that point have a very good handling on the mechanics involved manually executing the relevant maneuvers and understand fully why the autopilots are doing what they are doing. I believe this game will be extraordinarily more complex and ask players to complete orders of magnitude more flight missions and to those that want to progress and manage an interstellar space civilization/network should be afforded  these quality of life features in stock to allow them to macromanage more fluidly and gain focus on not just flight but mission planning as well. I think we all want to live vicariously as our own Buzz and Neil , but I know I would also like to experience being an administrator and planner as well and do not think I am alone in this nor do I feel I am wrong or out of place to hope for it.

I have not mentioned in here automation in the form of custom written scripts as in kOS. I do hope something similar is included and even perhaps a VPL to allow greater accessibility for non programmers. This would allow for much greater nuance in planning and seeing ones own vision of a mission be completed as they see fit. I also see plenty of potential for players to learn new skills that would be practical in the real world as those uninitiated to the programming world would be given an opportunity to use code not to just display some text or execute a sorting algorithm, but actually fly a rocket. What an inspiring and motivating invitation to those beginning to learn code. That said, nothing like this has been confirmed, none the less hinted at.

I have also not mentioned how colony automation should be implemented as we have little information to work with on how colonies will even work and I feel talking about automation with such little information to be a bit premature. That said, I am happy "milk-runs" have been confirmed as running all those missions would take an extremely long time and become more of a chore than exciting creative play as well as a distraction from the greater game at hand.

 

EDIT: One thing worth considering also would be mass or dimension limits for the autopilot features so only landers of a certain mass/size could have automated landings and only rockets below a certain threshold could have automated launches or docking procedures and further researches could upgrade these limits.

Edited May 18, 2021 by mcwaffles2003

[Pthigrivi]

Nice breakdown @mcwaffles2003 . It's probably a sticky wicket not knowing much about what Intercept has planned for release or after or what they'd rather leave to mods. Given the ambition of the currently stated scope I think SOME form of automation will be important, especially for colonies. This could of course be abstracted by more or less 'magic' transfers of resources, but if there were other reasons to implement mech-jebby functions maybe there's a way to kill two birds. A couple of examples that could be really cool:

1) You build a mining base on Ike that harvests ore and uranium, and a base on the surface of Duna that produces ore and life support. You then build tankers that ferry both those resources to a station in orbit above Duna where you're building a big Jool or interstellar vessel. Each tanker does a proof-of-concept run where the resources are loaded and brought to the station. The Ike tanker then draws off some LS to keep the miners happy, and the Duna tanker loads on some Uranium to keep the lights on at your Duna base and both return to their origins. The player can then set a schedule for how often these flights repeat and the automated system does the rest. If you miscalculate your inputs and the identified resources aren't present when the next leg is scheduled to depart a little warning pops up to tell the player to adjust. 

2) You have a colony on the surface of the Mun thats a few kilometers from a very rich source of He3. You build a harvester rover that can mine the ore, send it out to the extraction zone, run it until it's full, then return it to the base where it unloads for processing. You then build multiple copies of that harvester, set waypoints in the He3 deposit and set a schedule for them to drive out and return. 

3) You do a Spacex style test-launch of a lower stage, sending it to the approximate altitude and distance you plan to separate, do your back burn, and fly it back down to a landing pad at KSC. Later you can set that subassembly to execute that maneuver when staged so you can follow your second stage to orbit knowing the game will (probably) land your first stage safely. 

4) You have a crew compliment of 6 for a first-landing on Pol. You tell everyone on the vessel to disembark, where they then begin wandering around, ogling the landscape, causing little antics etc. You can then click on any of them without switching vessel and issue commands to plant a flag, repair a landing leg, collect surface samples, set up a long-term science experiment, etc, at without micromanaging each task. 


Im sure given just how complex players' vessels' and different conditions are this is probably a hugely complicated thing to program, but it could also really make this game if done well. It might be nice for instance if timings and quantities of resources to be transferred were stored in the schedule and could be adjusted on the fly. This might make the interface a little more cumbersome but it would save players time having to repeat tanker-runs with only small corrections to onloaded/offloaded resources. So long as players understood the system wasn't flawless and there were warnings when problems arose (Insufficient resources at departure point! Specified docking port blocked at arrival point!) and players could make manual corrections I think it could be an amazing system.

Edited May 18, 2021 by Pthigrivi

[Admiral Fluffy]

My favorite idea is cosmetic, but i would also like rover automation.  Like the rovers drive around and do stuff. I would also like auto Ion Engine craft.

[Guest]

6 hours ago, mcwaffles2003 said:

I think these are all reasonable checkpoints for people

Honestly I don't think so, to me those would feel like grind for experienced players and leave new ones without a tool as crucial as the maneuver planner for too long while automating things that are genuine flying gameplay loops like learning how to pinpoint land too early.

I'd leave all the takeoff, rendezvous docking and landing automation for the supply route system and not bring them to the flight scene (well, maybe something for booster recovery).

[shdwlrd]

I think in flight automation should be available from the very beginning of the game. It's a case of they're there if you want to use them, you can ignore them if you don't. Just like in real life.

(On a side note, I have to ask this. I don't know why everyone wants to punish the experienced players in the early game who don't want to execute their planned maneuvers anymore?)

Rover automation is a must. There's other things that can be done instead of driving from point A to point B. Especially when driving at safe speeds and you have to cover a long distance on an established route.

Background automation for resource logistics is going to happen no matter what. Why give a reason and plans for it. The let the devs figure it out.

Idle automation could be fun or frustrating to see. Just seeing the Kerbals wondering around because they're bored would be cool.

[PlutoISaPlanet]

We know automation will be in the game for colonies, so why not give us some more?

[Pthigrivi]

58 minutes ago, PlutoISaPlanet said:

We know automation will be in the game for colonies, so why not give us some more?

The main question is whether colonial supply routes will be simulated by in-game craft or just implied by magically transferring resources on some set schedule. If you were there at the right time it might be cool to see supply tankers automatically landing on the roof of your off-world VAB, but I don’t think that’s necessarily reason enough to physically model it. I think it only makes sense if other autonomous flight systems were already going to be part of the game for other reasons. 

[Guest]

1 hour ago, shdwlrd said:

(On a side note, I have to ask this. I don't know why everyone wants to punish the experienced players in the early game who don't want to execute their planned maneuvers anymore?)

I don't think anyone here wants to punish anyone else.

It's about incentives. The fact is that people respond to incentives, and gamers playing a game will gravitate to the easiest way to play it. If you give them the option to automate manoeuvre node execution or various other flight things from the get-go, that's what they'll go with, and it'll become the primary way to play the game. Flight will become an optional gameplay mode. 

Any game needs a  focus and a few central activities it's built around. Supporting systems have to make those core activities more enjoyable, engaging, and exciting. Like, if you're making a shooter and decide to add RPG elements, these elements have to enhance and enrich the core experience which is shooting things; if instead they detract from it or make it optional, the end result isn't going to be as good.

If your intention as a game designer is to make a vessel design + colony building + resource management game, then it would make more sense just not to implement flight and all the physics associated with it. It's  a huge effort. Instead, put that effort into making the vessel design + colony building + resource management that much deeper, richer, more complex, and more engaging. It could be a terrific game if done properly. It just wouldn't look much like KSP at all.

The central activities in KSP2 are building air- and spacecraft, flying them, and using them to explore exciting new worlds. The colony aspect supports that: it creates gameplay reasons to design, fly, and explore, and creates new opportunities for designing, flight, and exploration.

Therefore, I believe that any feature set or subsystem in KSP2 has to support that core set of gameplay activities. If instead it conflicts with or dilutes them, it shouldn't be implemented in the first place, and that effort should be spent on something that does support and enhance them instead. This is the case with certain types of automation. For the same reason, it's important that automation is only unlocked at the point when the manual stuff would otherwise become rote and repetitive.

Finally, since KSP2 is intended to be so moddable, I'm pretty sure that there will be mods out quite early that unlock whatever gates the game puts this kind of thing behind, so KSP1 veterans who are bored of flying things can get what they want too.

[Burning Kan]

TL;DR

with this two mods u can do almost everything automaticly

 

[PlutoISaPlanet]

2 hours ago, Pthigrivi said:

The main question is whether colonial supply routes will be simulated by in-game craft or just implied by magically transferring resources on some set schedule. If you were there at the right time it might be cool to see supply tankers automatically landing on the roof of your off-world VAB, but I don’t think that’s necessarily reason enough to physically model it. I think it only makes sense if other autonomous flight systems were already going to be part of the game for other reasons. 

Thats true! Either way would be fine for me, but I prefer it to actualy happen in game because that is more realistic and requires the right transfer window.

[SOXBLOX]

I am in favor of any automation, especially of milkruns and dockings. Recovery of reusable lifters should also be automated.

I paused when I came to "cosmetic automation". These colonies are going to have hundreds of thousands of Kerbals in them. If cosmetic automation happens, it has to make me believe that there are really that many Kerbals in the colony. There is little I hate more than out-of-scale objects in a diorama. These colonies should be to scale, both in terms of visible population and physical size.

[mcwaffles2003]

7 hours ago, Master39 said:

I'd leave all the takeoff, rendezvous docking and landing automation for the supply route system and not bring them to the flight scene (well, maybe something for booster recovery).

My honest guess is that the milk run simulator wont even be physically simulated so as not to bog down the game in the late game. I assume by that point there may be 100's of craft in flight simultaneously.

Also, I know we've talked about this level of automation in the past and believe we have fundamental disagreements where too far or too much occurs. I know I'm susceptible to getting overly emotional over the keyboard here so I'll just state that I respect your position on the matter but disagree and hopefully leave it at that.

7 hours ago, Master39 said:

Honestly I don't think so, to me those would feel like grind for experienced players and leave new ones without a tool as crucial as the maneuver planner for too long while automating things that are genuine flying gameplay loops like learning how to pinpoint land too early.

For the parts of automation that we do agree should exist in the game do you have a different idea for how/when checkpoints would be achieved? I stated reasons for each of mine and the overall intent behind them all was to ensure the player has enough experience in each maneuver to have hopefully learned why the automation acts as it does when executing maneuvers for the player.

@PthigriviI'm  curious as to how milk-runs will actually be implemented seeing as relative positions between planets will change, there for dV requirements for transport between nodes in the supply network will change. I agree a proof of concept flight should be used to prove a milk run with that specific ship and mass payload be possible but wonder how flexible that will be ultimately.

[swjr-swis]

Kerbals doing cosmetic stuff when they're standing around idle would be nice... it would add some life to the game.

As for other forms: as long as I can leave it off when I want to fly and do things myself, I don't mind some forms of automation being incorporated into the game. I would prefer it to be something programmable though, be it through scripts or by triggering action groups through certain inputs. That way I am still responsible for getting it set up correctly in the first place, and I retain the flexibility of adapting it to emerging circumstances (read: I forgot to add deploying the chutes again, didn't I? Ok, panic).

[Jack Mcslay]

I think you should be required to do every route before that same route can be automated, including transferring from body to body with high orbital eccentricity, although It could be made an exception for rovers at low speeds (<10m/s)

A moving moho base which you order to be constantly in the light by slowly circumnavigating it would be neat.

[Guest]

10 hours ago, mcwaffles2003 said:

Also, I know we've talked about this level of automation in the past and believe we have fundamental disagreements where too far or too much occurs.

Yep, I already knew your position and I was just stating mine in this topic to avoid repeating ourselves, no arguing intended.

 

10 hours ago, mcwaffles2003 said:

For the parts of automation that we do agree should exist in the game do you have a different idea for how/when checkpoints would be achieved? I stated reasons for each of mine and the overall intent behind them all was to ensure the player has enough experience in each maneuver to have hopefully learned why the automation acts as it does when executing maneuvers for the player.

I would give al the data to the player from the start, maneuver node and planner included, and make only the automation unlockable.

As for how exactly I don't know how the tech tree is going to work but I would put a branch for automation in there.

[mcwaffles2003]

3 minutes ago, Master39 said:

I would give al the data to the player from the start, maneuver node and planner included, and make only the automation unlockable.

As for how exactly I don't know how the tech tree is going to work but I would put a branch for automation in there.

I feel like if a maneuver planner was handed to a player from the start they'd skip getting an intuitive sense for orbital mechanics like changing orbital inclinations, setting up a rendezvous, or creating Hohmann transfers. I think all the data should be available to the player but having something that places nodes for the player from the start seems like it skips a lot.

[Pthigrivi]

12 hours ago, mcwaffles2003 said:

 

@PthigriviI'm  curious as to how milk-runs will actually be implemented seeing as relative positions between planets will change, there for dV requirements for transport between nodes in the supply network will change. I agree a proof of concept flight should be used to prove a milk run with that specific ship and mass payload be possible but wonder how flexible that will be ultimately.

I know, its not a trivial problem and may be the reason they go for magic transfers in the end. As anyone who’s used Mech-jeb knows a player can very often execute more efficient landings than it does, and if your proof-of-concept manual mission cuts it too close the game may not be able to replicate that without running out of fuel 300m above your colony. Like you said even one transfer window to the next carries different dV requirements esp. with inclination changes. That might be solvable by encouraging players to leave a healthy safety margin or only allow scheduled transfers with equal or less dV than the craft, but there are a lot of other challenges as well. If a player does something tricky like a Minmus-LKO fuel tanker that relies on high-AoA aerobraking to lower its apoapsis (as I often do) will the game be able to replicate that performance? Even the routing could get very complicated. Like if late in the game you’ve got a high-isp resource transfer vessel ferrying various resources from moon to moon around Jool, rendezvousing with higher thrust landers and stations and spaceplanes from laythe... what would the UI look like that could help players manage timings and balance resources for all that? This is a question even if the supply routes are magic, but physically modeling all of the components doesn’t make it easier. 
 

As far as the progression/timing discussion goes, I think there’s a big difference between the maneuver planner as currently available in KSP 1 and an automatic maneuver generator like the ones found in Mech-Jeb. The former really should be available right from the beginning so players can do their first orbital circularization burn. The latter I think falls into that give-a-man-a-fish zone where players might learn more from being given a tutorial and a transfer window date (or even a porkchop graph?) and let them noodle out the hohmann maneuver themselves the first several times. In fact I kind of think all of the current lock-on functions for prograde, normal, radial etc.  should be available from very early on but all of the other things we’re discussing (maneuver execution, auto-land, etc.) should be held back till after you’ve started building colonies. You could even have them unlock based on total off-world population, the idea being your spacefaring civilization is now producing kerbals experienced enough to fly themselves. There might be some nuance here with probe control but overall that seems like it would guide new players to learn the fundamentals and then provide handy time-savers much later in the game. 
 

 

Edited May 19, 2021 by Pthigrivi

[Pthigrivi]

Some things that might help not just supply routes but other systems like multiplayer and overall resource management:

1) Gather all resource transfers into one window with tabs for different resources rather than dozens of right-click menus. The parts could highlight when you hover over the item in the window and you could then set each container to fill or empty by toggling flows and clicking on target levels. It might even be nice to allow multiple containers to be saved as groups if for instance you had a big set of H2 storage tanks at a base or station or wanted to balance multiple radially attached fuel tanks for weight. 

2) Station/colony command/core modules through which resources deliveries could be scheduled and resources managed. You could automate deliveries, select preferred storage tanks, monitor inputs/outputs, etc. They could also be used for probe control, colony crew management, or even maybe station keeping if they were orbital (I find mine move around a bit after repeated dockings).


And one more little note: I'm maybe most interested in being able to issue Kerbals commands in addition to direct control. I just think the EVA experience with multiple crew running around doing things would be easier and more satisfying. It's probably also a really good thing for new players getting used to EVA. I remember early on some terrifying experiences overcorrecting and losing track of my vessel as I flew off into space. Exhilarating as that was it was also frustrating, and might have been nice in a moment of panic to have the option to "return to vessel" and have him/her pilot back. Easier and less restrictive than umbilicals. 

Edited May 19, 2021 by Pthigrivi

[modus]

Wouldn't something like WOLF (part of MKS by Roverdude) be implemented to transfer resources, so you wouldn't have to actually fly everything?

Edited May 19, 2021 by modus

[shdwlrd]

23 hours ago, Brikoleur said:

I don't think anyone here wants to punish anyone else.

It's about incentives. The fact is that people respond to incentives, and gamers playing a game will gravitate to the easiest way to play it. If you give them the option to automate manoeuvre node execution or various other flight things from the get-go, that's what they'll go with, and it'll become the primary way to play the game. Flight will become an optional gameplay mode. 

Any game needs a  focus and a few central activities it's built around. Supporting systems have to make those core activities more enjoyable, engaging, and exciting. Like, if you're making a shooter and decide to add RPG elements, these elements have to enhance and enrich the core experience which is shooting things; if instead they detract from it or make it optional, the end result isn't going to be as good.

If your intention as a game designer is to make a vessel design + colony building + resource management game, then it would make more sense just not to implement flight and all the physics associated with it. It's  a huge effort. Instead, put that effort into making the vessel design + colony building + resource management that much deeper, richer, more complex, and more engaging. It could be a terrific game if done properly. It just wouldn't look much like KSP at all.

The central activities in KSP2 are building air- and spacecraft, flying them, and using them to explore exciting new worlds. The colony aspect supports that: it creates gameplay reasons to design, fly, and explore, and creates new opportunities for designing, flight, and exploration.

Therefore, I believe that any feature set or subsystem in KSP2 has to support that core set of gameplay activities. If instead it conflicts with or dilutes them, it shouldn't be implemented in the first place, and that effort should be spent on something that does support and enhance them instead. This is the case with certain types of automation. For the same reason, it's important that automation is only unlocked at the point when the manual stuff would otherwise become rote and repetitive.

Finally, since KSP2 is intended to be so moddable, I'm pretty sure that there will be mods out quite early that unlock whatever gates the game puts this kind of thing behind, so KSP1 veterans who are bored of flying things can get what they want too.

What incentive is there for a veteran KSP player to prove that they know how to do an orbital maneuver, a proper gravity turn, an orbital rendezvous, docking before they can automate it? There is none. So the question stands, Why punish the veteran KSP player by forcing them prove their skills and understanding of the game mechanics before you can automate them?

Everyone seems to be under the impression that to enjoy the game, you must know how to do the necessary skills. Or put another way; I had to learn these skills, so must you or prove that you know them before you can have an autopilot. That's kind of dictating how to play KSP.

My point is "I don't care if you want an easy or hard way to play, as long as you're playing and enjoying KSP, that's all that matters." 

A new player will have to learn a ton of new things. Why force them to master the flight skills the veteran players had to master before you can use an autopilot. 

It seems to me that everyone's thinking is to enable the easier play modes, you have to beat a game using the hardest game mode. What about the player you just wants to go though the story and casually do what is needed to beat the game?