Jump to content

KSP2 Release Notes - Hotfix v0.1.3.2


Intercept Games

Recommended Posts

  • KSP2 Alumni

KSP2 v0.1.3.2 Hotfix Release Notes

Bug Fixes 

Map & Tracking Station

  • :1437623226_rocket_1f680(3): Fixed: trajectory position changes when vehicle transitions between Spheres of Influence [Original Bug Report]

UI/UX

 

SUBMITTING BUG REPORTS AND FEEDBACK

If you'd like to provide feedback about this build, there are many different ways to do so:

Submit Feedback through the Game Launcher

Suggest a Change on the Forums

Join us on Discord to discuss potential changes

Bug reports should be shared to:

KSP Forums Bug Reports

:1437623226_rocket_1f680(3): <-- This rocket denotes an issue or change that community members directly helped by sharing or suggesting it to our dev team. Thanks to all of you who send in bug reports and suggestions!

Link to comment
Share on other sites

  • KSP2 Alumni

Thanks to @Draradech, @Niko_Dragovich, @MechBFP, @The Aziz, @sunnyssk, @LameLefty, @Razor235, @Chris_The_Crafter, @Flush Foot, @silent_prtoagonist, @ShroomTheVoice, @StormFury07, @afyber, @D-Rex, @Rocktagon619, @Diskervery, @CaptainParallax, @Scarecrow71, @alohl669, @Starhawk, @ChromeDome, @Ambious, @Rubenio, @Scidleee, @vianna77, @Nnamleips, @pbau5, @Kim Hanson, @running_bird, @RickJM694, @billyBobJoe, @HyenaDae, @Davidian1024, and @Buzz313th for contributing to the bug reports that led to these fixes. And thank you to everyone who upvoted the bugs to the top of the list, ensuring they were on our radar.

Link to comment
Share on other sites

And I can absolutely confirm that the SOI change issue IS FIXED!  I just loaded a game I created way back in 0.1.1 where I headed to Duna, and had it saved in LDO.  Created a trajectory to get back to Kerbin - from the correct position, burning retrograde to Duna's orbit - and it worked!  Trajectory was calculated properly, did the burn (and a few thoughts on that below), and then warped to get out of Duna's orbit.  Trajectory stayed where it was supposed to stay, and I was able to get back to Kerbin in this particular save.  Woot!

Now, the burn.  I have been playing a lot of KSP1 lately, so I wasn't paying attention to the fact that the countdown timer on the maneuver node thing is countdown to when you are supposed to start the burn.  I checked how long the burn was supposed to take (42 total seconds), and when the countdown timer got to 21 seconds (half of the total burn time), I started the burn.  And that worked far better than at any point where I've followed the timer the way it is currently designed.  I think I'm going to keep doing that.

Thank you, @Intercept Games for getting this one fixed!  Major props!

Link to comment
Share on other sites

I tried it on Minmus - it works, the plan no longer sends me out of Kerbin SOI, even predicted Pe isn't changing. Now to try the same somewhere else, I'd have to be bold enough to try interplanetary travel after not touching it for months thanks to no reliable ingame tools for that.

But I did notice a performance drop near planetary surfaces, especially, as usual, Kerbin and KSC. 13 frames is a solid hit compared to average 30 in 1.3.1. In space it's smooth as butter.

Link to comment
Share on other sites

1 minute ago, Scarecrow71 said:

I checked how long the burn was supposed to take (42 total seconds), and when the countdown timer got to 21 seconds (half of the total burn time), I started the burn.  And that worked far better than at any point where I've followed the timer the way it is currently designed.  I think I'm going to keep doing that.

I have to believe that this feature is just not properly implemented yet in KSP2. It tells you to start right where you placed your node, and we all know that's not how it works.  It would also be great if like in KSP1, the dV countdown showed you what is actually left on the burn rather than just statically what the initial dV was. But I guess we'll have to wait for that.

Link to comment
Share on other sites

34 minutes ago, herbal space program said:

I have to believe that this feature is just not properly implemented yet in KSP2. It tells you to start right where you placed your node, and we all know that's not how it works.

That's how it works, in ksp2 though. ksp1 account for an instantaneous burn, that's why you need to burn half before and half after, it's not like that in ksp2 as you can now see the trajectory during the burn (sometimes it's doing weird shapes but that's intended).

Not accounting for bugs of course (inclination change for instance).

Edited by Spicat
Link to comment
Share on other sites

19 minutes ago, Spicat said:

That's how it works, in ksp2 though. ksp1 account for an instantaneous burn, that's why you need to burn half before and half after, it's not like that in ksp2 as you can now see the trajectory during the burn (sometimes it's doing weird shapes but that's intended).

That's not how it works period. If you place a maneuver node, your burn needs to be symmetrically timed around it for maximum efficiency  regardless of the game version.  Putting it all on one side of the node is never the best. That's just orbital mechanics, not the game.

Edited by herbal space program
Link to comment
Share on other sites

17 minutes ago, herbal space program said:

That's not how it works period. If you place a maneuver node, your burn needs to be symmetrically timed around it for maximum efficiency  regardless of the game version.  Putting it all on one side of the node is never the best. That's just orbital mechanics, not the game.

You can move the node to do exactly that, it's just a visualization change

Besides, if you start at the node, the projected maneuver will be what you will have, so it's not a question of efficiency or not, the feature is properly implemented. If you want them to make the node in the middle, make it a suggestion.

Edited by Spicat
Link to comment
Share on other sites

20 minutes ago, herbal space program said:

That's not how it works period. If you place a maneuver node, your burn needs to be symmetrically timed around it for maximum efficiency  regardless of the game version.  Putting it all on one side of the node is never the best. That's just orbital mechanics, not the game.

Have you prepared any long-duration maneuvers, eg. with ion engines? To get from an interplanetary speed to get a capture you need a long burn, and projected trajectory reflects that, it's mostly straight for most of the burn until it turns around the body at the end, just when it forms an ellipse. Start it too early and you're doomed because you're at target speed at half the distance and now you're on a collision course.

Link to comment
Share on other sites

1 hour ago, herbal space program said:

I have to believe that this feature is just not properly implemented yet in KSP2. It tells you to start right where you placed your node, and we all know that's not how it works.  It would also be great if like in KSP1, the dV countdown showed you what is actually left on the burn rather than just statically what the initial dV was. But I guess we'll have to wait for that.

I thought the change was clear but it is how it's designed to work, even if it's got some bugs still in it (I don't particularly like the burn time countdown and preferred the dV remaining indicator of KSP1). In KSP2 you are absolutely supposed to start directly on the node, it's for logically sound reasons.

The two versions are designed quite differently with regards to manoeuvre nodes. In KSP1 the program assumes that you carry out the burn and change your velocity instantly. Therefore, it's mathematically impossible to perfectly execute it but in most cases it's a sufficiently good approximation to start the burn a half duration before the node. If the duration is small compared with the orbital duration, it's not an issue. But escaping from LKO with a Xenon engine for instance would lead to a very different trajectory.

In KSP2 it tries to factor in the duration of the burn as well as the velocity vector change to give a more accurate prediction. The most intuitive way to plan this therefore is to specify the START of the burn time. Perhaps this is important for future interstellar engines which might have crazy long burn times.

OK so there's still issues - it's difficult to precisely execute a normal burn without numbers to go off, there are bugs in it, it doesn't factor in staging I suspect, and you can't specify a variable heading for your burn which is dead useful on big inclination changes for instance or long gravity well climbs. But I can see why the philosophy has changed and agree with it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...