CustomAsteroidPlanes does not transform consistently

[Starstrider42]

Background Info

• Operating System: Windows 10 64-bit
• KSP Version: KSP 1.1.0 32-bit
• Custom Asteroids Version: 1.3.0
• Other mods: RealSolarSystem 11.0.0 (and bundled Kopernicus/ModuleManager), RSSTextures 10.4 2048.

  Issue Description

I've found a weird bug that slipped through my testing of inclined asteroid groups. All behaviour in this post was tested by replacing the Custom Asteroids config that ships with RSS with this file.

If I load KSP and start a new game, asteroids will be aligned with the orbital planes of the RSS. Edge-on view: Oblique view:

However, if I either:

• quit to the main menu, and start a new game
• quit KSP, then restart KSP and try to load the old game

then newly spawned asteroids will no longer have the correct orbital orientation, so long as I spawned at least one asteroid. Sometimes the effect is a few degrees, sometimes it's dozens. Oblique view of a bad case:

Within a KSP session and for a single save game, the orbital orientation does not change. I've yet to find a way of predicting the size of the offset; I used to think it increased with the number of asteroids spawned previously, but that's not the case. The rotation does not appear to be around a special axis.

Technical Details

The orbit rotations done by CustomAsteroidPlanes are implemented by finding the asteroid's untransformed state vectors (using Orbit.getRelativePositionAtUT(ut) and Orbit.getOrbitalVelocityAtUT(ut)), left-multiplying them by a Quaternion, and calling Orbit.UpdateFromStateVectors with the altered vectors. I've added some debugging logs, and the transformer swears it's always doing the same transformation, regardless of what the map view looks like:

Calibration: [0, 0, 1] -> [0.026371156796813, -0.390285193920136, 0.920316278934479] Calibration: [1, 0, 0] -> [0.999589502811432, -1.84732489287853E-05, -0.0286505203694105] Calibration: [0, 1, 0] -> [0.0111988745629787, 0.92069399356842, 0.390124499797821]

[Starstrider42]

Just confirmed that this bug can be reproduced without either Kopernicus or RealSolarSystem: