Make manual delay more user-friendly

[Starstrider42]

I have a number of suggestions for making the flight computer's manual delay feature easier to use. (Disclaimer: suggestions may actually make it harder to use, more discussion/polling needed).

• It's hard to remember to hit enter for the manual delay, especially since the other text boxes in the flight computer -- the custom attitude and the burn length -- don't require hitting enter (sure, you can hit enter to start a burn, but you can also click the burn button). Two possible solutions:
  • Add a "set" button next to delay box. This would serve as a visual reminder that just typing is not enough.
  • Reparse the text box whenever it's updated. Since manual delay only takes effect when you schedule a command, this shouldn't cause problems from the delay being updated in mid-typing. I think. Probably.
• At the moment, all flight computer features, including manual delay, stay on when you close the flight computer window. Manual delay is the most problematic, since it leads to the confusing behavior that nothing happens when you try to act. Again, two options:
  • Have manual delay, and only manual delay, turn off when you close the flight computer window. This would prevent players from having to disable the delay every time, but it would cause trouble for players who like to hide the window whenever they're not setting something directly related to the computer. It would also make the computer's behavior less self-consistent, which could make it harder to understand.
  • Have everything turn off (including state/queues) when you close the flight computer. Has the advantage of self-consistency, but makes the "I like to hide the window" problem more extreme. If implemented, would make Flight Computer status indicator #50 obsolete.

This is a usability issue, so it should really be done in whatever makes the most sense to the most players. Thoughts?

[AdmiralTigerclaw]

My one Cent: Add the ability to chain the 'execute maneuver node' function. Even if it's not super accurate, it makes more sense if you can chain several automated maneuver nodes together.

[Starstrider42]

Already being worked on: #73, see the last post.

[Dunbaratu]

This isn't a duplicate of #73. #73 is about maneuver nodes. This is about making it easier to tell the flight computer what timings you want for all queued actions, even ones that aren't using maneuver nodes.

I've only just started using RT2 and the most difficult thing I have is this:

• IMO the textfield UI elements should all use the same interface with regards to the 'enter' key. The way it works now, the Delay field's value won't set until you hit ENTER, meaning you can't delay unless you hit Enter in that field. But the other text fields like 'pitch' and 'yaw' immediately trigger the command when you press Enter, instead of just setting the value and awaiting the press of the button to commit the command, so with those fields you must NOT HIT Enter if you're trying to queue the command for later. This leads to the fact that to queue a command you must remember to NEVER Hit enter on any field Except the Delay field.
• The fact that if you want to program a command to happen later you can't just pick a hard absolute time and instead must make it a delay relative to whatever the time was when you happen to commit the command makes it very picky about programming two moves you meant to happen back to back. You have to set the first command with a bigger delay than the second command, then when setting the second command you have to wait...wait...and hit the commit button.......NOW. That sort of touchy timing seems unnecessary. You should be able to chain two commands back to back by having an option for a delay relative to the completion of the prev command in the queue rather than a delay relative to when you committed the command.

[AdmiralTigerclaw]

Yeah, relative delay should definitely be a thing. It's annoying if you want to program a delay between one maneuver and the next, and you have to recalculate for each one. Having a 'X time after last command' option in there.

Another useful feature would be delay reprogram options on the queued commands. You program a time delay and you start queuing up commands and then realize the delay for the first command is too long or too short and you want to change it. You have to reprogram ALL of them. One should be able to go back and alter the time on the user delay to fine tune a command.

Also, the ability to move commands up or down in the queue. That way if you get half way through making a list of command options, and realize you need to add a command to the front of the list, you don't have to redo it.

I've done so many F9s on launch because I wasted too much time redoing the command list from scratch every time I made a mistake.

Fixing what needs enter and what doesn't is good as well as has been reviewed. Honestly, the time delay input should behave like a field of the command anyway, so setting the command should just read the input. It makes no sense to have the time delay get stored as a separate module that requires the player to hit enter. That also messes me up and causes me to bungle command lists.

[jdmj]

This issue just begs for the whole new feature: queue editor. Probably something like this: while in flight, user clicks on a button and FC stops receiving new commands. Instead, it opens new window where every action user does is added into list, with its description, field for the delay, (optional) buttons to move it up/down the queue and [X] button.

• Every part should have all of its actions unlocked (so that you could set both extend and retract actions for gear/antennas/solar panels irregardless of their current state).
• Delay field for every action should have a radiobutton nearby (to set relative delay).
• Moving every action up/down the queue should set the delay accordingly (equal to delay of next/previous action in the queue). Drag&Drop interface would be even better.
• [[x]] deletes action from the queue.
• Finally, two buttons: Accept and Cancel, to load action list into queue and start transmission or drop it. Both give back control over the craft to player.

If the queue will be persistent than it may be a good idea to give player an option to set action UT instead of delay. If possible, with KAC integration.

[Starstrider42]

Already requested: #26. While I agree that it would be a cool feature, I also agree with Cilph that this is probably too ambitious, especially since the flight computer was never intended to replace full-featured autopilots like kOS or MechJeb.

I was looking more for short-term ideas, i.e. small, relatively easy changes we can add in the next few releases. Even a limited queue editor would be a major update in itself.

[Peppie84]

Here are two small ideas:

• A small button to the right as Starstrider42 said + hover text
  
• A small button on any queued command to get the delay from this + hover text
  

I always have the problem that i want to add a new command right after a queued command, and typing the complete delay string confused me so much.

What do you think?

[Starstrider42]

I like screenshot 1. For screenshot 2, how does it work with burns (the case where I personally would be most likely to use this feature)? I've confirmed (by using SmartParts to auto-stage) that the 1.4.0 flight computer does recalculate burn times as needed, so I can see this getting messy if updated times need to propagate to other commands.

[Peppie84]

yeah that's the weird part on feature 2. Its currently the start time of your burn/maneuver. (command.Delay + command.ExtraDelay) But if you wait your burn time and than adding the new command you will be after this :D

Edit: But if click the new copy button, wait your burn time and than adding the new command you will be after this :D

If you want you can try it (maybe not bug free, its only a draft)
https://www.dropbox.com/s/uiv1r0l1cno7qjw/fc_mandelay_addition.dll.only.zip

[Starstrider42]

That could make it tricky, since if you specify the burn as either a maneuver node execution or as a delta-V requirement, you can't see in advance how long it will take.

I'll take a look, but probably not today. Since I've been on KSP hiatus for a month and am still juggling some RL stuff, just trying out the 1.4.1 release candidate will probably take up all my free time.

[jdmj]

Guys, have you seen this editor?
http://forum.kerbalspaceprogram.com/threads/98270-WIP-Plugin-DL-Flight-Computer-Fully-automated-flight-programmable-via-VPL

[Starstrider42]

No, thanks for the link.

[Starstrider42]

@Cilph and @erendrake, you guys are more familiar with the nuances of RemoteTech.API.AddSanctionedPilot() than I am. Can you comment on @pixartist's question at http://forum.kerbalspaceprogram.com/threads/98270?p=1507965#post1507965? It sounds like we might have a compatibility problem, but I never fully grasped what it was about MechJeb that made AddSanctionedPilot() not work.

[gregoire-astruc]

Hello,

I skimmed through most of it, but I agree that there is a usability/ergonomics issue with this manual delay.

It took me quite some time to see the small input to set the manual delay: I always tried with the obvious large one with the "0s" text in it :)

The documentation on manual delay is also very vague on the subject (it never says you must show the queue in order to access the input).

Hopefully you guys can enhance our UX!

[Peppie84]

So i added the delay + burn time to my second suggestion.

i'll pr this for 1.6

[JDPKSP]

I'm currently playing with the extraDelay functionality a bit. I'm thinking about expanding it to a whole set of conditionals (eg.: altitude, height from terrain, speed, and so forth), so the player has more control over when a command will pop. The current behaviour is:
if the timestamp has passed and the condition is met (or there is no condition) the command will pop.
I've implemented some rudimentary Tminus estimation for conditions, for use with timewarp throttling as well.

you can take a look at my preliminary work here:
JDPKSP/RemoteTech2/Conditionals

Conditionals are mainly intended to make it easier for the player to land and take off within signal delay, so that being said some more stuff will need to be added (notably autostaging and speed controlled throttle commands). I'd like to hear your thoughts before I do any pull requests.

My intention is to change the behaviour (of mainly the UI) a bit:

QueueFragment:
To the immediate left of the text input field (currently referencing mExtraDelay) there will be a combobox from which you can switch condition types (defaults to: None).
text input into the input field is parsed in conjunction with the selected condition type into a condition whenever a command is enqueued within the flight computer. Meaning that the player does not need to press enter to activate a condition. Since conditions are only pushed together with commands, it is unnecessary to have the player press a button two times in order for the flight computer to send the command they want to.

Perhaps We'd want to continually check if the string is parseable, and turn the field background red if not, alerting the user that their condition will fail (akin to what HyperEdit does).

FlightComputer:
Add support for rudimentary autoStaging. Where the flight computer will automatically stage if all engines in the active stage go out of resources.

Since AutoStaging is a setting within the satellite itself, reaction to the press of the toggle needs to be subject to signal delay (+ condition). Therefore a new command will be added that simply feeds a value back to the flight computer. Room for expansion with this one in case there are other fields we wish to subject to signal delay
(wouldn't it be wonderfull if someone found a way to hook into GuiActive fields, so we could close the current exploit of throttle clamping engines for instant control)

Add KeepSpeed option to burn commands. Where the flight computer assumes that you are pointing retrograde/vertical and controls the throttle to maintain a constant surface speed. This is mainly intended for landing and takeoff maneuvers.

AttitudeFragment
set the default throttle to 100%
Compress the textfield for time or D/V input to 1/3 width and place a combobox immediately to its right for toggling between the three modes(time, D/V or keep speed). The last 3rd of the space (right-most) is reserved for a toggle for autostaging. Pressing it will immediately queue an InternalCommand, and popping it will set the visual value of the toggle (up/down).

[neitsa]

I'm closing this issue for the following reasons:

1. The delay feature on the FC Window was implemented
2. As discussed here, Flight Computer: set up command queue manually  #26 is a proposal we'll implement in the 2.x branch.
3. Expanding flight computer: pop conditions, "keep speed" mode, autostage and possibly ignoreRotation for pitch, roll, yaw, orientation #498 is a list of features from @JDPKSP we'd like to implement (this one stays open, I'm adding a note on this issue to link to the comment)
4. We'll do a complete FC overhaul for RT 2.0 (at least from a code POV, but maybe also for the interface).