KSP Loading... Preview: Advanced Maneuver Mode

[GrandProtectorDark]

2 hours ago, Gapone said:

1.7.0

1.7.1

1.X.0 versions always have some big problems that need fixing 

[evileye.x]

1 hour ago, mystik said:

Because waiting for 2 weeks to get a mod updated is a big no-no.

Actually, sometimes it just works in new version. 

And I need 100+ mods in my game anyway

And Maneuver Editor has "circularize" button and numpad controls. I always hated drag-and-prey Maneuver gizmo

 

Edited April 5, 2019 by evileye.x

[mystik]

49 minutes ago, evileye.x said:

Actually, sometimes it just works in new version. 

And I need 100+ mods in my game anyway

And Maneuver Editor has "circularize" button and numpad controls. I always hated drag-and-prey Maneuver gizmo

 

I need about 10 mods and I rather need none. I don't need the extra features you mentioned. I just want the flight data (altitude, angles, speed) and had to resort to Kerbal Engineer for this, which is never updated on launch day. So now I will just need one less mod. I still rather do the maneuvers on my own rather than have the computer figure everything for me. If the computer does it all for me then I might as well watch Matt Lowne play because my input is reduced to pressing a button (same as playing a video on Youtube).

[klgraham1013]

4 hours ago, Gapone said:

1.7.0

He had it right the first time. 

[GrandProtectorDark]

1 hour ago, mystik said:

resort to Kerbal Engineer for this, which is never updated on launch day.

KER is one of those mods that worked fine with the past 3 major updates without needing to be updated itself.

[Superfluous J]

19 hours ago, StrandedonEarth said:

Navhud (autocowreck tried to replace that with Nachos) was nice, I used that but not for docking. I was referring to the Navball DAL, which just adds a red circle to the navball, not the NF version with its own window 

Amusingly I have both installed usually, and use both for docking. At the same time.

[GrandProtectorDark]

3 hours ago, mystik said:

 Because waiting for 2 weeks to get a mod updated is a big no-no.

Tbh, judging by the past major updates, you'd still need to wait for any of the serious new version bugs to be fixed anyway. 

Or it's like all updates from 1.4 upwards and most stuff works anyway.

[Xurkitree]

If there's one complaint I have with this, is the update frequency of the AP/PE displays. You would expect much less lag between readout updates, and instead just smoothly increment. The same goes for the DV calculator, but I'm willing to give a bit of leeway there.

AP/PE are values taken directly from the game and displayed, the refresh should so fast it appears live, like how KER's HUD updates itself.

Such a slow display speed would have problems, especially when dealing with large laggy craft. 

[DMagic]

8 minutes ago, Xurkitree said:

If there's one complaint I have with this, is the update frequency of the AP/PE displays. You would expect much less lag between readout updates, and instead just smoothly increment. The same goes for the DV calculator, but I'm willing to give a bit of leeway there.

AP/PE are values taken directly from the game and displayed, the refresh should so fast it appears live, like how KER's HUD updates itself.

Such a slow display speed would have problems, especially when dealing with large laggy craft. 

We should all be hoping that the displays don't update every single frame. That would be a significant performance optimization (and if you think KER's constantly updating display isn't barfing out 10X as much garbage allocations as KSP's baseline you're fooling yourself), this kind of conversion of numerical data to a text display comes with unavoidable garbage creation. Updating the text every other frame, or 3rd, or 4th frame significantly cuts down on that effect while being barely noticeable for most players. If you have a large craft causing low frame rates then the display will always look a little laggy, but one solution might be updating based on real-world time, rather than frame rate; update 5 times per second instead of, say, every 4th frame, or something like that.

Edited April 5, 2019 by DMagic

[Xurkitree]

3 hours ago, DMagic said:

We should all be hoping that the displays don't update every single frame. That would be a significant performance optimization (and if you think KER's constantly updating display isn't barfing out 10X as much garbage allocations as KSP's baseline you're fooling yourself), this kind of conversion of numerical data to a text display comes with unavoidable garbage creation. Updating the text every other frame, or 3rd, or 4th frame significantly cuts down on that effect while being barely noticeable for most players. If you have a large craft causing low frame rates then the display will always look a little laggy, but one solution might be updating based on real-world time, rather than frame rate; update 5 times per second instead of, say, every 4th frame, or something like that.

Yeah, I agree, but this issue exists with the DV calculator as well, and at low fuel levels, you can have engine flameouts before the DV readout reaches close to zero.

[Capt Snuggler]

next you'll be adding stock clouds, at which point my heart will stop.

[Ratwerke_Actual]

8 minutes ago, Xurkitree said:

Yeah, I agree, but this issue exists with the DV calculator as well, and at low fuel levels, you can have engine flameouts before the DV readout reaches close to zero.

I had this issue on an Eve Launcher. Granted, Eve (or anywhere with atmo and terrain) strains my poor netbook, so I had more pressing issues.

[Bill Phil]

4 hours ago, DMagic said:

We should all be hoping that the displays don't update every single frame. That would be a significant performance optimization (and if you think KER's constantly updating display isn't barfing out 10X as much garbage allocations as KSP's baseline you're fooling yourself), this kind of conversion of numerical data to a text display comes with unavoidable garbage creation. Updating the text every other frame, or 3rd, or 4th frame significantly cuts down on that effect while being barely noticeable for most players. If you have a large craft causing low frame rates then the display will always look a little laggy, but one solution might be updating based on real-world time, rather than frame rate; update 5 times per second instead of, say, every 4th frame, or something like that.

From my understanding the physics calculations are done based on frames. 

[DMagic]

25 minutes ago, Bill Phil said:

From my understanding the physics calculations are done based on frames. 

I'm not talking about physics calculations. KSP is already calculating all of these orbital parameters and other related data all of the time, on every physics frame. That is not going to change in 1.7.

I'm talking about taking those numerical orbital values, converting them to a string of text, which generates garbage allocation in two unavoidable ways (it's technically possible to avoid the garbage allocation inherent to converting a numerical value to a string, but the string itself will always generate garbage), then displaying that text on screen. That has nothing to do with when the physics calculations take place. That is just a matter of when you want to update the UI, which can be done whenever you choose.

[Bill Phil]

1 hour ago, DMagic said:

I'm not talking about physics calculations. KSP is already calculating all of these orbital parameters and other related data all of the time, on every physics frame. That is not going to change in 1.7.

I'm talking about taking those numerical orbital values, converting them to a string of text, which generates garbage allocation in two unavoidable ways (it's technically possible to avoid the garbage allocation inherent to converting a numerical value to a string, but the string itself will always generate garbage), then displaying that text on screen. That has nothing to do with when the physics calculations take place. That is just a matter of when you want to update the UI, which can be done whenever you choose.

That has a lot to do with when the physics calculations are done, since updating the values requires calculations. 

If the game is chugging then updating after an interval may not be possible because the math hasn’t been done yet.

[DMagic]

24 minutes ago, Bill Phil said:

That has a lot to do with when the physics calculations are done, since updating the values requires calculations. 

If the game is chugging then updating after an interval may not be possible because the math hasn’t been done yet.

The UI will (generally) always be updated after physics calculations are run. But that has nothing to do with whether you want to update that UI every frame, or you to update with less frequency. 

The Unity object life-cycle dictates in what order code is run. But that has no bearing on what I'm talking about, which is whether or not the UI is being updated every frame, or not.

This isn't like multithreading where you have to worry about two different threads accessing the same object in memory; whether the physics math is slow or not has no bearing on the relative frequency with which you update the UI.

[OrbitalBuzzsaw]

So how likely is 1.7 to break 1.6-compatible mods? Cause I just got my install working again, and I have some mods last updated for 1.4 that I need to keep my save operational.

[AVaughan]

2 hours ago, OrbitalBuzzsaw said:

So how likely is 1.7 to break 1.6-compatible mods? Cause I just got my install working again, and I have some mods last updated for 1.4 that I need to keep my save operational.

Probably similar to other recent updates.  Most working mods will continue to work, but anything that is version locked (eg Kopernicus) will refuse to load with the new version.  (Given what could happen to existing save games if Kopernicus did load, but wasn't working properly that is actual the right call).  

But the best course of action is to copy your existing install somewhere else, and that way it can't be broken when KSP updates, and you can chose when to try the updated version.

[GearsNSuch]

If we keep getting features as useful as we have in this and the previous update, by then end of the year KSP should be able to brew my coffee, drive my car, and do my job.

I do particularly like how you tied it into the existing GUI rather than making it an inconvenient popup window. Well done, and thank you!

Hey, we have a release date, but I don't see a hype train thread yet. *Someone* had better get moving...

Edited April 6, 2019 by GearsNSuch

[GrandProtectorDark]

10 hours ago, OrbitalBuzzsaw said:

So how likely is 1.7 to break 1.6-compatible mods? Cause I just got my install working again, and I have some mods last updated for 1.4 that I need to keep my save operational.

Probably not that likely. 

Things like part mods/planet packs (not Kopernicus itself)have good upwards compatibility. 

And last few updates have been rather nice to most plugin based mods. 

Ofcourse we'll never know if something similar to the partdatabase/modulemanager problem is gonna happen again.

Just wait a bit for the first patch to arrive before switching versions. 

 

Spoiler

You can also always chose to downgrade your version via the betas tab on steam or just to make a seperate copy of your ksp install

 

[Xurkitree]

I just keep multiple folders of KSP over my desktop, copied straight from the steam folder. Aslong as I don't derp and overwrite them, they should be fine.

[Fraston]

No more drag-handles? YES!

[OrbitalBuzzsaw]

9 hours ago, AVaughan said:

Probably similar to other recent updates.  Most working mods will continue to work, but anything that is version locked (eg Kopernicus) will refuse to load with the new version.  (Given what could happen to existing save games if Kopernicus did load, but wasn't working properly that is actual the right call).  

But the best course of action is to copy your existing install somewhere else, and that way it can't be broken when KSP updates, and you can chose when to try the updated version.

Good to hear will do.

[Loskene]

I'm gonna chance my arm assuming the SQUAD devs are paying closer attention to this thread than the rest of the forum for the time being, and ask if there might be any tentative plans for what's to come after 1.7? Not asking for details or anything, just wondering if the trend of tidying up some loose ends is going to continue or if they're shifting back towards flagship content after this.

If there is plans to continue giving some neglected parts of the game a fresh coat of paint, I'd like to get in early to stake out my support for a general visual quality overhaul and optimisation at both the high and low end. It would take a lot more mods out of my "must have" category after each update, I don't know about you guys n girls. You can see what I mean by my two posts in this thread: 

 

[Superfluous J]

I've already encountered a bug with 1.7 and it's not even out yet.

I don't have any desire to play 1.6 now that I know what's going to be in 1.7.