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

[VerdammteSeele]

I'm pretty sure I've seen this EXACT thread already, but either way I still love the idea, also being biased cause I'm a computer science student. lol

[hotcrazyfruit]

I imagine it wouldn't be impossible to code a mod for this..

An excellent example is e2/wiremod for garrysmod, if anybody ever used it.

I wish I knew c# so I could fool around with it.

[Deejay2000]

I would like to see something like this in Lua, whether it be in the game or a mod. I would probably just be using this on probes. It would go well with something like RemoteTech, so if there is a 3 minute delay on Duna, instead of trying a near impossible landing, you can make the computer do the landing then control it like normal. As for complete autopilots, if you have the skill to create an autopilot, then you should be able to create it. But since this could be an autopilot, it might just be better as a mod for now.

-Deejay

[Dunbaratu]

First off, in the interest of not trying to sidetrack Squad into an enormous project beyond their staff's available time, I'd vote an emphatic "no" to the suggestions to make the language have an in-game GUI development environment. The game interface should just first concentrate on being able to parse the language and execute it, limiting the UI to just something where you paste a block of code text, or upload a text file of code. If there's time later, then making a fancy GUI or IDE to help can be nice but really, that's an enormous project of secondary importance to actually having the feature work at minimum. Also, the language should be something that already exists so that external already existing IDEs can be used by people. What Squad should provide is just a place to attach the code to a vessel design, and the API for the code to call into.

I envision for attaching the code to the vessel, that it be a thing you attach not to the vessel as a whole, but to the command module. Thus you have programming that can differ depending on which command module is selected with "control from here". And it makes thematic sense that the script is part of what's "inside" the core's computers.

I have to say that I like this idea because the primary thing I dislike about using Mechjeb's autopilot is that it's an autopilot that just arrived fully formed as a gift from heaven. MY space program didn't have a hand in making it, or learning trial-and-error style, what's wrong with it to correct it for next time. If there was to be some sort of piloting system, it needs to have that "Kerbal" feel to it, and that means I should have the joy of knowing that if I screwed up the programming, it can have hilariously disastrous effects.

[Dunbaratu]

Also, as another thing - if such a thing was implemented it would also open up the possibility of adding an interesting new challenge to the game, that being that direct control of unmanned computerized spacecraft has an imposed lightspeed delay and if you want to deal with manual control of it, it requires you to control the craft ahead of time if it's far away. The idea I have for the interface for this is that you basically just set up maneuver nodes using the normal maneuver node interface, and then just say "do those manuevers please when the time comes". That might sound like it makes things easier, but keep in mind that I'm envisioning that because of the lightspeed delay, this is the ONLY way you're allowed to control unmanned probes. The manual flying interface is reserved for manned craft only under this proposal.

The only thing you can do with an unmanned probe is:

1 - Tell it to perform manuever nodes at least N minutes from now where N is the lightspeed delay based on its distance.

2 - Tell it to activate one of its action groups at time T (which must be at least N minutes from now or later).

That way to make an unmanned probe do anything really interesting, like LAND, you'd have to program it to do so by script prepared ahead of time.

This would also have the effect of making the increased risk of manned missions perhaps more worth it. "Yeah it's a heavier payload, but at least with a pilot I'll be able to control the craft in real time." This will make the tradeoff between "should I do this unmanned or manned" become a real decision for the player to make that matters.

[ZenithRising]

First off, in the interest of not trying to sidetrack Squad into an enormous project beyond their staff's available time, I'd vote an emphatic "no" to the suggestions to make the language have an in-game GUI development environment.

I'm not sure a GUI would add much dev time to this idea actually. It could be built off of the existing Action Group GUI, with a list of action "blocks" that you stack to create a sequence of actions. Actions would include, "Adjust Pitch", "Adjust Thrust", "Extend Landing Gear", "Wait for Altitude", etc. with input-able values for each. Creating a system like that would be no more complicated that creating a dev console you can type into, possibly less so. Unless perhaps they can backdoor into a text-based system they are already using to code the game. I don't think that's likely though.

The biggest dev cost will be creating this system at all, and after that, adding new and more complex actions to it. Still, I think they should. Besides being really neat for dedicated players to mess with, it could double as a MechJeb-like system for precise burns/ascents, which I think a lot of players would use.

[Dunbaratu]

I'm not sure a GUI would add much dev time to this idea actually. It could be built off of the existing Action Group GUI, with a list of action "blocks" that you stack to create a sequence of actions. Actions would include, "Adjust Pitch", "Adjust Thrust", "Extend Landing Gear", "Wait for Altitude", etc. with input-able values for each. Creating a system like that would be no more complicated that creating a dev console you can type into, possibly less so. Unless perhaps they can backdoor into a text-based system they are already using to code the game. I don't think that's likely though.

But what you described is nowhere near complex enough to really program it. You need loops and branches. not just a list of unconditionally executed steps in sequence.

As far as a dev console you can type into, no that's really easy to implement because it's just a standard-issue textbox widget that pretty much every gui toolkit comes with as a stock thing.

[KvickFlygarn87]

This would be awesome! I can finally write a program that keeps my mainsails from overheating while I'm in map mode!

[KrazyKrl]

I would suggest something like a part that has like 16 Kerbits of data (magnetic coil memory?). And can only talk to the part it is connected to, and any parts connected to the parent. So, you could, say, give an order to the decoupler on your fuel tank to fire after the fuel is out, and to automatically fire drogue/main chute at the altitude you want (would need tweaking of persistence of game debris outside of the physics area).

The size limit on the code it's carrying could increase over upgrades you research. And the language used could be the same C code used everywhere. There is no reason to make up some obscure programming code for it. The main problem with adding something like this; is limiting it early game, so you don't end up with fully automated everything.

[pizzaoverhead]

This would be awesome! I can finally write a program that keeps my mainsails from overheating while I'm in map mode!

In the time since this has been suggested, the kOS mod has done a lot of what has been requested here.

[karolus10]

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

Same for me, catchy idea .

[Arachnoid_Warrior]

Is here someone, who played ever COLOBOT (COLOnize with roBOTs)?

There was a simple C-like (or Java-like - don't sure) language to program bots. Maybe, it is possible to do something like it in KSP...

[Galane]

I'd be happy with with a mod that simply adds right click options to parts in the VAB. For example, right click an engine and lock gimbal and have that setting stay with the .craft so one doesn't have to remember to do it on the pad at every launch.

If you have a part with fuel crossfeed that can be turned off and has to be off but is on by default and can only be toggled on the pad or in flight, make it toggle-able in the VAB and save its state. Same thing with parts with reaction wheels.

Then go a bit farther and equip those toggles with time, altitude or stage settings - choose one. If your rocket needs the reaction wheels off on the pad (due to them causing wobble that interferes with MechJeb's auto warp) but is fine with them on after launch, set them to start out off but turn on at liftoff.

In some cases you might need to toggle something more than once, so having 3 or 4 (shouldn't need more than 4) settable state changes of a system like RCS would be good. For example if you need RCS on while making the gravity turn but then need it off afterwards the 1st toggle would be On at the turn start altitude then the 2nd toggle would be Off x meters higher.

There wouldn't need to be any directly visible/editable code or script in-game. What the player would see is the same sort of popup menus they normally see for parts after the ship is on the pad or in flight. With the script stored in the Ships folder using the same name as the .craft it could be directly edited by people who want to dig in and twiddle the settings directly.

Could have two options for the script, just changes (different start settings from the defaults and any toggles set) or a full script that has every part with editable settings so the player can open the script in a text editor and easily set things without having to create the rest of the script structure from scratch.

To get more complex for the plugin would be to have an in-game editor that lights up the part on the ship and staging chart when the cursor is in the script section for that part.

What would make it even easier is to also put the popup menus on the staging chart for decouplers, separators and engines. If you have an engine buried in the middle of a rocket and it must have its gimbal locked for less wobble in flight, it's difficult to get at on the rocket. Dunno why Squad doesn't also have the menus on the staging chart.

[way2smrt]

What happens if you code your own MechJeb with this?

All in all, very good post. It's well organized and it is clear, concise and well thought out.

[Ricardo79]

I am not much of a programmer but absolutely yes on the first post.

Adding more and more function never hurts.

Maybe some kind of a dual action... where you can switch on an "easy" just klick the allowed options style and a expert mode on this where you can program it would be very neat.

[tater]

A mod is going to probably close all these posts you are making since the thread is 2 years old, just so you know.

[tntristan12]

Probably, but I hope not. These older suggestions were often ignored because of the young state the game was in. However, now there is no reason to not at least promote them. The devs have announced 1.0, so this is the time to really consider cool features like this. It's worth a look, no matter how old the OP.

[mattinoz]

A mod is going to probably close all these posts you are making since the thread is 2 years old, just so you know.

Maybe not given this is the linked thread in the "What not to suggest" thread.

[Starwhip]

One qualm: Too many abbreviations that are way too short.

New users and people new to coding would be entirely lost! (I code, so I'm not. )

Decouple. Instead of Dcpl, how about a Stage() method? (Which takes optional parameter for stage number, defaults to "next" stage)?

To avoid confusion with parts associated with stages, to access a part you could do:

Ship.Part(<part>)

[RAINCRAFTER]

I am not much of a programmer but absolutely yes on the first post.

Adding more and more function never hurts.

Maybe some kind of a dual action... where you can switch on an "easy" just klick the allowed options style and a expert mode on this where you can program it would be very neat.

First of all, suggestion: people don't like it when you necro, even for reasons. Also, I think that this is overall a good concept, though I think this should be a mod and not a stock feature for non-programers.

[Ricardo79]

First of all, suggestion: people don't like it when you necro, even for reasons. Also, I think that this is overall a good concept, though I think this should be a mod and not a stock feature for non-programers.

Yep I got a message about this necro thing since.

But I can't just stand to write about it. I found this on the already suggested post. And I do really like the idea.

I wasn't aware of this thread is a long dead one... As for at least 20 others I necroed in the last 2 hours... Rookie on the forums work sorry and as you probably guessed not english, so I can just barely understand what are people write here

I don't really like the concept of modding (for a Work in progress game) if the functionalities can be added directly, seamlesly, officially.

There are a ton of good mods here at least 20 I can fire right now without using my brain which without KSP would be too plain (almost unplayable withouth them).

But the separately installing configuring and running out of memory thing is not something people like. They DO like the lot more clever functionality they even can handle...

Therefore all the best Ideas SHOULD be inside the core game (For this one game it is particularly true as it is getting developped RIGHT now and so much to do is ahead.)

I understand and totaly respect your opinion about the programming part maybe a bit too much for an "average" player. I admit that. That's why I wrote to be good to make it a lite and a hard way switchable stuff.

AS you mentoined it: This should be a mod. IMHO the hard way should be a mod but a lite player friendly version could be a good addition to the game.

[Starwhip]

A mod, you say?

kOS Scriptable Autopilot System

I think this might help you.

Really, though, some simple scripting with Action groups would be great in stock.