Sun_Serega

You can fix it by installing Community Fixes or my SASed Warp mod (or both). My explanation above.

Release v2.4.0 Made the state of SAS during Warp persistent over game restarts. Should've done so with 2.2, because junky-ness was the only reason I didn't want this to be persistent, but I forgor.

Sometimes presets.json turns into this: { "TimeWarpLevels": [ null, null, null, null, null, null, null, null, null, null, null ], "PhysicsWarpLevels": [ false, false, false, false, false, false, false, false, false, false, false ], "Presets": {} } Probably due to a crash? I wasn't trying to change it during any of the crashes tho... Anyway, when I try to open the mod in game - I just get "Failed to load presets.json!" window, with no option to reset it, so I have to manually delete it and restart the game. Can you please add an in-game reload (from disk, if user fixed it) and reset (fully replace with default) buttons, when presets.json is broken?

Release v2.3.0 The fix to the thrust-on-rails will be a part of the "Community Fixes" mod, starting with v0.13 This version turns off the fix in this mod, but only if you have the right version of "Community Fixes", to avoid incompatibility.

For anyone find this - there is more info with possible solutions in "KSP 2 Modding Society" discord: https://discord.com/channels/1078696971088433153/1163071637214724096/1216032110264057957

Finally got to play my save... But I can neither rescan it (it's already fully scan), nor re-send the science. Can you please make this state fix itself? For instance, you can add a ScienceArchive version field to the save, and if the version doesn't match on load - you run extra expensive checks to fix things like this, where science was already sent, but did not register in ScienceArchive.

Release v2.2.2There were problems with publishing the changelog to the forum and Discord. I think I definitely for sure figured out everything, so time to shoot myself in the foot with live testing for the second (third?) time... This one goes out to all the car emoji haters! Download on SpaceDock

Release v2.2.2 forum auto-post test (something was broken in the github workflow, so I'm testing things) Download on SpaceDock Release v2.2.2 forum auto-post test (something was broken in the github workflow, so I'm testing things) Download on SpaceDock

Release v2.2.2 aaa Download on SpaceDock

Latest mod template has a workflow step that uploads changelog as a forum post. But it was failing time to time. I need this topic to quickly iterate on the workflow. If it's possible, I'd like to delete this topic later.

Updated the mod to version 2.2 Fixed the junky-ness. Spin-stabilization is no longer needed. In other words, @Coin, it wouldn't spin violently anymore. Also, this mod now works if you set speed mode to `Surface` or `Target`.

It does currently spin, but that is mainly visual. It can't destroy your vessel during warp.

Finally found a clue to why I had to use `vessel.transform.left` (with the violent spin) instead of a more meaningful `vessel.transform.forward`. Turns out `vessel.transform` doesn't take into account control part direction (like command pod), and defaults to spaceplane orientation. So even if you build a rocked in VAB - this "forward" is still pointing to the side. And the "left" I was using - when in VAB it's somehow pointing up. Found that `vessel.ControlTransform.forward` works, and doesn't require the "spin-stabilization", but it's still junky if the control part was rotated in any way. Need to test more before I make a release with this. Also, while testing things for this found that warping while landed with this mod turned on in tray breaks the game, basically deleting all trajectory info.

Oh god, hopefully not

You can't cut the throttle while warping. So if you press X while warping it first cuts the warp so the second press can cut the throttle. At least that's my theory why it works like that. I didn't remap anything.

It's not on the chart, so maybe it's one of the mods, but I'm stopping warp with "X". Either way, much better then pressing "<" a bunch of times.

No, it's related but not the trigger. I just explained this bug above. Basically you need high position or velocity. With how floating point numbers work - this lowers precision, triggering that sanity check. High position is easy to get, for instance teleport to a high circular orbit above Jool, its extreamly consistent there. I casually reproduced it first try at the end of my mod's demonstration video.

In my save with "Orbital Survey" Jool survey is done, but it's not shown in the "Science Arkive": Other bodies work fine: Here is a save and importable mod list: https://drive.google.com/file/d/1pyqy-XKKK7QG0ourxzlKocCx3Di8bGhj/view?usp=sharing

Updated the mod to version 2.1 Made things a bit more intuitive and uniform. Now SAS during warp also works with no thrust or if the "maneuver" direction is selected. Also updated the demonstration video and added an explanation to it in the first post.

The technical side of the problem: When warp is engaged with thrust ON, the game tries to calculate the trajectory ("VesselComponent.HandleOrbitalPhysicsUnderThrustStart" method) The end of that method has a sanity check, turning off this thrust-on-rails if either the position or velocity calculated for the current point in time (T=0) on the new trajectory is >=0.01 units off the actual current possition of your vessel. Now, the only way this is telegraphed - is the error message in the Alt+C. This makes it extra nasty, because the game falls back to the non-thrust trajectory but doesn't turn off the engines - they keep wasting fuel with no good way to notice this in time. My solution for myself For now, I've turned off this sanity check in my "SASed Warp" mod, because this bug was preventing that mod from being useful. If the Vanila game were to turn off the thrust-on-rails - with my fix you will instead see a debug message in the Alt+C, with pos(-ition) and vel(-ocity) error deltas. P.S. The same fix was also added to the "Community Fixes" mod starting with v0.13, so having either my mod or CF is enough to fix (hide) this bug. But if you have both, make sure "SASed Warp" is at least v2.3, otherwise there will be a conflict with CF. From my experience of flying in and then out of 800k Jool orbit, the position error is usually much larger for than velocity error. But even with that, it's only enough to lose accuracy over time. There is no noticeable teleportation when warp starts. Possible vanila solutions I imagine a very small fraction of players will use mods. And my fix isn't really a fix - it just hides the problem to make it less annoying. So it's still a good idea to do something official but temporary as soon as possible. You could at least reduce thrust down to 0 and display a warning. And maybe a settings toggle to turn off this sanity check? As for long term - I think using the "double" type for such calculations was easy but a very bad idea: Floating point may look like the right thing to use, given how the scale tends to change rapidly. But when it really matters - is when you make a maneuver that goes through several very different scales. Like LKO Jool transfer with 2 pre-planned gravity assists: off of Tylo and then Laythe. Given that, I think a custom fixed-point numbers would be far more appropriate: unsafe struct Fixed256 { private fixed uint data[8]; //TODO } If you properly use 64-bit carries with 32-bit data words - many things fall into place like puzzle pieces, so it's not as scarry as it might look at first. And I don't think the speed will be an issue, since custom fixed numbers are generally faster (at least when they aren't 4 times bigger) and the "HandleOrbitalPhysicsUnderThrustStart" is already optimized to only be called once in a while.

Updated the mod to version 2.0 2 because there are now 2 fixes with this mod installed: 1. SAS works during warp 2. Thrust under warp always works Make sure to update both SpaceWarp and BepInEx to 1.9.4 - otherwise it might not work.

There is also "Kerbal Life Hacks", as "Community Fixes" but QoL. But I agree rapid development is worth it for now. Look at how "Even Better Time Warp" does it. There is a default and active versions. The active version is unindexed, but if it's missing (like after first install) - it is created as copy of default version.

It's wierder when it doesn't spin. Because that's not a bug but a feature, see demonstration video above. (didn't find how to make it work without the spin) About explosions after warp... I had them before I made this mod, so it's probably unrelated. Well, the main problem with that is reproduction - this bug always disappears after the reload, so I can't even test possible solutions. But it seems like a good old kraken attack on joints.

Do you have thrust on? The main code doesn't run otherwise. (this should probably be configurable, but I didn't make any real UI yet) Also please describe your use case, especially if it's not thrust under warp. But even if it is, in general I'm interested because so far I only made this mod for my specific situation, but I'd like to make it useful in more cases. P.S. Ah, the demonstration is a bit outdated then... I recorded it during testing, before I even discovered that thrust direction during warp is stored separately... P.P.S. Nevermind, thrust is on in the demonstration video. Even tho there are no engines, it should still work in the current (1.1) version of them mod. But I might fix that later, so it only activates when there is actual engine thrust.

Made a bug-fixing mod because couldn't wait for a proper implementation: That said, please don't consider it a solution. It's only good enough as a hotfix. And it doesn't exist for this particular bug-report, it's more of a general improvements for SAS and thrust during warp.