pre programmed maneuvers

[mrvice]

Why is there no "flight computer" (like in remote tech) since 1.2 update?

(Placing a maneuver node as long as you have connection wich gets executed also if connection to ksc has been lost.)

in my opinion this should be already in the stock game, with the option of signal delay on/off.

Nothing is more annoying that you know you could have done that orbit if this feature would be ingame already.

Edited October 1, 2017 by mrvice

[MR L A]

I can guarantee the response you will get to this is something along the lines of "we all have different ideas about what should and shouldn't be in the stock game - some people think a feature like this should be stock, some people think its completely unnecessary - and seeing as there are mods available to fill the gap, just use them"

IMO some flight computer system would be cool... but I imagine it would be a hell of a learning curve on top of a game that already seems ridiculously hard until you know what you're doing. Do we really need a flight computer though? Sure, it would be cool to sit back and watch something land on another planet automatically or deploy antenna and solar panels at a specific orbital height but doesn't that mean you're just doing less work and watching the computer play for you? 

[mrvice]

2 hours ago, MR L A said:

I can guarantee the response you will get to this is something along the lines of "we all have different ideas about what should and shouldn't be in the stock game - some people think a feature like this should be stock, some people think its completely unnecessary - and seeing as there are mods available to fill the gap, just use them"

IMO some flight computer system would be cool... but I imagine it would be a hell of a learning curve on top of a game that already seems ridiculously hard until you know what you're doing. Do we really need a flight computer though? Sure, it would be cool to sit back and watch something land on another planet automatically or deploy antenna and solar panels at a specific orbital height but doesn't that mean you're just doing less work and watching the computer play for you? 

it´ts not meant to let the computer play for me, just like in situations for example when going to moon and need the burn on the dark side of satellite connection to be able to make it into oribt, wich is nothing other than a pre lanned maneuver that executes without connection wich makes things only easier but not hard . ( not hard to master at all ). Harder would be to use remote tech mod wich is the only mod i know that has a working flight computer (without connection). Iam not talking about a mechjeb thing. Just something that lets you place a manouver node as lons as you have connection but still would execute automatically even when connection is lost. ( but you have to pre-plan it ) . As the stock game has the option that probe control comes to a complete stop during connection loss i see this as a pretty needed feature.

[Spricigo]

33 minutes ago, mrvice said:

As the stock game has the option that probe control comes to a complete stop during connection loss i see this as a pretty needed feature

The limited control when out of signal  can as easily be used as an argument against the idea.

Personally I'd like to have the ability to auto-execute planned  maneuvers added to high level pilots. It could as well be provided for high tech probecore or a new part.

I don't see that happening in stock and the autopilot mods available are all way more complex (complete?) 

 

[Alshain]

I think the biggest reason this didn't happen has nothing to do with play styles, it is because this is insanely difficult to program correctly and Squad didn't feel it was worth the dev time..

Even the RemoteTech flight computer is terrible mess.  It only works half the time, not well enough to turn on signal delay as a game option because it is too ignorant to fly your probe correctly even when you tell it exactly what to do.

As much as I love RemoteTech, I use quickload far more often when I try to use the flight computer because half the time it either won't stop when it is supposed to and spins the craft in circles, or gets confused as to which direction is prograde (which I think is actually a stock issue when having multiple probes on one craft, even if all the probes are facing the same correct direction).  The worst part is, even if you see it messing up, you can't stop the maneuver.  Even if signal delay is off, you can't stop the maneuver, deleting it does nothing, you have to force shut down the engine, try to stop the maneuver, return to the space center and then come back to the craft for it to be finally deleted.

Now if the RT developers have been working on this mod for years and it is a complete mess, imagine if Squad tried to do it in stock in one patch.  That isn't to say it couldn't be done and done better, but it would take dev resources that would detract from development on other things.

Edited October 1, 2017 by Alshain

[Gaarst]

The stock comm system is a good idea but unfortunately it is not complete.

 Something as simple as a circularisation burn should be able to be programmed; having to maintain direct communication with Earth/Kerbin to do it is stupid, especially if you consider comms are not instantaneous IRL.

The difficulty in the comms system should not be "you want to capture but you can't since you're on the wrong side of the planet", it should be "you can follow your mission plan, but if something goes wrong there's nothing you can do". Simple programmable tasks (I'm not asking for a full autopilot) such as single burns should be programmable when in comm range to be executed when unable to provide manual control.

This would make the probes a little bit less insignificant when compared to manned vessels (which don't have any drawbacks in the game since there is no life support and don't need a comm link).

[mattinoz]

If you wanted to simulate radio transmissions you could save lock out a number of minutes ahead of the craft and not allow new nodes in that zone. How many minutes would be well say twice maybe three times the radio delay to the nearest control center. 

[UranianBlue]

Answer: MechJeb.

If you want an autopilot, use MechJeb. If you want something else, you can code up a working module in C#.

[DAL59]

I think the inability to control probes without a signal since you cannot program really needs improvement.  It makes probe missions very difficult, due to occlusion.    

[Spricigo]

4 hours ago, DAL59 said:

I think the inability to control probes without a signal since you cannot program really needs improvement.  It makes probe missions very difficult, due to occlusion.    

Very difficult?!! C'mon!!!!

And you still have the option to disable it 

 

[DAL59]

42 minutes ago, Spricigo said:

Very difficult?!! C'mon!!!

You cannot do orbital insertion burns behind the body.  

[Superfluous J]

5 minutes ago, DAL59 said:

You cannot do orbital insertion burns behind the body.  

Yes you can. You don't even need the ability to auto aim at anything.

Make a maneuver node while you have full control. Aim the probe at it. Time warp to it, and burn.

Though most probes can auto-aim retrograde, which is all you need to do it even without any pre-planning.

[Spricigo]

21 minutes ago, DAL59 said:

You cannot do orbital insertion burns behind the body.  

The whole point of the features is to have situations where probes may be out of communication.

Either learn to plan your mission with commnet in mind or just disable it.

 

[Capt Snuggler]

instead of "programming", which I agree is far too complicated for the average player, what about a simple event script?

pick "events" from a drop down list and put them in the correct order.

set the functions, targets and required values (time delays, altitudes etc, resource values).

load to launch pad and click "run script".

eg:

1. set throttle: 100%
2. set SAS mode: rotation hold
3. set rotation hold: pitch: 90° yaw: 90° roll: 0°
4. Stage
5. wait for: alt = 7000m
6. set rotation hold: pitch: 45° yaw: 90° roll: 0°
7. wait for: stage fuel = 0.0L
8. Stage
9. wait for: alt = 20000m
10. set SAS mode: prograde hold
11. wait for: apoapsis = 100000m
12. set throttle: 0%
13. wait for: altitude = 71000m
14. Stage
15. wait for: altitude = 100000m
16. set throttle: 100%
17. wait for: periapsis = 99000m
18. set throttle: 0%
19. print msg: (free text) You are now in orbit. have a nice day!
20. end

This is a crude launch to orbit script. obviously it depends on the craft and could be improved and made infinitely more precise. (*also im not sure about the pitch, yaw and roll values. I think 0,0,0 points you at the eastern horizon.)

The scripts would be as important as the craft files and shared by the community.

by having predefined options you avoid having to learn syntax. instead you just keep adding events to the script. by selecting options from a drop down and inputting values where needed.

Edited October 13, 2017 by Capt Snuggler

[Capt Snuggler]

ALSO

The functions and script length should be defined by the probe core. the better the probe core, the more "memory" and the more advanced functions. such as:

• set throttle: maintain acceleration = 2.0 G
• set rotation hold: match target orientation (for docking)

or a bunch of specific rover driving or plane piloting functions. The player still needs to define all the values.

 

Edited October 13, 2017 by Capt Snuggler

[Spricigo]

2 hours ago, Capt Snuggler said:

instead of "programming", which I agree is far too complicated for the average player, what about a simple event script?

The average players already use a simple events(maneuver nodes) to "program" the flight. 

It's fairly simple yet powerful.  The supposed issue is the inability of probecores to run the 'script' by themselves, regardless of communication status. 

 

 

[Capt Snuggler]

4 hours ago, Spricigo said:

The average players already use a simple events(maneuver nodes) to "program" the flight. 

It's fairly simple yet powerful.  The supposed issue is the inability of probecores to run the 'script' by themselves, regardless of communication status.

I mean that average players (my self included) cannot be expected to learn a programming language in order to stop their probes from bricking when outside comms range.

 

You could crate the script and initiate it when in coms range. just make the first event a "wait for: X" or similar. so you could initiate the script just as you enter the SOI of Duna, then it waits until the X condition (ie. altitude) is met before continuing with the script.

so for example, just as you enter the SOI of Duna you run the script.

1. set SAS mode: retrograde hold

2. set throttle 50%

3. wait for: periapsis = 100000m

4. set throttle 0%

5. wait for: altitude = 100000m

6. set throttle 100%

7. wait for: apoapsis = 110000m

8. set throttle 0%

9. end

 

Edited October 13, 2017 by Capt Snuggler

[Spricigo]

36 minutes ago, Capt Snuggler said:

I mean that average players (my self included) cannot be expected to learn a programming language

If you know how to setup a maneuver node you already know the language. In fact you already program in the language. But instead of it being automatically executed is up to the player to do so.

[DAL59]

5 hours ago, Spricigo said:

up to the player to do so.

...except when the probes are occluded.  

[Pand5461]

@mrvice, @DAL59 you basically want CommNet play with pre-CommNet mission planning. In than case, why bother? Just switch off "probes need signal for control" switch and enjoy no loss of connection and whatnot.

The whole purpose of CommNet is to include signal occlusion, so some of the previous techniques either become impossible or require more care.

[Spricigo]

9 hours ago, DAL59 said:

...except when the probes are occluded.  

It's up to the player plan and execute maneuvers.  The fact you are planning something impossible to execute don't change that.

 

 

 

[DAL59]

16 hours ago, Pand5461 said:

probes need signal for control" switch

That setting does not allow you to actually fly your probe during occlusions.  It just means that you can extend solar panels and antenna and take readings during occlusions.  You still cannot throttle or turn.  

[Spricigo]

56 minutes ago, DAL59 said:

That setting does not allow you to actually fly your probe during occlusions.  It just means that you can extend solar panels and antenna and take readings during occlusions.  You still cannot throttle or turn.  

You can burn at 100% throttle and turn to whatever direction you probe SAS allow. As explained by 5thHorseman that's more than enough to make orbit.

But if that is still too difficult to you,  I already pointed the solution: disable commnet.

[DAL59]

1 hour ago, Spricigo said:

You can burn at 100% throttle

good point.  Especially since you can set your throttle limiter before hand.  Thank you for telling me this!