Automation, not Autopilot.

[Tweeker]

I posted this in another topic on probes, but I don't think the distinction I was trying to make was entirely understood.

In the topic people where advocating for some degree of automation of probes. I suggested that a stock probe, or rover might be positioned in orbit, or on planet. Then turned on, it then goes off to do it's own thing. The player would then have to retrieve it later for a science turn in.

In my mind this is different from autopilot, which squad says they think would take away from the game. Once turned on the probe acts autonomously, but they player has no control over where the probe goes. This is an important consideration because one of the goals of an autopilot is to fly where you want, not just to fly around.

When the probe is deployed it would make a course correction and an additional number of pseudo-random course corrections during it's orbit, so it would not be as if a kerbal could turn the probe on and then wait right next to it for it to finish making science. Instead they would have to go and collect it from wherever it ended up. That would add more variety to the standard routine of go, do science, return. And if I'm honest the rote nature of collecting science is one of the things that could stand improvement.

Having a probe that acts in such a way would also mean that the player would have to be careful to deploy it in an orbit that would ensure it would not end up crashing into the planet or shooting off into space. All these point, I think, are strong arguments showing how autonomous probes would enhance gameplay.

[Justin Kerbice]

Good idea.

An example where this feature could be REALLY useful: a SCANsat satellite probe which keep the SAR array pointed to the targeted body whatever the orbit is

(it needs to keep track of available monopropellant if it used RCS to rotate).

[Red Iron Crown]

What you are describing is an autopilot, just a primitive one in which no changes to its programming can be made once activated. A ship with a probe core and a kerbal on board (a not uncommon situation) would be a ship with an autopilot that the kerbal deactivates to make programming changes.

Not that it's a bad idea, just pointing out that the difference between automation and autopilot is largely semantic.

[Tweeker]

In the strictest sense SAS is an autopilot. Turn your rocket, or airplane to a bearing of 90 degrees, horizontal, and it will fly in that attitude hands off until it runs out of fuel.

So while it may similar to an autopilot, I think it is different enough from what squad describes as autopilot to merit discussion. It would not make things simpler, it would be more difficult.

[Red Iron Crown]

So, how sophisticated would you want it to be? How complex a maneuver should it be capable of? Can it be turned off once activated? Is a kerbal required to do so?

Not trying to criticize here, just get a better idea of what you're envisioning. And I agree it is an idea worth discussing.

[Kegereneku]

I don't want to be harsh but many people here couldn't fly without an autopilot (which is just a lot of automation), which isn't standard in the game.

Myself I see no reason to not propose a sort of simplified Mechjeb in the late game, not because I can't do anything manually (I am a Orbiter player) but because it's boring on the long.

Furthermore, in the gameplay, probes serve the important purpose of being an cheap, easy and dispensable way of acquiring Science-point which would be extremely hard and slow if we had to send a Kerbal everywhere.

Automated probes is a fundamental part of Space Exploration regardless we like it or not, and there's no interest for a probes that land at randoms locations, just as there's no reason to keep a probes from being able to send the result of its experiment from place where you couldn't land and retrieve Kerbun (like Eve).

[Tweeker]

Not offended at all.

Basically your control over it would be limited to where it is deployed. There would be an ideal orbit for it to be released in, one from where the course corrections it would make couldn't end up crashing into the planet or shooting into space. Beyond that it would be fully automatic. Turning it off, or controlling it wouldn't be a option, and it would be "unkerbaled"

It would fairly small, maybe like a like a stayputnik + some sensors, a docking port, some small maneuver thrusters, and a battery. I think ideally it would need to be a "black box" unit, rather than part that could be built up.

[Red Iron Crown]

I must be slow, I'm still not understanding what the unit would do. If you deploy something in a non-atmospheric orbit, it's going to stay in that orbit indefinitely without any need for course corrections.

[Tweeker]

the course corrections would be for gameplay reasons, rather than orbital stabilization or optimization. So that you could not just turn the probe on, orbit right next to it, and recover it.

By performing these course changes and going away from the initial orbit the probe creates additional gameplay. Also I think it would dovetail nicely with contracts; take this probe to optimal orbit, release it and retrieve it later. Get science, reputation and cash.

[Camacha]

You could build something like this with kOS That way you can decide for yourself how far and random you want to take things.

[coolitic]

You are basically suggesting auto-pilot but are just using a different word.

Admins should start banning people who keep posting do not suggest (for a week or so). I don't necessarily mean you OP

[eurybaric]

Agreed.

Furthermore, a good argument (and purpose) IMO would be that when you're sending a probe to a far off planet - well, Even the moon for that matter, telemetry back and forth to that probe would take time. I mean (and here I'm thinking about it while I type), how the heck do we have instant control and camera views and whatnot for a probe that's on the other side of the Kerbol system? It doesn't make sense, and it's much less immersive than having the probe be automated.

Picture this. You launch a rocket with a payload consisting of a service module (manned) and a probe. Get it to LKO let's say. Separate the the service module from the launch vehicle remains, and shoot for Mun tugging with you the probe. Enter a precalculated orbit around Mun - and that would depend on how you've automated/programmed your probe. Say 80x80km circular equatorial orbit. Activate probe and separate. Return with the service module to Kerbin. On the probe side, once it has been activated, it begins executing its predefined set of instructions.

For example, these would go like this:

1-Complete one orbit while probing the equator for landing sites.

2-Change orbit inclination to 45 degrees.

3-Complete a set of orbits mapping the surface.

4-reducing periapsis to 15 km

5-scan for dust and/or composition of atmosphere (yeah I know in ksp mun has no atmosphere ) and activate applicable science experiments.

6-circularize orbit

7-go back to equatorial orbit

8-Sleep mode and wait for retrieval by subsequent manned mun mission.

Well, Mun wasn't really a good example (being close and boring and all hehehe) but you get my point.

and of course back on the ground (or in a manned ship) we could still send and recieve some basic info/instructions like abort mission, some visual feed, shutdown, etc..

EDIT: My post is replying to the OP.

EDIT2: I think I must finally check out that KoS thing ((:

Cheers!

Edited March 1, 2014 by eurybaric

[Nuke]

i think the jist of what this suggestion is really asking for is npcs. you want things in the universe that are not directly under the control of the player so that the player has something to interact with as part of the mission.

[Whirligig Girl]

You are basically suggesting auto-pilot but are just using a different word.

Admins should start banning people who keep posting do not suggest (for a week or so). I don't necessarily mean you OP

No, autopilot is a control over where you want to go, like mechjeb.

automation is more like The Sims on free-will mode, you don't control them, and you can only watch as they ruin their life or help their own life.

[Whirligig Girl]

i think the jist of what this suggestion is really asking for is npcs. you want things in the universe that are not directly under the control of the player so that the player has something to interact with as part of the mission.

Player Characters creating Non-Player Characters? Cool.

[Nuke]

think about it, once the launcher and the space center than operated it does its job, they are done. the satellite or probe get handed over to the control of the people who paid to put it up there. space agencies dont micromanage everything launch. if you take a contract to put up a probe you are done as soon as you separate it, its not your payload.

[Dunbaratu]

It all comes down to where you want the wall between "player's space agency does it" and "someone else on Kerbin does it" to exist.

Sometimes the work that real-world people did in the space program is abstracted away so far in the KSP game that the player has no say in them - for example the engineering decisions about the dimensions that rockets and fuel tanks have, and the work to make a liquid engine that won't blow itself up. These were not easy at all, but the player doesn't have to worry about them in KSP. The presumption is that other companies handle that and got it all working for you. Whereas, the top-level decision about how to put those parts together, how many stages the rocket should have, and so on are in the player's hands. So SOME of the stuff is in the player's hands and some is abstracted away and assumed to be done by other Kerbal people outside the scope of the game. So the question really just boils down to this and this alone:

Given that the task of programming a working computer automation system is still a thing done by people, not by the computers themselves, how much of that task should be in the player's hands and how much of it should be abstracted away and presumed to be done by other people outside the scope of the game?

That's really all it comes down to. Nobody is claiming that an autopilot is unrealistic, just that if it works perfectly out of the box regardless of what the player does, then it removes from the player that aspect of the game and puts "making the autopilot" into the realm of "stuff the player assumes some other Kerbals somewhere else on Kerbin did for you."

This whole "automation not autopilot" title is a misnomer. It's still an autopilot system - but just one in which the player is assumed to be the programmer at the topmost level of putting it together. Only the primitive steps are abstracted away, not the top level decision of how to assemble them together.

Whether or not the piloting has automated help outside the player's control is not a boolean yes/no. It's a continuous sliding scale. Even in the stock game there's a lot of computerized help for the pilot. Setting a maneuver node and getting a prediction out of it about where it will send you if you burn that way, and whether or not your movement will be timed to coincide with a planet's arrival and thus form an encounter is a really hairy mathematical problem that your onboard computer is calculating for you.

So it's just a matter of where you want that sliding scale set. It's never going to be 100% player control (it *already* isn't in the stock game), nor is it going to be 100% outside the player's control either (because then why is the player there?).

And furthermore, as the mod kOS demonstrates, having an autopilot doesn't have to imply having one that other people made. You could have one that YOU made.

So the distinction between "player controlling it live as it happens" and "player controlling it, but doing so ahead of time by making an autopilot" and "player not in control because somebody else's autopilot is doing it." is important.

The arguments that real astronauts don't have to fly manually and therefore you should let someone else's software fly for you sort of ignore that rich middle ground between the two of having an autopilot that YOU had a hand in making fly the craft. So you're not flying in real-time manually but you, ultimately, are still the one responsible for how it flies.

I'm not sure a thing like kOS is ever going to have wide enough appeal to be in the stock game, because it's very much the sort of thing that a person who's done a small amount of programming can pick up quickly but for someone who hasn't programmed at all before it can be a bit of a steep learning curve.

BUT, that being said, there may be room for something a bit further on the slider toward "game provides it for you" than kOS is, but not quite as far over in that direction as, say, making Mechjeb stock would be.

If you've ever played the old PS1 game called "Carnage Heart", a thing like that might work. (In the game you programmed your mechs to fight other mechs, and your program was basically a bunch of command tiles you dropped onto a slate to make a visual flowchart.)

[Tweeker]

An autopilot is a pilots aid, it does things like maintain stability in the 3 axes of flight, maintain a set altitude or air speed. Navigate to waypoints, etc.

This would in NO WAY aid the player in fly, or navigating or gathering science. It would be HARDER than the current means of gathering science. Because the player would have NO CONTROL over the probe's flight, other than where it was released.

As an example:

The Kerbin surveyor, to me launched from a 200K orbit.

It would be a "Black Box" unit, all the player could do is turn it on, and collect it later.

After being flown to orbit and launched it would

1) make a separation burn,

2) make a inclination change.

3) increase apoapsis by up to 100 KM

4) decrease periapsis by up to 100 KM

5) turn it's docking port north.

It would then be up to the player to go and get the probe to earn their science, instead of the current model which is very grindy, and which adds little gameplay to the game. This stands in stark contrast to the Mechjeb, KOS et al, because it doesn't aid the player in any aspect of flying, maneuvering or landing. That is why the distinction between autopilot and automation is important. If you classify it as an autopilot on technicalities then it can easily be dismissed under the "what not to suggest" list. Instead of playing semantics gottcha look at the gameplay enhancements.

[stupid_chris]

Everyone go back on track, this isn't a debate on what is and what isn't an autopilot. This thread is good to go, so keep it clean please. Thanks.

[rkman]

If the idea is that an automated probe or rover does its own thing - while it does not have focus, that would first require a more fundamental change to ksp so that craft that have no focus (and are out of physics range of the craft that does have focus), can do anything at all other than being on rails.

[Red Iron Crown]

It could be implemented in such a way that it changes its orbit Hyperedit style, no need to stay focused on the probe while it does its thing.

[Tweeker]

I was thinking about that, and I wondered if it could simply disappear once it's beyond the physics boundry, and then reappear after it has run it's course. Not ideal, but it would require fewer changes to the game.

[Dunbaratu]

This stands in stark contrast to the Mechjeb, KOS et al, because it doesn't aid the player in any aspect of flying, maneuvering or landing. That is why the distinction between autopilot and automation is important. If you classify it as an autopilot on technicalities then it can easily be dismissed under the "what not to suggest" list. Instead of playing semantics gottcha look at the gameplay enhancements.

Why are you pretending this is in contrast to kOS when it isn't? I've written kOS scripts that can run an entire mission to Duna and back home with the only player input being to tell it "okay start the next step of my script now".

[Red Iron Crown]

Because the player isn't deciding the script, if I understand the idea properly.