Scratch style Action groups

[ZodiaK]

the point of this is to have some sort of level of better automation available, but you have to do the dirty work yourself. in mechjeb all you do is click a button and PHOOOOOOO you're off. whilst here you have to program it all yourself, so there is still a lot of work involved.

on the note that this will make action groups harder- I completely disagree.

action groups could still perform the same way they used to.

when '1' pressed==>toggle solar panels ==>end all

[Capt Snuggler]

the point of this is to have some sort of level of better automation available, but you have to do the dirty work yourself. in mechjeb all you do is click a button and PHOOOOOOO you're off. whilst here you have to program it all yourself, so there is still a lot of work involved.

on the note that this will make action groups harder- I completely disagree.

action groups could still perform the same way they used to.

when '1' pressed==>toggle solar panels ==>end all

Yup. there is no reason these functions couldn't be under an advanced [+] option int he AG menu. if you want basic action groups for your flight controls for simple engine on/off stuff, no problem. this would just allow us to make more interesting functions with scalable levels of complexity. AND it lets us cram more functions in to our 1-0 action groups.

personally the first thing this would help me with is solar panels on space planes:[press 6> toggle cargo doors> wait 3sec> toggle solar panels> end]

one question, could an AGfunctioninstructionlistthingy have more than one trigger?

eg: [press 6 or when altitude greater than 70,000m> toggle cargo doors> wait 3sec> toggle solar panels> end]

and another question, could the AG play backwards on the second press? i want those solar panels retracting 3sec before the cargo doors close.

Edited November 2, 2014 by Capt Snuggler

[ZodiaK]

okay, I did a quick mock-up of Capt. Snuggler's cargo/solar program.

this demonstrates 3 new behaviors.

the first is the 'toggle' command. what this means is that when 6 is pressed, the thing 'toggles' instead of just opening. this means that pressing 6 will also close the bay after it's been opened.

the 2nd is 'type= toggle'. this means that the first time the button is pressed, it continues the command normally. but the 2nd time it is pressed, it continues out the script backwards, effectively imposing a 'toggle' behavior.

the 3rd is the green flag. here it stands in place for an 'always' block, that begins sensing when physics load on launch. a sort of 'universal detector'

[mattinoz]

Would there be any reason we could write code by flying?

Thinking the craft file would have mission logs translated in to scratch records then those could be divided and tweaked to develop action groups for future flights.

[ZodiaK]

perhaps that would be a bit too complex

[Alshain]

I see some benefits to this, but it's running right on the edge of being an autopilot which isn't likely to be implemented. The benefits would be timed staging and triggering action group actions, but I personally don't think the "wait for x km" or "wait until intercepting" elements should be included. Anything more than waiting a defined number of seconds is too close to an autopilot and should remain in mods. Changing the heading, changing the throttle, I think all of that is a little too far. If it can't be done in action groups now, it probably shouldn't be in most cases.

Understand I'm not calling it a bad idea entirely, but some of the mock ups in the thread are just too powerful.

Edited November 3, 2014 by Alshain

[Vallius]

Maybe there should be a limit of like 4 steps to avoid making the entire flight automated? Seriously though, I'd some to have at least some of this functionality for the abort key.

Step 1: Shut down engines, decouple capsule, and fire escape rockets.

Step 2: Wait 5 seconds.

Step 3: Open parachutes.

[Alshain]

Maybe there should be a limit of like 4 steps to avoid making the entire flight automated? Seriously though, I'd some to have at least some of this functionality for the abort key.

Step 1: Shut down engines, decouple capsule, and fire escape rockets.

Step 2: Wait 5 seconds.

Step 3: Open parachutes.

Sure, that stuff can already be done through action groups (except the wait 5 seconds) so it would apply.

[Climberfx]

Man, this is amazing...

Can't wait...

[Capt Snuggler]

I see some benefits to this, but it's running right on the edge of being an autopilot which isn't likely to be implemented. The benefits would be timed staging and triggering action group actions, but I personally don't think the "wait for x km" or "wait until intercepting" elements should be included. Anything more than waiting a defined number of seconds is too close to an autopilot and should remain in mods. Changing the heading, changing the throttle, I think all of that is a little too far. If it can't be done in action groups now, it probably shouldn't be in most cases.

Understand I'm not calling it a bad idea entirely, but some of the mock ups in the thread are just too powerful.

i dont see it as being "auto pilot" at least not in the mechjeb sence. the player is writing the launch script and so it is still subject to player error and stays true to the trial and error fun of KSP.

sure the functionality will need to be limited to make sure the player is calling the shots. maybe more advanced functions like attitude control should be tied to advanced probe cores with a cost, weight and electric penalty.

IRL rockets do have automated launch cycles the thing is that the player would have to write there own launch cycle using careful planning, timing and trial and error.

edit: on rereading I agree some of the functions suggested are way too powerful. things like "wait for intercept mun" and "wait for periaps" require too much calculation and feedback from external data. info from the map view should not be available in these commands.

"wait for X time"

"wait for orbital velocity"

"set throttle to"

"wait for altitude"

"set attitude to"

these are fine as they are based off simple internal data from on board sensors.

Edited November 4, 2014 by Capt Snuggler

[Master Tao]

I realize it's hard with Scratch-style programming (and programming in general), but I'd really like to see fuzzy logic. For horizontally-launched spaceplanes, it would really help to have instructions apply to ranges like:

Set pitch to 15-20 degrees above the horizon.

Wait for altitude between 18 and 20 km and velocity > 700 m/s.

Set pitch to 5-10 degrees.

Wait for altitude between 28-35 km and velocity > 1500 m/s.

Start rocket engines.

[John FX]

I would like to have the option to trigger an event if mun was 90 degrees ahead in the orbit. I`d like to say `wait until Mun phase=90` then `100% thrust for 872 Dv` then trigger on `wait until SOI=Mun` and so forth.

I do not see commands like that as too powerful as they trigger on things that the craft should have sensors for. Even starting a countdown from when Mun was directly above would do and that could be set by a kerbal pressing a button if Mun was in the centre of a marker on a window, really basic stuff.

I really really like this idea. I has some aspects of KOS without having to learn syntax and without too much power, some aspects of the current system but with `playability` for those that want more.

On the most basic level it would work *exactly* like the current system (if the default trigger was the space bar and the default action was `stage`)

It could even make that by default so there would be no difference in gameplay to get the current method.

I`d really really like to be able to set up a chain of events like `jettison fairing, wait 3 seconds, extend solar panels, orient to (nose pointing away from planet, panels flat to direction of travel)` which was triggered itself by being in vacuum.

I know, I should check out smartparts...

on rereading I agree some of the functions suggested are way too powerful. things like "wait for intercept mun" and "wait for periaps" require too much calculation and feedback from external data. info from the map view should not be available in these commands.

"wait for X time"

"wait for orbital velocity"

"set throttle to"

"wait for altitude"

"set attitude to"

these are fine as they are based off simple internal data from on board sensors.

You could have triggers for `wait until vertical speed<0` `wait until vertical speed >0` as this would be an onboard sensor and you could find your Pe that way but I agree, simply giving the player their Pe value is too much and if you want that just get MJ.

I would say that `wait for orbital velocity` is a bit powerful for some. You could wait until alt>70km and wait until vel>2300 etc but saying `you are now in orbit` and triggering from that might be too much for people to handle who like their craft to be controlled by a biological entity only.

Edited November 5, 2014 by John FX

[Red Iron Crown]

I really really like this idea. It has some aspects of KOS without having to learn syntax and without too much power, some aspects of the current system but with `playability` for those that want more.

This sums up why this idea is so appealing to me. I don't have the programming skills to put kOS to good use, but I think I could do useful things with a Scratch-like pseudocode interface.

[Aatch]

I like the idea, but I think that some of the example functions are too powerful.

Anything that allows it to be pretty much an autopilot is a little too far for my tastes. Delays and similar make sense, but I'm wary of conditionals and having action groups directly control the craft beyond "turn engine on, turn engine off".

[ZodiaK]

well, if it does get implimented, it would be SQUAD's call. I'm sure that the'd make the right decision.

[scy]

I like the idea, but I think that some of the example functions are too powerful.

Anything that allows it to be pretty much an autopilot is a little too far for my tastes. Delays and similar make sense, but I'm wary of conditionals and having action groups directly control the craft beyond "turn engine on, turn engine off".

I don't understand the logic. In my opinion designing craft can be interesting as can flying things never done before, but things like launches (at least of easier craft) and transfer burns quickly get boring. Why can't an autopilot do that while I go get a cup of tea?

Each to his own, I guess.

[ZodiaK]

each to his own, especially when tea is involved

[JimmyAgent007]

Launching made easy I like. Maybe tie it into pilot skill so that new games dont get it right away, need to level up your kerbal first. As for other things like landing and transfers I think should be manual.

[Pds314]

This would be incredibly nice. Of course, at that point, why not go all the way and use KOS? Sure, it doesn't have scratch's block-based simplicity, but it is certainly not overly complex and does let you do exactly what it shows here, and substantially more.

Of course, what you've shown for scripts are quite simple. I think my scripts would be more like...

Edited November 13, 2014 by Pds314

[Red Iron Crown]

This would be incredibly nice. Of course, at that point, why not go all the way and use KOS.

Because kOS is only user-friendly if you're a programmer. A Scratch-style interface is much more accessible and intuitive for us non-programmer types.

[Capt Snuggler]

Launching made easy I like. Maybe tie it into pilot skill so that new games dont get it right away, need to level up your kerbal first. As for other things like landing and transfers I think should be manual.

I would tie it to probe cores and then make probe cores chew huge amounts of electric charge per input command.

taking direct control of a probe would be very energy inefficient. It would be much more energy efficient to program the probe to limit the number of input commands or if you want direct control, make it manned mission.

*edit*

also bigger probe cores could have more memory to allow you to queue more commands. (bigger programs)

This would make Kerbals and Probe cores fill separate but equally important roles.

Kerbals = direct control as long as the kerbal stays conscious.

(high G force blacked out kerbal)

Probes = pre-programmed automation with very limited direct control.

Edited November 13, 2014 by Capt Snuggler

[ZodiaK]

This would be incredibly nice. Of course, at that point, why not go all the way and use KOS? Sure, it doesn't have scratch's block-based simplicity, but it is certainly not overly complex and does let you do exactly what it shows here, and substantially more.

Of course, what you've shown for scripts are quite simple. I think my scripts would be more like...

http://i.imgur.com/AVHANdy.png

for the sake of clarification this script isn't for KSP, but for another scratch project

[Majorjim!]

I would tie it to probe cores and then make probe cores chew huge amounts of electric charge per input command.

taking direct control of a probe would be very energy inefficient. It would be much more energy efficient to program the probe to limit the number of input commands or if you want direct control, make it manned mission.

*edit*

also bigger probe cores could have more memory to allow you to queue more commands. (bigger programs)

This would make Kerbals and Probe cores fill separate but equally important roles.

Kerbals = direct control as long as the kerbal stays conscious. (high G force = blacked out kerbal)

Probes = pre-programmed automation with very limited direct control.

I would love all these realism enhancing things to be made stock. I do feel that these ideas would be better in a mod discussion though.

I've read everything Squad has said about their vision of KSP. And these kinds of thing are far too complex and tricky to be made stock.

I'm not hating on it, I just don't want Snugglers good ideas to get lost.

Dude, you should propose your ideas to mod makers too.

MJ

[Alshain]

I don't understand the logic. In my opinion designing craft can be interesting as can flying things never done before, but things like launches (at least of easier craft) and transfer burns quickly get boring. Why can't an autopilot do that while I go get a cup of tea?

Each to his own, I guess.

I think Squad has said they don't want to implement a stock Autopilot (again, I think, not 100% on that). If we want the feature implemented (which I think most of us are saying yes) then it will need exceptions before they would consider it.

[bartekkru99]

You also need to put some effort to make it work so it isnt really that "auto". I remember times when i was playing little big planet making all of those logic circuits. I never managed to make my mech walking how i wanted.