Add a programming-like function to the Action Group creator.

[quietsamurai98]

If action groups could be programmed to act like a launch sequence, it would add a whole new layer to rocket design.

Proof of concept/ravings of mad man:

• Representing each individual part with an ID, with a format like this:

  <PartType>.<SymmetryGroupNumber>.<PartNumber>

  .
  Breakdown:
  

  • PartType: Abbreviation for what part it is. Examples: SprtSRB for the Sepratron SRB, MnslENG for the Mainsail Engine, JmbLFT for the Rockomax Jumbo-64 Fuel Tank, and so on.
    
  • SymmetryGroupNumber: The symmetry group of the PartType that the specific part is in, numbered by chronological order of placement.
    
  • PartNumber: Which part the specific part is, with the the part closest to the launchpad being 1 (in case of a tie, the rightmost part is 1), then the number goes up by one going clockwise. 0 means the whole group.
    

  For example, the part

  MnslENG.2.4

  is the 4^th part in the group of Mainsails that was placed second.

  [*]Commands could:

  • Tell the specified part(s) to do something, like to decouple, turn on, turn off, etc., with a format like

    <Action>(<PartID>)

    . For example,

    Actv(SprtSRB.5.0)

    would activate the fifth group of Sepratrons,

    Dcpl(RmxDcplrDCPLR.3.1)

    would decouple the first member of the 3^rd group of Rockomax Brand Decouplers, and so on.
    

  • Tell the craft to do something, like change the throttle, toggle RCS/SAS, point in a direction, etc. For example:

    Throttle(80)

    Would set the throttle to 80%,

    SAS(Tgl)

    toggles SAS,

    RCS(On)

    turns on RCS if it was off,

    PntDir(0,0)

    tells RCS and/or SAS to rotate so it is facing 0 degrees (north) and to turn 0 degrees from the zenith, or from straight up, relative to the body that is being orbited (This is the starting orientation of nearly all spacecraft in KSP).
    

  • Tell the program to do something, like to pause and wait, to terminate, to restart, etc. Examples:

    Sleep(1000)

    would cause to program to wait 1000 ms (1 second) before continuing,

    EndProgram

    would end the program,

    Restrt

    would restart the program from the beginning.
    

  [*]Attributes could say what percent full a tank is, if a part is still connected to the main craft, the velocity of the craft, how overheated an engine is, what percentage the throttle is, etc. Examples:

  JmbLFT.5[Fuel.Liquid.Prct]

  would return 1 if the tank is full, 0 if empty, 0.5 if 50% full, ect.,

  MnslENG.1.0[Cnctd]

  would return 1 if the first group of Mainsails is still connected, 0 if not,

  Craft[Vel]

  would return the craft velocity in m/s, etc. Adding .Any to the end of an attribute selection returns the value for each part in a group of parts.

  [*]Loops and blocks would be things like

  Repeat[<Int value>]{<Code>}

  ,

  While[bool]{<Code>}

  ,

  Until[bool]{<Code>}

  ,

  If[Bool]{<Code>}

  ,

  If[bool]{Then{<Code>} Else {<Code>}}

  , etc.

  [*]Logic would consist of bool operators, like And, Or, Xor, Not,<, >, =<, =>, =, etc., which would compare Attributes. For example, (JmbLFT.1.0[Fuel.Liquid.Prct]=0) OR (MnslENG.1.0[Cnctd]=0) returns 1 if all fuel tanks in group 1 are empty or if all Mainsails in group 1 are not connected to the craft, and returns 0 if all tanks are not empty and all Mainsails are still connected to the ship.

Example of a program:

Until[JmbLFT.1.0[Fuel.Liquid.Prct]=0]{
Sleep(1)
}
Stg(Nxt)

The above code waits until the first group of Jumbo tanks are empty, then advances to the next stage. This could be used as a way to save fuel, to create automated launch sequences, etc.

Now, for something more complicated.

This is a basic autopilot example script that I thought of. It will guide a craft into a non circular, stable orbit, but it only points the craft and adjusts the throttle. The staging is manual, and the player must turn RCS on if wanted while still in the atmosphere.

Throttle(80)
Until[Craft[Alt]=>10000]{
 PntDir(90,0)
}
Until[Craft[Alt]=>70000]{
 PntDir(90,45)
}
Throttle(0)
RCS(On)
Until[Craft[Alt]=Craft[Ap]]{
 PntDir(90,90)
}
Until[Craft[Pr]=>70000]{
 Throttle(80)
 PntDir(90,90)
}

Throttle(0)

Breakdown of script:

1. Throttle to 80%, so that engines with be near 100% but not overheat (if using Mainsails).

2. Point straight up and face east until the craft passes 10000 meters (Takeoff and ascent).

3. Turn 45 degrees east of straight up until the craft passes 70000 meters (Gravity turn).

4. Cut the throttle, and turn on RCS, as fins don't work in outer space.

5. Point parallel to the ground, pointing east, until the craft has reached the apoapsis.

6. Maintaining the current orientation, throttle up to 80%, until the periapsis has passed 70000 meters, the lowest possible periapsis for a stable orbit around Kerbin.

Primitive guidance system I coded in five minutes. Don't criticize me, I know it's a blob of spaghetti code.

Mmm... Italian...

Also, a friend told me that for beginners, that drag and drop block coding could be simpler, and have a more gentle learning curve.

Example of Drag and Drop coding (shown in an old version of Scratch):

This idea could be an amazing addition to the game, allowing players with enough skill to make fully automated launchpad to orbit sequences, automated rovers, landing sequences, anything, as long as your coding skills are good enough.

Concerning the ban on suggesting autopilots:

I fully believe that this system would be balanced, as a player would need skill, knowledge, planning, and time to write a complex code, as opposed to autopilots like MechJeb, which require next to no skill to use.

Thanks for reading this post despite the extreme length and unnecessary detail.

Sorry for the long post, especially if it makes no sense to you. I've kinda confused myself now.

Please post feedback on the idea.

Thanks,

--

The Quiet Samurai

EDIT: I just found Autom8, so I want to preemptively address any people who say to just use that.

I think that a simple to understand, reads like English, easy to learn, language would be great for the future game; as a readable and easy to learn and use language would not be as intimidating to new players/coders as a more complex language, like lua or C/C#, is.

I can speak from experience: being overwhelmed by something, especially programming, at first glance can make you very reluctant to even attempt to learn it, even under different circumstances. My dad tried, and to a degree succeeded, to teach me KPL when I was 6-7, and I never really enjoyed coding until about 3 years later, when I happened to find a rather simple language called Scratch, and only then did I begin to like coding.

If people get turned off of coding by KSP, they may never give it another chance, and that would be the opposite of my intentions; to introduce programming to people in an approachable way in a fun environment.

This is just my own musings on how a block based system could work, just ignore it.

Or try to decipher the syntax and connect the meanings to the blocks used in Scratch, which is my inspiration for this syntax.

Block Code Visual Text Representation

|When (P) Released|

|| |Until <(P) Pressed>

|| ||Until <(FuelPercent[FuelTank.Group.Last])=(0)>|

|| ||Sleep(1)|

|| ||=====

|| |Next Stage

||=====

|Stop

Line by line explanation:

When the P key is released,

Repeat the following until P key is pressed:

Repeat the following until the still connected group of fuel tanks that was last placed is empty,

Wait 1 ms

Loop to beginning of this repeat until loop (line 3).

Activate the next stage,

Loop to beginning of this repeat until loop (line 2).

Stop Program.

Edited August 4, 2013 by quietsamurai98
code block musings

[Themohawkninja]

Maybe I'm biased, being a programmer myself, but OH MY GOD YES!

You could have things automatically fire/decouple when a tank runs out of fuel. This would be so cool!

Edited August 3, 2013 by Themohawkninja

[Beeman]

I feel like this would be a good alternative to what we have now. But like...keep what we have now, if that makes sense. Like, maybe in the options there'd be a gameplay toggle for action groups and what we have now can be simplified action groups while something like that can be expanded action groups.

If all we had was super complex action groups, it'd overwhelm a lot of people, especially when it's their first time playing. Or even some of us who play a lot but just don't know much about what we're doing. True trial-and-error KSPers XD

[quietsamurai98]

I feel like this would be a good alternative to what we have now. But like...keep what we have now, if that makes sense. Like, maybe in the options there'd be a gameplay toggle for action groups and what we have now can be simplified action groups while something like that can be expanded action groups.

If all we had was super complex action groups, it'd overwhelm a lot of people, especially when it's their first time playing. Or even some of us who play a lot but just don't know much about what we're doing. True trial-and-error KSPers XD

It could be like another tab, like the tabs for Parts, Action Groups, and Crew. Maybe call it Advanced Action Programmer

[Beeman]

That could also work

[SolarLiner]

Too much abbreviations in the proof of concept I think (Do we really want to type Dcpl instead of Decouple? Does it really saves time?), but I really like your concept. It can be a much better approach for the "non-mod" beginners to have automated parts.

Now script implementation is something big to add, and will take time. But this is an awesome idea to being able to write autopilots.

[quietsamurai98]

Too much abbreviations in the proof of concept I think (Do we really want to type Dcpl instead of Decouple? Does it really saves time?)

Abbreviations are more or less standard in coding. I think that abbreviations are faster than normal text, but the main draw, at least for me, is that they are easier to spell.

Case and point: I was originally going to say Dcpl and decouple in that last sentence, but after trying and failing to spell decouple five times, I just changed the sentence. I got Dcpl on the first try.

[SolarLiner]

Yeah, I'm not that much of an abbreviation guy. I use them when I see an improvement in the typing speed.

After that, I'm used to VS who gives me all the vars names and such. In a simple text file (like when I do PHP) I like to use them a bit more often. But still, I like when I can read properly on the first try who's who and what does what.

[quietsamurai98]

I see what you're saying, and I agree that abbreviating most actions doesn't really matter, but for things like parts and longer actions, it would probably get old typing 'Mainsail.#.#' or 'LargeStackDecoupler.#.#' or 'JumboTank.#.#[Fuel.Liquid.PercentFull]' over and over again.

Edited August 3, 2013 by quietsamurai98

[MrKicker]

How about using dropdown menus with the words of code in them and ditch typing completly. More user friendly for those who dont know that mutch about computers.

[quietsamurai98]

Also, here is a basic autopilot example script that I just thought of, that will put a craft into a non circular orbit, but it only points the craft and adjusts the throttle. The staging is manual, and the player must turn RCS on if wanted while still in the atmosphere.

Throttle(80)

Until[Craft[Alt]=>10000]{
 PntDir(90,0)
}

Until[Craft[Alt]=>70000]{
 PntDir(90,45)
}

Throttle(0)
RCS(On)

Until[Craft[Alt]=Craft[Ap]]{
 PntDir(90,90)
}

Until[Craft[Pr]=>70000]{
 Throttle(80)
 PntDir(90,90)
}

Throttle(0)

Breakdown of script:

1. Throttle to 80%, so that engines with be near 100% but not overheat (if using Mainsails).

2. Point straight up and face east until the craft passes 10000 meters (Takeoff and ascent).

3. Turn 45 degrees east of straight up until the craft passes 70000 meters (Gravity turn).

4. Cut the throttle, and turn on RCS, as fins don't work in outer space.

5. Point parallel to the ground pointing east, until the craft has reached the apoapsis

6. Maintaining the current orientation, throttle up to 80%, until the periapsis has passed 70000 meters, the lowest possible periapsis for a stable orbit around Kerbin

Simple 'auto guidance' system for launchpad to Kerbin orbit. Not really autopilot as there isn't autostaging or sophistication. Just a little proof of concept.

[quietsamurai98]

Double Post

[Beeman]

I like the scratch idea, where you use...in KSP they'd probably just be buttons for words and functions and things. So maybe action group one would have x number of buttons that you can define to certain parts, then give those parts functions.

Let's say we click action group one, a panel shifts open to the right with...let's say ten buttons. You..maybe click a button then click a part to assign that part to that button. Then another panel shifts over to the right from the engine button and you can assign one(or possibly more, depending on how complicated this system is already) action to that button. Maybe some of the actions can have parameters that you can manually adjust for numeric values. Like activating the selected engines at eighty percent or using your SAS controller to tilt the craft at a specific heading with a particular inclination. Or something like that.

You then start to setup button two. Let's say the first one was launching with your engines at eighty percent and then you set your second button to wait until you reach an altitude of 10,000. You'd probably have to use the command pod for the button.

Next, you setup button three. Button three, you want to perform a thirty degree turn with a heading of ninety degrees. Again, you probably would need to use the command pod for this as that's kind of your SAS controller, right?

Then instead of setting more buttons, you just launch. The buttons will activate from top to bottom in order for each action group that you activate. You hit action group one(whatever the hotkey might be for it) and you immediately launch with all of your engines set to eighty percent. THEN your craft just kind of goes until you reach an altitude of ten thousand meters. Finally, your craft starts to tilt just as you'd designed.

Essentially everything you seem to want, but with simple and accessible user interface for it.

Though, that leads to autopiloting(even if you have to manually define the numbers beforehand) and I think SQUAD wants to avoid that type of thing...more or less. I don't know. Either way, might make a decent mod if someone knows how to code that stuff.

I'm not sure how difficult it would be to work that out, though...I know practically nothing about coding XD

Edited August 4, 2013 by Beeman

[quietsamurai98]

Though, that leads to autopiloting(even if you have to manually define the numbers beforehand) and I think SQUAD wants to avoid that type of thing...more or less.

Yeah, it kinda does lead to autopiloting.

In five minutes I coded a crude auto guidance for launch to orbit in about 5 minutes, so imagine what a really good coder with some extra time could do... Interplanetary travel? Full auto launch, Kerbin orbit, Jool transfer, aerobrake, and Laythe land landing? That would be really hard though...

The easier the task, the easier the code, so a fairly experienced KSP player could code a launch to orbit autopilot, because they basically have a 'script' for it in their head from doing it so many times manually. However, The more rare, advanced maneuvers, like Kerbin Launch to Jool transfer+aerobrake to orbit would be near impossible to code, due to rarity and complexity of the mission.

I believe that this would more or less balance out, allowing the repetitive, easy tasks to become automated with enough experience and effort, but more unfamiliar and difficult tasks being extremely hard to automate.

[1D-1()T]

I must say this is a great suggestion. This would go really well with a mod where you could collect samples or rock etc.

Can you imagine sending a unmanned rover to Duna, and leave it searching for, I dunno, water or life. And it could have a satellite dish that could be set up to inform you if it finds anything.

I don't think it will get into vanilla, because it could be used as an auto pilot, and might drive people away with the added complexity, but if it did make it in, or there was a mod for it I for one would use.

[Beeman]

I believe that this would more or less balance out, allowing the repetitive, easy tasks to become automated with enough experience and effort, but more unfamiliar and difficult tasks being extremely hard to automate.

I feel like if we had a UI system like scratch or the weird button thing I was talking about emulating coding without the freedom of actual coding, it would more or less balance things out on its own. They'd just have to omit more advanced actions, leaving it to modders to implement those addons to the system. By limiting what actions you can assign to each button/part, you effectively limit the player's ability to fully automate flights. Or restrict certain actions to pilot skill, since I remember one of the devs saying something about training crew to handle certain maneuvers on their own. Like, if you setup a button to perform a particular turn or maneuver, maybe that vehicle will require at least one crewman with piloting skill level two. Or something like that...and it won't allow a launch without that crewman?

I don't know, there's a lot of interesting things to think about in this topic, though.

[Wice]

Man, I would love something like this so much! It has been suggested before but I really hope the devs ead this and implement something like it...

[Thorben]

In the past, I also thought how cool it would be to code some kind of autopilot and to automate everything on the space craft. The problem is: What will the player have to do if there is an active autopiloting script as you suggested? Extending or retracting solar panels (not even necessary)? Watching the planet? Doing ten EVAs just because there is nothing else to do? For me, this sounds quite boring and (although I basically like the idea) I hope this will not happen. In fact, this feature would change the spirit of KSP from "building and flying rockets" to "building rockets, programming scripts and watching how they work". Furthermore, I guess many community members have never been programming before and in the worst case, they would stop playing KSP if it changes to much into this "nerd"-direction (I'm programming a lot, so I'm counting myself to the "nerds" as well ). Of course, one might say "don't use it if you cannot or will not write scripts" but the more parts of a game are not open to the player, the more rises the feeling of not being the right gamer for the game (just my personal guess).

I hope the (already planned) crew tasks will find a way in the middle, allowing players to automate easy things (without coding) while not taking over the interesting tasks. Anyone who wants to write code for his rockets in KSP is free to write his personal autopilot mod.

[Beeman]

Some people don't care to fly the rockets that they build. Some people just want to build rockets, stations, probes, bases and so on and hop about in low gravity worlds, ragdolling left and right. Oh the hilarity~

Some people just want to manage a space program, doing missions to earn money then investing that money back into the space program to take on harder missions with more advanced tech.

Granted, I want to do everything, including flying my own rockets. Even so, the scratch method or the button thing I was talking about could have strict(or loose) limitations on what you can and can't actually do with the system and that's the beauty of it. The functions would still be much more robust and customizable than current action groups but not to the point where you can fully automate flight after flight. You'd still have to do things to make your flights successful. There could even be, as I suggested earlier, a crew skill requirement for certain tasks.

We might even see a lot of this semi-automated rocket maneuvering anyways, depending on how they work in the flight planning features they've got planned. Who knows?

[Fifi]

Shouldn't it be better to made a part which will function as a on-board computer? It would be programmed in Lua/Python/whatver and maneuver ships for us. This would allow automatic fleet to do it's jobs.

I don't know if anybody remembers this game, but connecting KSP and Colobot would be a great experience. ;>

[toric5]

big support for this! i think that because of the game/cartoony feel of kip, it should be a drag and drop, like scratch. someone go pester the devs about this!! (JK, the devs have a lot of stuff to do as it is. i just want the devs to hear about this.)

[Skorpion]

I remember ages ago Harvester asked the community about ideas for a redesign of the staging system. He eventually decided that the staging system wasn't so broken after all, so in the end not much changed (at least on the surface).

However, one of the more developed ideas that came out of that discussion was an editable flow chart, so that you could say, for instance:

If I'm in the second stage and I press the abort button:

1) Separate the pod.

2) Fire escape thrusters

3) Delay for three seconds

4) Open the parachutes.

(You'll have to imagine that in flow-chart form to get the full effect.)

I still like the sound of that, and now that we have action groups I can easily imagine an advanced interface that allows you to drag around nodes on a flow-chart, building actions the same way we build rockets.

One thing I've always wanted on my tugs is to have one button that cycles between front lights and rear lights, and a second button that cycles between lights off, lights low, and lights high. That's not really possible with the action groups we have now.

[SolarLiner]

TL;DR, stopped at the buttons for non-programmers.

WHat I think about is a user-friendly IDE to quickly design ascent profiles for example, add often used functions, and has the functionality of any other IDE (colour syntaxing, assisted typing maybe?, functions help, etc...).

Now the idea of a Lua/Python/Other/Custom scripting language autopilot Mod is also a great idea in the wait.

[Dave Kerbin]

First of course this is a great idea - as a programmer I was thinking of it myself and went searching to see if someone had already done it or started a conversation.

With regard to automation I think that is part of the point - I'd love to be able to design a 'program' to go along with my unmanned orbital refueling stations to cover the mundane task of putting a few up in proper orbit and then deorbiting their upper stage. Different people play the game differently, and I happen to be one of those that likes the design and planning part but don't get as much out of the basic flight tasks once I've mastered them. I think this would be a more 'realistic' alternative to MechJeb which I've tried and found both 'cheating' a little, but at the same time worse then doing some actions manually because it wants to do them in its own way. I like to feel that any failures are because I made a specific mistake which I can then find and fix, and failures like a well tested rocket using ascent assist going out of control is much more frustrating because the reason for the failure is due to some buried code in MechJeb.

Language wise I think using a BASIC dialect would not only match the flavor of a 60's space program, but also make it easy for non-programmers to learn and use. Strict old-school BASIC is also somewhat drag and drop friendly in the way each statement is easily identified by a keyword instead of by inference.

There are some challenges with an in-game language. You've already got one of them, which is how to 'name' parts and objects for reference in code. You want it to be simple and straight forward, but still cover everything. Consider what happens when you dock spacecraft together to form a larger ship or station; You might even launch duplicates of the same craft file, like standardized orbiting fuel depots, which are then joined in orbit to create a super depot. You might also want some form of reflection that allows a program to dynamically locate a part or parts. For example DPort(#ship) would give you the first docking port part inside the #ship part tree, while DPorts(#ship) would return an array of all of them.

Another challenge is with the limitations of how KSP works - to optimize performance objects outside a certain range or above a certain time warp become simple inert masses. For practical purposes a ship stops being a complex system of working parts and instead becomes a one step orbital mass equation as soon as you go to the space center or another ship. For example if you wrote a program that turned on some running light while solar power is at zero (ship is in the dark) KSP would only be able to execute it you where directly viewing your ship at 1x or low warp (I'm not sure of the exact warp steps where part function and part existance stop being simulated, based on the atmospheric warp restrictions I'd say it is 4x or less).

I think this means that any program would need to be something with a defined start and end, or at least the ability for the player to 'stop' a running program. A running program would be treated in a manner similar to the ship being throttled up - you can't warp and you can't switch to another object, which puts some serious limitations on what programs can do. Since very near objects do getsimulated it could be that a close enough objects can be 'remotely' commanded by your ships program.

[ZenithRising]

You tried and failed to spell Decouple multiple times? How does that happen?

In any case, programming languages are moving away from abbreviations and towards readability, even going so far as to do away with typing all together and using drag and drop lego-style systems. That's definitely the direction I would like to see anything in KSP go towards. How are you suppossed to know that the proper abbreviation is dcpl and not decoup or decpl?

If anybody has used Apple's Automator, that's a pretty good example of drag-and-drop script building, and it works well. Something similar in KSP would be amazing (though obviously a huge undertaking). Something text based might be easier to implement (perhaps it could be based off of the game's existing engine?). Either way, I would love playing around with it.