Krafpy

I'm excited about absolutely everything. What I love is the sense of exploration and discovery, and I believe that KSP2 with its new graphics, planet details and colony system will bring the exploration experience to a whole new level !

@ducceeh I still can't see the picture, the link isn't working. OPM is an extension to the Stock system, so the settings for the stock planets should remain the same. In the Kopernicus files of OPM ( see here: https://github.com/Poodmund/Outer-Planets-Mod/tree/master/GameData/OPM/KopernicusConfigs ) I can't find any file that would modify stock bodies' data. If you compare the positions of the stock planets between the stock setting and the OPM setting on my tool they are the same at any date. I also checked @theAstrogoth's tool which supports OPM as well ( https://kerbal-transfer-illustrator.netlify.app/ ) and the position of the stock bodies at Y1 D241 seem to be the same as in my tool and as in your first screenshot. Do you use a custom mod by any chance ? or a combination of mods ?

@ducceeh I don't see the in game picture, so I can't really evaluate how large the difference is. One possible reason is that there is an issue in OPM's configuration file, which should have been generated from OPM's Kopernicus files. I'll check that. Can you give the date to which these screenshots correspond to and which planets seem to have the largest difference ? Thanks !

Ah ! Sorry it was a misunderstanding then. My bad ! I would be interested in knowing what's your approach to compute powered swing bys.

@ArrowstarI remember on the screenshots you sent a while ago I only saw Lambert arcs connecting the different encountered bodies, considering flybys as instantaneous events (calculating powered swingbys analytically if I remember correctly), that's what I meant by "doesn't compute the details of in-SOI parts to be displayed". Did you add SOI intersection points and in-SOI trajectories when you display the whole trajectory ? Sorry if my phrasing is bad...

Custom sequence: Ke-Ev-Ke-Ke-Jo Earliest departure: Year 10 Latest departure: Year 20 Departure and destination altitudes: 100km No insertion burn I don't think this input is really useful. You probably just need to run the search several times. It gave me 1350m/s on the third run. A 10 years departure window seems small enough, but I would recommend reducing it down around the dates it gives on the first runs. Keep in mind that you will still have to fine tune the maneuvers in game. The ones the tool give aren't prefectly accurate. Well no tool is perfect. We both use some approximations and use the same evolutionary algorithm (only the settings are different I think).

Yeah it is totally possible to find a better trajectory manually. I just ran my tool again for KEKKJ and I got a 1350m/s delta V this time. Not as good as the 1100m/s of the video, but better than my previous try. From what I know, KSPTOT uses a similar search algorithm (a type of evolutionary algorithm), but I think it doesn't compute the details of in-SOI parts to be displayed, so it has less work to do and has probably more chances of finding good trajectories. You can also try theAstrogoth's tool : https://kerbal-transfer-illustrator.netlify.app/ It has a flyby calculator similar to mine, but uses a different approach at calculating the trajectories. Maybe it could give better results.

@Eddy119It is totally possible that a better trajectory with less delta V exist. My tool does not guarantee to find the optimal trajectory. It tries to... but is likely to miss it if it's a complicated trajectory. There is some randomness involved in the search process. If you enter a smaller departure date range, it should have more chances to find the optimal one.

Hi ! What do you mean exactly by "doesn't work too well" ? @Eddy119 Is it failing at computing a trajectory ? Or is the trajectory incorrect ? delta-V too high ? I just tried a Ke-Ev-Ke-Ke-Jo with departure between year 1 and year 20. I get a trajectory with an estimated delta-V of 1750m/s (without circularization burn around Jool).

Hello ! New small update ! In response to @Dealthough's comment, I added the following: - The arrival date is now clearly shown along with the departure date of a trajectory. - The ejection angle is displayed in the details of the first maneuver. It corresponds to the angle between the direction of the departure body's velocity (tangent to the orbit at the departure date, pointing in the body's moving direction), and the position of the ejection maneuver on the parking orbit around the derpature body. The angle is oriented counter clockwise (trigonometric direction). I hope this is useful.

Hi @Dealthough ! Indeed there is no ejection angle information for the departure, I haven't implemented it. The arrival date is indeed the cirularization date (or the date at which the spaceship enters the arrival body's SOI if "no insertion burn" is checked). I agree these could be useful information that I should have thought of ^^'... especially the ejection angle. I'll work on that as soon as I can ! For the time being you can try to guess the ejection angle by zooming on the departure planet and looking at where the ejection maneuver node is placed. One note just to be sure it's clear: the departure date shown represents the date at which the ejection burn from the origin's body is made. The mission elapsed time that is displayed is computed from that ejection burn. Therefore if you try to do a mission from the launch the MET in game and in the tool won't match. It's not a big problem as long as you plan the duration of the ascent and do the ejection burn roughly at the correct date... The maneuevers always require a manual tuning anyway. Don't hesitate to ask if you have any other question or issue !

Alright thank you very much for the clarification ! I know that a true anomly offset isn't directly linked to time. But if you look at the values, what looked like nonsense to me was these lines : Local Pos 1: [493910.75, 1014.90991210938, -340737.9375] Local Pos 2: [12113141.2240677, 1014.90991210938, 6726731.39502716] `Local Pos 2` is the position after adding +0.001 to the true anomaly of `Local Pos 1`. The sign of the z coordinate is changed, meaning that the object would have traveled to the opposite side of the xy plane by such a small change in angle... But now that you precised that the origin in local space can be anywhere, I guess they make more sense, the origin for these coordinates can be very close to the camera for example, thus the change of sign in the z coordinate. Even though the origin can be anywhere and can change, the scale should stay consistent. So just to verify that, the distance between `Local Pos 1` and `Local Pos 2` is 13599 km (if the units used are indeed meters). Knowing the velocity of Kerbin, in 1400s Kerbin would travel about 13000 km. So the coordinates make sense indeed, and confirms the units are meters. I hope I didn't mess up again in undertsanding what you write...

That's exactly what I meant, with the example of a planet orbiting the sun. Sorry if my phrasing was poor. So indeed for a planet, their coordinates would be calculated and expressed relatively to the sun (sun as origin), and for a satellite relatively to the planet its orbiting around. So the "AtUT" methods actually return the correct coordinates relative to the attractor body ? and not relative to some floating unkwon origin in space (that's what I understood from your earlier answer) ?

Alright, I guess it will be simpler to reimplement the functions I need. For placing and rendering objects I agree. But KSP needs at some point to compute, for example, the position of a planet at a given date, and for that, to my knowledge, it needs to do some maths involving quantities and vectors (computing mean anomaly then true anomaly, and then rotating some vector) that are defined in a coordinate system where the origin is the Sun. Or am I missing something ?

Hello ! New update ! There is now a "No insertion burn" checkbox for the trajectory settings. If checked, the final orbit around the destination body will be a flyby with the specified altitude at periapsis. Atmospheres' are now taken in account in flyby calculations (yes, this was not the case until now...). Flybys can't have a periapsis that goes below the atmosphere limit anymore. But more importantly, in order to help adding new solar systems to the tool, you can now directly convert Kopernicus .cfg files to a `bodies.yml` file on this page : https://krafpy.github.io/KSP-MGA-Planner/tools/cfg-to-yml/ Simply select all configuration files of all bodies (body files only) and convert. If a solar system is an extension to the stock one, you can check the "Combine with stock" checkbox to automatically add the stock bodies if no .cfg file is overriding them. This should make the use of custom solar systems much easier and straightforward. Instructions are detailed in the original post as well as in the github repo's readme. Using this feature, I completely replaced the data files for JNSQ which contained some errors.