Youen

The prediction used to be less than 10km wrong (more around 5km) for simple crafts and "classical" reentries (like 1/4 orbit inside the atmosphere, starting from LKO), so I guess something changed in the game and the mod needs to be updated (again...) Unless you see this deviation using FAR ? In which case I don't know what would be the problem because FAR exposes a method that should remain accurate even when FAR internal model is modified.

Well, I'm going to assume the latest version works fine since no one complained. Now published on SpaceDock, and AVC updated as well.

@Rohaq Indeed, it seems you have blizzy's toolbar installed, which means Trajectories will be available only there, and not in the stock toolbar. If you don't use blizzy's, you could uninstall it, in which case Trajectories would go in the stock toolbar instead. I'd like to know if someone can confirm the package published on github works fine? So that I can also publish it on spacedock, and update the online AVC version (which will notify players using the previous version they can update, but I'd like to have it tested first).

Thanks @Kobymaru for these improvements I've published a new package that contains the DLL you built (I don't have the latest version of the game installed here so I didn't recompile) on github. Since I didn't reinstall the game, I also didn't test anything. So let me know if everything works fine with the package I uploaded, and then I'll update on SpaceDock so that players with managed mods (CKAN and AVC) will get the updated version as well.

@Dizor that's an unexpected issue ^^ But sorry, right now I have no clue what could cause this, and also not enough free time to reinstall the game and debug the issue. I'll let you know if I find more time later.

@monstah Trajectories is supposed to detect if blizzy toolbar is not installed, and it won't try to use it if it's not there (but maybe there is a bug, though I always played the game without blizzy's toolbar and had no issue). Also, several players thought the UI was not working, but in fact they just needed to go in map view (the only place where the UI is available), so I'm telling you just in case (and I'll also add that in the FAQ).

Indeed, should work fine, but let me know if it doesn't.

Thanks. I'll let you know if I find something (don't expect anything soon, I'm a bit busy at this time). Also, I didn't know KSP 1.2.1 was out. I only tested with KSP 1.2.0 so far (but I can't say if it's related to your bug).

Hmm, this bug seems weird, Trajectories is only managed code, so it should not cause this kind of crash (usually, the worst managed code can do is throw an exception, which is caught by Unity and logged ; no crash). So, I'm not saying it's not possible that Trajectories has a side effect that contributes to the crash, but I've no clue what could be happening. Also, so far, you seem to be the only one observing this behaviour. If I find some time, I'll try to reproduce your issue ; in the meantime, could you post your save game to help with that? Are you playing on Windows?

For anyone interested in removing the nyan cat earlier (it would go away by itself in a week), you can download a custom version of ModuleManager here: https://github.com/neuoy/ModuleManager/releases/tag/v2.7.1 This is exactly the same MM code, excepted the nyan cat doesn't enable itself whatever date of the year it currently is. You can still enable it with the -nyan-nyan parameter (but then you don't need this custom version to do that). If you want to get rid of the nyan cat whatever mods you have installed, just make sure this is the only ModuleManager.dll file you have in GameData and subfolders. Also be sure no other mod needs a more recent version (it's the latest at the time I'm writing these lines). I also hope I didn't break anything by recompiling it, let me know if you have an issue.

I repackaged the very same version (1.6.5) with a custom ModuleManager dll that disables the Nyan Cat. You can download this modified version on github (Trajectories-v1.6.5a.zip). For anyone interested, you can also download ModuleManager.dll here: https://github.com/neuoy/ModuleManager/releases/tag/v2.7.1 This is exactly the same MM code, excepted the nyan cat doesn't enable itself whatever date of the year it currently is. You can still enable it with the -nyan-nyan parameter. If you want to get rid of the nyan cat whatever mods you have installed, just make sure this is the only ModuleManager.dll file you have in GameData. Also be sure no other mod needs a more recent version (it's the latest at the time I'm writing these lines). I also hope I didn't break anything by recompiling it, let me know if you have an issue.

Version 1.6.5 released on github and spacedock: - fixed stock toolbar button that wasn't removed when exiting flight view - removed debug module (that was spamming the loading log in release builds) - fixed .version file for KSP-AVC

I don't know if you were serious with this statement, but just in case, if you were, I strongly disagree. Module Manager is not just "a mod", it is a mod most other mods depend on. So basically, if you don't like the cat, you have to remove ALL mods from your game (I'd be interested if someone has statistics on how many mods rely on MM). I don't think it's a fair move from Sarbian to impose this to players AND modders (and for what reason?). Don't take me wrong, it's not an important matter (it only impacts the loading screen), but on the principle, it's a bit of a treason, to let modders become confident with Module Manager doing what it's supposed to (and nothing more), and all of a sudden add this quite out-of-place "feature". Also, I'm wondering why it's in MM, and not in MechJeb instead, for example? Feels a bit like a virus in it's current form. I was considering to remove the dependency on MM from my mod, and then I found out (by reading this thread) that it was going away in a few days, to only come back one day a year. This makes it less annoying, for sure, but yet, I'm hesitating (this is not a threat, I know very well that Sarbian doesn't care if I use his library or not, just thinking aloud).

Thanks for the bug reports, I'll take a look at the version file and the button bugs soonTM

Thanks @Kobymaru for this recompile and tests. Since it seems I don't need to update any code, I should be able to publish the recompiled version on github and spacedock tonight. And maybe integrate the latest modifications on the API (for kOS). EDIT: released on github and SpaceDock

I don't get it, Module Manager is included in the zip file, what went wrong?

@dlrk No idea... I think you can ask @Caleb9000 who implemented this API.

I've just released a new version (you can download it on github or spacedock). Here are the changes in this version : - Added prediction of SoI changes after aerobrake (also fixes a bug when aerobraking from an escape trajectory) - Fixed bug with wings that were incorrectly predicted with stock aerodynamic model - Improved ground impact detection (better collision check against relief) - Improved impact indicator in map view (not hidden underground anymore) - Added API for kOS (thanks to CalebJ2) - Automatic configuration reset if the configuration file is invalid or empty - Improved icon rendering for Blizzy's toolbar Enjoy!

I found the culprit : vessel.GetWorldPos3D does NOT return the world position (i.e. relative to the sun). It does so only when above 100km. When under 100km, it seems to add a rotation-frame position with the body position (which doesn't make any sense AFAICT). Also, I found how to know wether the game is in this "rotating frame reference" state or not: one can test the boolean "inverseRotation" of the current body, which is set to true only when the altitude of the current vessel is below mainBody.inverseRotThresholdAltitude When in this mode, another side effect is that the body transform is frozen (so the body doesn't rotate anymore). Instead, the universe rotates around the body in opposite direction? The whole thing seems to be another hack similar to the Krakensbane to avoid glitches near a body surface (I guess). EDIT: actually, vessel.GetWorldPos3D makes sense, as the position is valid relatively to all other objects (I hope). But since the universe is rotating around the body, it can't be used to derive a velocity (you end up with either a rotating-frame velocity, or an absolute velocity, depending on body.inverseRotation value).

Dammit, I'll never get it right... Things do not match yet. If I display the vessel velocity, computed from its position in inertial frame, it doesn't match when I'm below 100km. It should be around 2250m/s (circular orbit at 100km), but I get 2040m/s (the difference matches the rotating frame velocity, 210m/s at 100km). To compute my "true orbital velocity", I use positions and universal time. To compute the positions, I use GetWorldPos3D() - body.position. I don't see how this could be more independent from Kerbin rotation. So I'm back to what I said in the OP: apparently, the vessel doesn't move at the right velocity when under 100km. While KSP tells me the ship has an orbital speed of 2250m/s (which should be the right value), the vessel is actually moving at 2040m/s.

Actually, @wasml is right ; the reference frame changes when going below 100km. Everything in vessel.orbit is in inertial frame when above 100km, but in rotating frame when below. It seems vessel.obt_velocity follows the same rules. My positions were always in the inertial frame (as said in OP, I use GetWorldPos3D() - body.position), which explains why it didn't match below 100km. I probably made much more knots in my head than needed be, some of the things I said above are probably wrong. I wish this was documented in the first place! For those who want to work with the Orbit objects, you must also take care to swap Y/Z components, but not for all methods (for example, it's already done for vessel.obt_velocity and Orbit.GetRelativeVel ; but you must do it for Orbit.getOrbitalVelocityAtUT). Thanks everyone for the help sorting it out. Hmm... and if someone knows how to check what reference frame is used without resorting to hacks such as testing vessel altitude (don't know if the 100km threshold applies to others bodies) that would help too.

The vessel velocity (as reported by obt_velocity) is coherent at all altitudes, and matches the expected orbital velocity. For example it's the same as vessel.orbit.getOrbitalVelocityAtUT(Planetarium.GetUniversalTime()). vessel.orbit is also coherent and gives the correct orbit corresponding to Kerbin gravity. So there is nothing wrong with any velocity I can read from KSP API. The vessel position however does not match what it should. It follows the correct orbit, but slower than it should. vessel.orbit changes accordingly (same orbit, by time shifts to match the vessel moving too slowly along it). I haven't checked yet, but I think it will take more time than it should to make a complete orbit. I also haven't checked if other vessels are also moving slower than they should, or if it's only the player vessel. I will also check if I can observe the same behavior on another computer...

Hi, I have observed something strange when orbiting around Kerbin at an altitude lower than 100km: the vessel is moving slower than its velocity. Here are the values I used: - velocity is retrieved with vessel.obt_velocity - position relative to kerbin is retrieved with vessel.GetWorldPos3D() - kerbin.position - time is retrieved with Planetarium.GetUniversalTime() - velocity from actual vessel movement is computed with (position1 - position0) / timeDelta What I observe is that velocities are exactly the same for any altitude above 100km, but vessel movement is slower (by a factor of about 0.9) when under 100km. Anyone has an explanation?

Indeed, thanks, didn't see that one. I'll give it a try to see how it compares. KSPChiller is more a prototype than a mod at this stage anyway

Good point, I've not tested that yet. I'll let you know. Also, it still requires insulated tanks, I don't think the stock game has any. OK, that would be great Feel free to take what you want, when you want (the license allows it anyway).