Stract

The departure time is the same. The predictions of MFMS are more or less close to MA but from time to time it is difficult to match the trajectories between them. For example, if MSFS requires 3500 m/s prograde burn, MA optimizer gives 3400 m/s prograde and 1300m/s radial for similar flight (departure and arrival times are the same). I've asked you after couple of fruitless hours I've spent trying to put this trajectory into MA .

Thanks! I see, it makes sense. Probably since SoI's in RSS are much larger than in stock KSP, the difference between MA and Flyby calculations is also larger.

Sorry, I think I have one more question (I already feel myself too annoying ). As far as I can tell, Mission Architect works great with RSS, but I have some doubts concerning other functions of TOT. Specifically, I have difficulty with implementing multi-flyby path into Mission Architect. Here is the image: I've input departure orbit, suggested by multi-flyby maneuver sequencer, into mission architect, but the orbit around Sun after transition is quite different in MA and in sequencer. I'm not sure it is a bug since the results of multi-flyby maneuver sequencer were always a bit different from MA but this difference is significant. Could you please check that all corrections you did in MA for RSS are implemented in multi-flyby maneuver sequencer too?

Hi Arrowstar! I have one thing: for some reason two last pre-releases (with RSS gravitational parameter) has some problem with departure-arrival porkchop plot (that one on the very first page of TOT). TOT creates the diagram but then stuck on the window "Searching for optimal departure/arrival" with error sound. It happens with both GM and G(M+m) factor and with both stock and RSS bodies.

Works for me so far . I'll let you know if I'll find another issues but for now it seems TOT finally learn how to deal with RSS. Thank you so much!

Yes, for the upward transition the result is the same. TOT with GM parameter gives much better results than with G(M+m) if I put Charon on the right place in bodies.ini in advance. Well, that is strange. As I understand, I've made basically the same thing by switching to GM in TOT for SOI change calculations and shifting the position of Charon in bodies file to make sure it is in right place at this moment. Did you try to reproduce it? Upd: ok, I have a guess why you didn't succeed. If you just calculate velocity of Charon with GM factor then you'll get a velocity in wrong location, because the true anomaly of Charon with this factor would be wrong. You have to calculate velocity with GM factor BUT for true anomaly corresponding to G(M+m). Here I have an example for upward transition (I've edited convertRVVectOnUpwardsSoITransition.m function). It worked for my Charon-Pluto transition.

No, the ephemeris data are correct (well, if I understand the term right ). I'm talking about the following thing: suppose we have vectors v1 for velocity of the spacecraft and v2 for the velocity of the moon both relative to the central body. Then v=v1-v2 is the velocity of the spacecraft relative to the moon. What I've noticed is that at the moment of SOI transition KSP use the value for v2 as it would be in stock game. Maybe KSP calculates it separately from RSS using just orbital parameters from database as it always do. That's only my assumption and I it would be great if someone can confirm it.

Well, it is a bug of Kopernicus, not just RSS. As I understand, Kopernicus creates new solar system with this modification of orbital periods, but doesn't change the way spacecrafts are propagating (maybe it is not easy to change, I don't know). And unfortunately the game itself calculates relative speeds during SOI transition using default bodies mean motion. We can try to talk to devs about this inconsistency but I'm not sure they'll consider it as a bug.

Ugh. Great, just great... I think I've found the answer after all. I have a crazy idea that RSS calculates orbital periods using G(M+m) BUT use GM for calculation of new spacecraft speed during SOI transition. Look: I've modified bodies.ini by put there Charon position at the moment just before transition (to make sure the Charon mean anomaly at this moment is correct) and run TOT with GM gravitational parameter. Well, look at the screenshot. RSS way of calculations is VERY counter-intuitive... This is my modified bodies file. You can check it with mission file I've uploaded before, just choose old GM settings. If I am right then things become more complicated: TOT has to track SOI transition using G(M+m) to find correct location of the body but re-calculate new rVectBody and vVectBody during transition with just GM.

Ok, that's the story. Look at two screenshots: The first was made in Pluto SOI one second before entering Charon sphere. All parameters in game and in TOT matches perfectly. Second one was made two seconds later, already in Charon SOI. The altitude of the probe in TOT is fine (well, more or less), but velocity is wrong. I assumed that since velocity relative to Pluto in TOT is correct but velocity relative to Charon at basically the same moment is wrong then probably TOT used incorrect Charon speed by switching into new reference frame. Well, just my guess Link to the mission file <<click>>

Ok, I think I have an update. It seems initial epoch in TOT for RSS is correct after all. Periods of the planets are correct too, I've re-checked it manually more carefully - the true anomalies of the moons in TOT are the same as in the game itself for every given time. But still TOT have small but stable error for transitions at little moons. Maybe it is just a numercal error though. Good thing is that this error is noticable for little moons only and that this error is not grow with in-game time. So here is an example (picture below). The probe is going to enter Charon SOI in hour and a half. Game shows that periapse altitude at Charon is 212 km, while TOT expects -40 km. Other orbital parameters are also not exaclty the same. So if the position of Charon is correct (and it seem to be so), then maybe something is wrong with the SOI radius? On my picture I marked SOI transition in TOT body information and radius of probe just after SOI transition (green boxes). It looks like for some reason TOT made transition into Charon SOI 2 km below it's own database. It matches with altitude of the probe just after transition and predicted altitude in TOT (red boxes). I doubt this 2 km difference could create this error anyway but anyway I've decided to let you know I can upload mission file if you wish but this result is easy to reproduce, I've had similar situation in every try. Update. Just noticed: difference in altitude at the moment of SOI transition is tiny but the difference in vertical velocity is significant, 116.7 m/s in game vs 125.7 m/s in TOT. Just checked - velocity relative to Pluto just before transition in TOT and in game were similar. But if the speeds of spacecraft relative to Pluto are similar then maybe the speed of Charon is wrong here? Maybe TOT still uses old orbital speed while recalculating velocity in new reference frame?

Hi Arrowstar, so far most of the things works great! I've noticed only one issue: there are some problems with fast-orbiting moons like Phobos, Deimos or Charon. Predictions for fly-by near them are not as good as for other planets or moons, sometimes TOT didn't see SOI transitions near them at all. Orbital periods for them are fine (or at least good enough), so maybe the problem is with initial mean anomaly or something. At least I've input manually current Charon mean anomaly and epoch into bodies.ini, skip 20 years and put a probe into fly-by trajectory near it. The predictions were fine, while automatically generated bodies.ini didn't give SOI transition at all. I'll look at it more carefully but anyway it is a minor issue. Overall TOT handles RSS really good now. Thank you for this great instrument!

Sure, I'll be happy to try.

Yes as far as I can tell. Kopernicus Orbit loader contains the following lines: body.orbit.period = 2 * Math.PI * Math.Sqrt(Math.Pow(body.orbit.semiMajorAxis, 2) / 6.67408e-11 * body.orbit.semiMajorAxis / (body.referenceBody.Mass + body.Mass)); body.orbit.meanMotion = 2 * Math.PI / body.orbit.period; So yes, it seems RSS use G(M+m) for all planets and moons motion. Strictly speaking this is also true even for spacecrafts motion since the mass of spacecraft is neglidgeble compared to mass of any RSS body, so for spacecraft G(M+m) and GM are practically the same.

Hi Arrowstar! Yup, all I did is add this smaller body GM. As far as I can see, the only problem in TOT with RSS is that TOT calculates the relative position of planets and moons incorrectly, so every SOI transition creates an error. In my example stock TOT determined the wrong location of Earth on Sun orbit (wrong true\mean anomaly to be precise, caused by wrong orbital speed of the Earth) at the moment of SOI transition, which ended up in wrong Sun orbital parameters of a probe. By adding Earth GM into the function I corrected orbital speed of the Earth and hence the true anomaly of the Earth at that moment. So yes, my assumption is that adding GM of smaller body at every time TOT tries to locate the current position of planet or moon (i.e. at every SOI transition, every fly-by trajectory calculation and so...) should do the trick. At least it worked in my example.