Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add direct values input apart from sliders. #2121

Closed
misiektw opened this issue Apr 3, 2019 · 8 comments
Closed

Add direct values input apart from sliders. #2121

misiektw opened this issue Apr 3, 2019 · 8 comments
Milestone

Comments

@misiektw
Copy link

misiektw commented Apr 3, 2019

Please add/convert numerical value fields, so we can input values directly for all Flight Plan parameters. Something similar to MJ maneuver editor.

I've been playing with Principia for the past few years, and it's great, except that horrible sliders.
I mean, with game stuttering you will almost always overshoot. I could plot Moon trajectory in few seconds with numeric input, but with sliders, it sometimes takes like minutes. Not to mention longer plots, when you want to put MN on distant body periapsis, it's just ridiculous how much time is wasted when trying to fiddle with those sliders, when I know exact number I want already.
Of course, helpers would be nice like in Precise Manouver, when you can one-click snap MN to AP/PE/AN/DN etc., but that is just wishful thinking =)

So, for the love of Newton, PLEASE allow to input exact numerical values apart from sliders, converting current read-only fields to editable and getting values from them should be enough.

@eggrobin
Copy link
Member

eggrobin commented Apr 3, 2019

Of course, helpers would be nice like in Precise Manouver, when you can one-click snap MN to AP/PE/AN/DN etc., but that is just wishful thinking =)

We are considering this (but this is complex), see #1936 (comment).

converting current read-only fields to editable and getting values from them should be enough.

You may have noticed that the timing of the manoeuvre is shown as a countdown, not an absolute time (this avoids having to have a date system, which is another can of worms entirely, especially in stock where we could not just use our existing calendar and time scale logic).

Editing a field that is counting down is unlikely to be convenient.
Once we have timing relative to an apsis or node, the timing could be expressed as a fixed duration, which could then be edited.

@misiektw
Copy link
Author

misiektw commented Apr 3, 2019

Editing a field that is counting down is unlikely to be convenient.

Well, I agree, and I forgot about counting down, mea culpa. But there could be separate text field to enter a rough value, which would be copied into t-initial after pressing a button. There is often a situation when setting time even within an hour or a day would be helpful on longer plots.

However, rest of them - plan length, tangent, normal and binormal don't have this issue... And they're a pain to set with sliders too sometimes. Especially tangent. For Moon, when I have to slide to 3150m/s for the 100th time and I'm getting stutter almost every time hitting around 3000, and after the stutter counter is at 6000+ already. So I have to scroll back and pray that there won't be another stutter when approaching the desired value from above... Beyond annoying.

While at it, sliders sensitivity limiter would be nice also. Like text field you could enter max delta value. For example 1m/s/s at maximum slide to left or right, then interpolated for intermediate slider positions.

@pleroy
Copy link
Member

pleroy commented Apr 3, 2019

We discussed replacing the countdown by a time-between-manœuvres field, as it would avoid the countdown problem entirely, and it would actually be more useful when you have two manœuvres in the future separated by a short time. The only awkward bit is to define the reference time for the first manœuvre. Presumably it would have to be the time of creation of the flight plan in the UI.

@misiektw
Copy link
Author

misiektw commented Apr 5, 2019

I understand t-initial is an issue because each one is defined as absolute UTC time and You want to change it to relative time. But let's forget t-initial for now, and focus on deltaV components.
As per eggrobin explanation in #1936, I can't see a reason why you can't slap text fields for the tangent, normal and binormal.

UI overhaul would be great, but that's a lot of work and prone to new bugs, so probably months away. Adding 3 widgets and getting value to/from them should be pretty fast, and would be a huge help.

There is already reset to 0 so you could just reset to arbitrary value from text field, can't you? There is space for that in UI after tangent, normal and binormal.

@eggrobin
Copy link
Member

eggrobin commented Apr 5, 2019

I understand t-initial is an issue because each one is defined as absolute UTC time and You want to change it to relative time.
But let's forget t-initial for now

Why forget it? We have a solution to this problem, as outlined in @pleroy’s comment.
How the timing is internally defined is not the relevant part; what matters is how it is displayed, since it is the displayed value that is edited.
The current display as a countdown is awkward (and makes editing infeasible), whereas displaying the time since engine cutoff at the previous manner (a bit like, say, Apollo time bases) would both solve the issue of the timing of two nearby far-future manœuvres being illegible, and make the displayed value stable and thus amenable to text editing.

I can't see a reason why you can't slap text fields for the tangent, normal and binormal.

If we are going to do this, we are doing it for all of those sliders; otherwise we will introduce a great deal of complexity to separate those sliders whose value can be edited by text entry from those that cannot.

@misiektw
Copy link
Author

misiektw commented Apr 5, 2019

I edited, because I was expecting that answer about replacing fields, sorry eggrobin.
That's why I suggested reset to arbitrary value without touching current fields.

@eggrobin
Copy link
Member

eggrobin commented Apr 5, 2019

Adding things next to some sliders but not all would be just as complex, and would waste UI space with redundant information.
All these (label, value display, slider, zeroing button) “differential slider” widgets are controlled by the same code, and adding a separate widget that controls the same value would just make a mess of the code.

Instead the differential slider should be extended to support text edition.

@misiektw
Copy link
Author

misiektw commented Apr 5, 2019

Instead the differential slider should be extended to support text edition.

Well, of course, I wasn't suggesting which class you should put it into, and I only glanced at the UI code for a few minutes. Extending differential slider is a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants