Kerbal Space Program 1.7: “Room to Maneuver” Grand Discussion Thread

[dok_377]

1 hour ago, 5thHorseman said:

I'm not the one who decides these things but I don't think that bug is severe enough to warrant a special release to fix.

The fairings themselves can be essential for some crafts. Building custom capsules with rovers in them, for example. That's how I found that bug, because my Duna rover with custom capsule doesn't work how it should anymore. Even if you somehow manage to get rid of the decouple bug (which i figured out how to do in this case), then you get slapped in the face by the byproduct of that bug: rcs doesn't fire until you de-render the fairing, which is impossible in the atmosphere due to extended render range. And my skycrane relies on rcs for orientation. I'm not even going to start imagining how many designs are going to be broken due to this change. Even the basic rockets in some cases. I'm not saying that it's straight up unplayable, but it can be almost as bad as broken aerodynamics. Some people might not even see that much of a change, but other people crafts might not work at all. Either way, no biggie, my duty here is to report a bug, not tell people how fast they should do their job. 

[klgraham1013]

 

On 4/18/2019 at 7:19 PM, dok_377 said:

It seems like 1.7.1 is needed indeed. I found a bug with interstage fairings: https://bugs.kerbalspaceprogram.com/issues/21915

On 4/18/2019 at 8:16 PM, 5thHorseman said:

I'm not the one who decides these things but I don't think that bug is severe enough to warrant a special release to fix.

I don't know.  Base functionality of a part being broken seems pretty big.  Then again, I had to wait a year to safely drive solar panels through the Mk3 cargo ramp.  So, who knows when Squad will get to it.

[Superfluous J]

2 hours ago, klgraham1013 said:

Base functionality of a part being broken seems pretty big.

The base functionality isn't broken. A specific use case is. There's even a workaround if I'm reading the bug report correctly.

[dok_377]

7 hours ago, 5thHorseman said:

The base functionality isn't broken. A specific use case is. There's even a workaround if I'm reading the bug report correctly.

It's not just the base functionality. Rcs is broken too. Deploying the interstage all the time to fix that is pretty annoying if you want to save the look of the stage (falcon 9 replicas, for example), and sometimes deploying the interstage will explode the rocket, so it needs to be grounded or completely redesigned. Seems excessive to me. The workaround of changing the root part of the vessel isn't going to fix everything. Sometimes you just NEED to have the root part at the same stage as the fairing. 

[Superfluous J]

3 hours ago, dok_377 said:

It's not just the base functionality. Rcs is broken too. Deploying the interstage all the time to fix that is pretty annoying if you want to save the look of the stage (falcon 9 replicas, for example), and sometimes deploying the interstage will explode the rocket, so it needs to be grounded or completely redesigned. Seems excessive to me. The workaround of changing the root part of the vessel isn't going to fix everything. Sometimes you just NEED to have the root part at the same stage as the fairing. 

I'm not saying it's not a bug. I'm not saying it shouldn't be fixed. I'm saying that making a replica down to the detail that the interstage fairing stays intact MIGHT NOT BE a valid reason to release a bugfix patch, especially when there are multiple workaround such as re-rooting and deploying the fairings.

I have a few personal bugs that have been in the game since before 1.0. One of them requires I either edit the persistent file or hack a copy of the ship into orbit with the bug fixed, as there is no workaround when it happens. Why should this get a special release but those not? Because it's new? I can't revert to 1.6 and fix my bug. I can't revert to 0.22 and fix it.

Edited April 20, 2019 by 5thHorseman

[dok_377]

4 hours ago, 5thHorseman said:

I'm not saying it's not a bug. I'm not saying it shouldn't be fixed. I'm saying that making a replica down to the detail that the interstage fairing stays intact MIGHT NOT BE a valid reason to release a bugfix patch, especially when there are multiple workaround such as re-rooting and deploying the fairings.

I have a few personal bugs that have been in the game since before 1.0. One of them requires I either edit the persistent file or hack a copy of the ship into orbit with the bug fixed, as there is no workaround when it happens. Why should this get a special release but those not? Because it's new? I can't revert to 1.6 and fix my bug. I can't revert to 0.22 and fix it.

Well, I'm not asking for special treatment. It would be nice of them to fix that bug in a patch, but that's probably not going to happen, as squad is not known for releasing a bunch of hotfixes to fix individual bugs. And I'm not seeing that much bugs to be confirmed on the tracker to make a list sufficient enough for a patch. If we need to wait for 1.8, so be it. 

Edited April 21, 2019 by dok_377

[maceemiller]

Looking forward to playing 1.7......

I've had a break from gaming since January and when I get back back from the holiday I'm currently on it's time to fire up the 'ol PC, update KSP and take to the black void again

[Tyko]

@SQUAD  I've been playing around with the new Maneuver Node controls in 1.7. They're good. They don't completely replace all the abilities of the mod versions, but they have the basic controls needed for most players.

The maneuver node control points really need the ability to press & hold for repeat clicks. Having to manually click-click-click the node buttons is annoying. 

Otherwise, great job!

Edited April 23, 2019 by Tyko

[OHara]

On 4/23/2019 at 8:30 AM, Tyko said:

The maneuver node control points really need the ability to press & hold for repeat clicks.

The , , etc. icons in the new maneuver panel are pull-handles as well as buttons, like the ones in the map-view maneuver-node adjuster.  That is, you can drag them either direction to adjust the burn, as well as click on them.  They don't yet work as well as the originals in map-view; in particular the icons don't look drag-able and don't move when you drag, and don't give as much variability in the speed of change.

I like the pull-handle function of the map-view gizmo better then auto-repeat on hold-down of the button.

[Edit: But, even if the new maneuver panel has simple auto-repeat buttons, we would still have the pull-handle of the gizmo on the map view. ]

Edited April 26, 2019 by OHara
looking again, the pull-handles have enough variability in speed of effect

[Tyko]

3 minutes ago, OHara said:

The , , etc. icons new maneuver panel are pull-handles as well as buttons, like the ones in the map-view maneuver-node adjuster.  That is, you can drag them either direction to adjust the burn, as well as click on them.  They don't yet work as well as the originals in map-view; in particular the icons don't look dragable and don't move when you drag, and don't give as much variability in the speed of change.

I like the pull-handle function of the map-view gizmo better then auto-repeat on hold-down of the button.

why can't we have both...auto-repeat feels more precise to me as the pull method scales with how far you pull as well as how long you're holding the button, so trying to hold at an exact steady pull to advance is very difficult. A simple repeat when you hold it down function is easier for me to control.

[Guest]

deleted

Edited March 29, 2020 by Guest

[Terwin]

21 hours ago, Tyko said:

why can't we have both...auto-repeat feels more precise to me as the pull method scales with how far you pull as well as how long you're holding the button, so trying to hold at an exact steady pull to advance is very difficult. A simple repeat when you hold it down function is easier for me to control.

If click and hold auto-fires repeat clicks then that breaks the attempt to drag a small amount where it may be a few moments of the button held down before you pass the threshold to start the drag.

Also, if you have auto-click on hold then that either constantly increases so long as you are dragging something, or you are at risk of auto-click disabling because of an accidental tiny drag adjustment.

Generally it is better from a UI design prospective to only have one click-and-hold behavior at a time, as trying to have multiple functions will only cause erratic and unexpected behaviors.

Perhaps you can advocate for a setting to allow either auto-click or drag behavior on hold?  If the behavior is determined by a setting, then you don't have to worry about having the computer read your mind on which one you want to use this time.

[klesh]

On 4/23/2019 at 11:30 AM, Tyko said:

The maneuver node control points really need the ability to press & hold for repeat clicks. Having to manually click-click-click the node buttons is annoying.

 

Presumably the intended solution is to raise the scale of the clicks with the little slider to reduce repeat clicks?

[DMagic]

The new maneuver node handles don't work as buttons (at least I'm pretty sure they don't, the scroll wheel does work, though), and they don't work based on how far you pull the handle (like the old maneuver gizmo does), instead they work based on how fast you pull the handle. 

Instead of dragging the mouse further away to increase the effect you have to quickly jerk the mouse, I guess part of the problem is that the UI is down in the corner, so you can only pull down or left so far before you run out of room. The problem I've found, is that it seems difficult to alter the change rate after you have started dragging the handle, if you start with a quick movement to make a larger change in dV, then you can't really slow down without starting over. And there seems to be fairly little difference overall, even a very fast mouse movement only makes the dV change a little bit faster.

It makes it a little awkward to control when you have been trained by the regular maneuver node to do it a different way for so long. There you just modify how far you are pulling the handle to adjust the increment. I guess we are supposed to rely on the dV scale slider. Or maybe they should come up with a different UI for adjusting the maneuver node, instead of trying to replicate the existing system in a condition where it clearly isn't well suited.

Also, the dV increments are a little silly, when has anyone ever needed 1000m/s per tick? That could be topped out at maybe 100m/s and add more increments at the low end for extremely precise maneuvers (or probably just make fewer increments).

Edited April 25, 2019 by DMagic

[Superfluous J]

15 minutes ago, DMagic said:

Also, the dV increments are a little silly, when has anyone ever needed 1000m/s per tick? That could be topped out at maybe 100m/s and add more increments at the low end for extremely precise maneuvers (or probably just make fewer increments).

Agreed. Also a way to change that increment via (for example) alt-scrollwheel when your mouse is anywhere in that UI frame.

[Dunbaratu]

Is anyone else noticing that if you use arrow keys to move the text cursor while typing in the new type-in fields to edit maneuver nodes, the camera turns?  I think the default keybinding to turn the camera is still active when typing in the field.

[OHara]

The handles of the maneuver-adjust gizmo in the new maneuver-mode panel do work as buttons for me.
I am also frustrated by the fact that once you pull the handle to make a quick change, you cannot slow down that change without releasing and re-pulling.  If it is possible to copy exactly the behaviour of the map-view gizmo, that would be nice.
(Of course I'd like the pull-handles to be alongside the type-in boxes, and a several of other changes, some of which might be unwise, but I don't know which.)

6 hours ago, Steven Mading said:

Is anyone else noticing that if you use arrow keys to move the text cursor while typing in the new type-in fields to edit maneuver nodes, the camera turns?

Yes, but only once or twice. 
Usually for me, the arrow keys move the cursor when focus is on the text-entry box, and rotate the view when focus is elsewhere.  I wish I knew exactly how to trigger (and thus how to avoid) the bug.

[Superfluous J]

26 minutes ago, OHara said:

The handles of the maneuver-adjust gizmo in the new maneuver-mode panel do work as buttons for me.
I am also frustrated by the fact that once you pull the handle to make a quick change, you cannot slow down that change without releasing and re-pulling.  If it is possible to copy exactly the behaviour of the map-view gizmo, that would be nice.
(Of course I'd like the pull-handles to be alongside the type-in boxes, and a several of other changes, some of which might be unwise, but I don't know which.)

Yes, but only once or twice. 
Usually for me, the arrow keys move the cursor when focus is on the text-entry box, and rotate the view when focus is elsewhere.  I wish I knew exactly how to trigger (and thus how to avoid) the bug.

Maybe it depends on where the mouse cursor is?

[Guest]

I feel two things I think should be fixed from this update;

1. I think that you should fix the maneuver mode, whenever you click on the maneuvers they get really big

2. And the lighting is too dark, right after I updated it got really dark in the night. It would be nice to see your spacecraft at night

On 4/17/2019 at 2:40 AM, RealKerbal3x said:

There's a slider next to the graphical manoeuvre editor that allows you to change the 'strength' (so to speak) of the editor. Also, you can enter numerical values to make it more accurate.

Yeah I found it recently

[Superfluous J]

2 hours ago, The Doodling Astronaut said:

1. I think that you should fix the maneuver mode, whenever you click on the maneuvers they get really big

Nodes do get bigger when you click them. I don't know if the size is settable in an option or config setting but...

2 hours ago, The Doodling Astronaut said:

2. And the lighting is too dark, right after I updated it got really dark in the night. It would be nice to see your spacecraft at night

...this one is settable. I don't recall the wording of it but it's a global setting, off of the main menu.

I suspect when you updated you lost your config from the old version.

[OHara]

1 hour ago, 5thHorseman said:

Nodes do get bigger when you click them.

There is a bug where they sometimes stay bigger after the click (already on Squad's list at 21943) and then get even bigger on the next click.

And answering three posts up, the arrow keys both moving the cursor in the type-in boxes and intermittently rotating the view, shows no simple relation to where the mouse cursor is.

 

On a new related topic, does the 'ejection' angle, in the second orbit-information tab, make sense to anyone ? 
It does not have any obvious relation to the similarly-named angle defined in Olex's and AlexMoon's on-line transfer planners, even though the mouse-hover text gives a definition that does match those in the transfer planners.

[Superfluous J]

1 hour ago, OHara said:

On a new related topic, does the 'ejection' angle, in the second orbit-information tab, make sense to anyone ? 

After some fiddling... No. I can't figure it out either. I never really paid much mind to the number anyway though.

[maceemiller]

Odd? 1.6 works fine yet a new 1.7 install is as choppy as you like? Done a defrag etc but no change? No mods etc....stock install....dissapointed...

[Guest]

15 hours ago, 5thHorseman said:

Nodes do get bigger when you click them. I don't know if the size is settable in an option or config setting but...

...this one is settable. I don't recall the wording of it but it's a global setting, off of the main menu.

I suspect when you updated you lost your config from the old version.

Yeah maybe 

[Azimech]

2 hours ago, maceemiller said:

Odd? 1.6 works fine yet a new 1.7 install is as choppy as you like? Done a defrag etc but no change? No mods etc....stock install....dissapointed...

Noticed this as well.