Krafpy

Sorry everyone for the terrible delay in my response ! It would be possible. At least, I don't see anything that could prevent me from implementing it in the current software. There is no way for now. I am well aware this should be a feature... I just didn't design the software initially to support that... but it is something I can try to add. I don't think it would actually be that hard for me to implement it, since the excel file contains all the required data to retrieve the full trajectory. For now, it is not possible, and I currently have no idea how to implement that. It doesn't mean that it won't be implemented in the future though. I'm currently pretty busy with my studies. I hope to get some time soon to finish things I promised almost a year ago now... (didn't forget about you @akyyy !) Once again, I apologize for the delay! I began experimenting a bit with a mod version of the software (for KSP1) last year. I put it on hold it during the summer as I failed to fix an issue with orbit calculation (if anyone has some knowledge in mod development and is interested, dm me!). But I believe most of the requested features regarding custom solar systems and game configurations (e.g. system scale) would be implemented much more easily and reliably with a mod version, so I'll probably postpone them for the mod. Though, I'll still try to work on the current web tool if the features don't require too much refactoring of the code base; I'll keep your requests in mind! I'll try to respond to this thread much more often.

@akyyy The video is recorded, currently editing it.

@Eddy119 I am not aware if such list exists. Maybe try creating it with KSPTOT ? It might be better at finding launch windows (if you are just looking for that). The best I got with my tool is 1500m/s for KEKKJ (without insertion burn).

Hi @akyyy sorry to hear that Do you mean that if you follow step by step what is indicated by the tool you don't get immediatly the intersections/flybys ? If it's that then it's completely normal. The results (times, maneuvers...) are internally computed with some assumptions and simplifications. It is very unlikely that following the details of the trajectory will give you the exact same one in game. You need to fine tune manually the maneuvers in order to enforce flybys to happen more or less how the tool displays them. I tested with a Ke-Ev-Mo trajectory and when I entered the Ke-Ev maneuver as indicated it didn't even give me an intersections with Eve although the tool computed that it would. However, after I modified a bit the maneuver by hand (about 50~ m/s dV change and moved it later/earlier) I got the intersection. Remember that the tool gives more or less precise idea of what the trajectory would be and what maneuvers to do. I promise I'll do that video tutorial ! sorry for the wait

Hello @Dartio! My tool doesn't support KSRSS for now, you can check @theAstrogoth's tool which has a KSRSS option : https://kerbal-transfer-illustrator.netlify.app/Flyby but it seems to be scale 1/10 Do you have by any chance a link to the Kopernicus config files of the 1/9 scale version ?

Hi ! Thank you for all the information and work you did ! Yes my tool always suppose an equatorial departure orbit, which is pretty bad in terms of dV. I will see if I can make it consider the inclination, or maybe even add the inclination as a part of the optimization process. I want to point out that I have (almost) no control over what trajectory is produced by my tool. It tries to find a trajectory that minimizes the total dV with what is basically a "smart evolutionary trial and error" algorithm generalized for any planet sequence. So it has no idea that good human-found strategies for specific trajectories exist, and can fall in a local minimum.

Hello and thank you for your message @Utkucan ! If you want to have some details on what the tool does internally you can see one of my previous posts : Note that this post describes how the tool worked when I released it. It has some mistakes and the current version has some differences. But this should give you a rough idea at least about "how it calculates an optimal trajectory" (keep in mind also that there is no guarantee that the result is the optimal trajectory). If you want the exact details on how it works now or have specific questions, don't hesitate to ask or even direct message me. I'm not sure if you are talking about the parameters you can change in the user interface (e.g. departure planet, departure date... etc.) or internal parameters in the optimization algorithm. For your second question : I'm not sure about what you mean by "interpret and export them to the game". The tool gives the information of each maneuvers you have to perform and when. You basically have to try to reproduce them in game. However, due to precision and simplification issues, following the steps in game exactly is unlikely to give you the exact same trajectory that the tool shows you. So manual fine tuning is required. This is something someone else already asked in a comment a few weeks ago ( @akyyy). I'm a bit busy and, mainly, don't have a PC that can run KSP decently right now. I'll try to make one as soon as I get the time for it. I hope this helps ! Don't hesitate if you have further questions.

Unless you find a perfect configuration of Kerbin and Eve, it's pretty hard to find a good trajectory that doesn't requires Jool to get in a good position first. I tried with a departure at the beginning of year 6 (Kerbin/Jool opposition) and forced the departure date to be not later than year 10. I get a deltaV of about 2500m/s (without circularization around Jool) with a departure between year 7 and 9. I get about 3000m/s deltaV with a simpler Ke-Ev-Mo trajectory. I think this kind of maneuver is not very well handled by my tool, so it's not very surprising that a good KEKKJ trajectory is hard to find.

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.

Thank you for the information ! After playing around a bit I eventually noticed that the scaledSpace coordinates indeed change every frame and depend on camera position. So if I need to compute the positions of several bodies for physics purpose (i.e. with origin centered at the Sun or at the planet for moons), ignoring floating point precision issues for now, is it feasible with getPositionFromTrueAnomaly or a similar functions ? Or do I need to reimplement the maths myself ? If the origin can be anywhere, how does KSP compute the bodies' positions since the maths involve positions vectors with defined origins ? Sorry if I'm not clear.

@nubeees I'm not sure if I understood correctly but I guess what you mean is that the lines appear first where you placed them (in the map view), but then seem to drift away from the planet. Am I right ? If that's the case, I think I encountered the same problem. I solved it by constantly updating (recalculating) the positions of the lines' points at each frame in Update or LateUpdate. And I don't think you even need to attach the line object to any other object if you do that, except the scaledScene.