Make time warp remember your selection, reduce time warp to 50x near SOI changes

[technicalfool]

The idea is that the game should remember if it reduced your time warp during a low swing around a planet, and increase back to the original warp value when it's far enough away from the body it's orbiting around.

UI-wise, perhaps if you try to warp faster than allowed, the game paints the unavailable arrows on the warp indicator red. These will paint themselves green as you increase in altitude and the game raises your warp speed to the selected value.

This could also work in tandem with a much higher warp speed (or speeds) that only become available in interplanetary space. As soon as you get within some reliable distance of a SOI, you drop down to a warp value that's low enough to not ruin your projected periapsis in floating point errors.

[Kasuha]

For SOI changes it's unnecessary. All that's needed is fixing the bug that causes trajectory errors if you cross the SOI boundary at higher warp levels.

But for when the warp speed is reduced due to planet proximity, that would be quite nice.

Or the game might be a bit smarter about it and only reduce the warp speed if I am going to hit the atmosphere or surface.

[rkman]

For SOI changes it's unnecessary. All that's needed is fixing the bug that causes trajectory errors if you cross the SOI boundary at higher warp levels.

I think that's not a bug but an inevitable consequence of reduced accuracy at high timewarp.

[technicalfool]

For SOI changes it's unnecessary. All that's needed is fixing the bug that causes trajectory errors if you cross the SOI boundary at higher warp levels.

From what I'm aware (and that's not all that much), that's not a little bug. It has more to do with the limitations of even 64 bit numbers. There's some code libraries out there for handling really really big number types in C#, but I'm not sure how fast the CPU is going to be able to crunch through them given it's a speed vs accuracy compromise, or whether the really big numbers can somehow be used really sparingly!

[technicalfool]

I think that's not a bug but an inevitable consequence of reduced accuracy at high timewarp.

That's what I'm thinking. Having the game detect when you're [some reliable distance] from an SOI or the main body and drop out of hyper-warp could be a compromise that would allow gazillion-times warp speed in interplanetary space, but the time warp drops automatically when close to an SOI, or crossing an SOI boundary.

It would probably kill a bunch of amusingly bad related bugs, like warping through planets. The game already attempts to drop your warp speed if you're getting close to a lithobraking manoeuver. It just needs tweaking a bit, perhaps making more aggressive at high warp speeds so it doesn't miss the atmosphere and give you a free ride to Moho via Jool.

[rkman]

The 'reduce timewarp as distance to body decreases'-mechanism used to be much more aggressive in older versions of ksp. As far as i can remember accidental overshooting occurred less frequently back then. Downside was being limited to lower timewarp while in orbit, compared to how it works now. General consensus seemed to be that timewarp limits in orbit were to low, and it was changed to what we have now.

A workable solution might be to have aggressive auto-reduction of timewarp (including when about to cross soi boundary), which can then be manually overridden to one or two steps faster timewarp.

[Kasuha]

I think that's not a bug but an inevitable consequence of reduced accuracy at high timewarp.

It is only inevitable consequence of the current implementation of timewarp. I don't know the code but I have very good rough idea how is it implemented. And I am rather sure the implementation can be improved to provide smooth SOI transition at any time warp level.

From what I'm aware (and that's not all that much), that's not a little bug. It has more to do with the limitations of even 64 bit numbers. There's some code libraries out there for handling really really big number types in C#, but I'm not sure how fast the CPU is going to be able to crunch through them given it's a speed vs accuracy compromise, or whether the really big numbers can somehow be used really sparingly!

Double precision numbers are standard for quite a while even on 32-bit machines and with these numbers you can hold diameter of solar system in sub-milimeter accuracy. KSP system is order of magnitude smaller. Errors in SOI transitions are not caused by this, otherwise you'd not be able to transit the SOI boundary correctly even at 1x time.