VikingStormtrooper

No, I did not upload my engineering stuff on Github (but there are still my mods! ); in any case, if you think this could be useful I will take this idea into account! That paper is nice, and features the basic notions as well! Very good reference. Your strategy makes sense, especially if you are interested only in the basic Lambert transfers; however, if one day you feel bored, keep in mind that adding a single gravity assist is not terribly complex (although pretty time consuming, if you do not set up the algorithm efficiently). Well, the most interesting thing to get from your computations is the minimum delta V, and the corresponding maneuver; this is just one point on a 3D plot. However, porkchops can also indicate points that are not minima in the strict sense, but still acceptable in terms of delta V or time-of-flight: this allows you to choose launch windows rather than discrete times. It's a lot of flexibility, isn't it? Ok then! Ephemerides are the "refined" way to deal with the problem of orbits and times. They are basically a collection of orbital parameters which allows people to know where the celestial body X is at time Y; JPL created the Horizon tool, a huge database of these parameters computed via accurate n-body simulations for a huge number of bodies. As you may imagine, it is extremely valuable for astronomers and space engineers; keep in mind also that, differently than KSP, real life is not based on patched conics, and the ephemerides allow you to track how the orbital parameters of a given body (the Earth, Titan, Mercury, etc.) change in time, depending of the overall gamma of perturbances they may experience. However, if you deal with KSP stock planets, AFAIK there are no ephemerides in-game, since KSP uses a relative time mode ("count time from the moment in which you start the match") instead of an absolute one ("minute-hour-day-month-year etc.). This means that you plan transfers basing on the current phase angle between your bodies, and then you keep the orbits of your bodies fixed in time up to moment in which you forecast a phase angle which grants a low delta V. You know how much time you have to wait, but not the day you start and the day you finish. The basic mechanism is similar, but I am personally less familiar with this one, and I prefer dealing with ephemerides.

Just to understand, do you see the PartTools folder in your Assets (under Unity/YourProject)? It happened to me once that I started a new project, did everything but still not see any PartTools object in my project. I had to manually copy the PartTools folder from another project, and the issue disappeared.

I wrote a short sci-fi story at the high school, maybe I will translate it to English

Sure, you can refine the optimization algorithm as much as you like! I cited the manual process I worked on, but I am sure that it would be easy to make it automatic (probably better for your needs!). Just take into account the orbital periods of your bodies, and fix some kind of tolerance. It's ok if you want to use C or Python; I don't know Python, but I am pretty sure that a C solver is more computationally efficient than a Matlab one (there was a paper about this, don't remember what). If you like, I can still give you my Matlab functions for reference; I did not write the Lambert solver personally, but I made the other functions. The optimization algorithm that I used was quite slow, but it worked flawlessly (I had also a gravity assist along the way, meaning two Lambert arcs and two nested for cycles, a nightmare for my CPU!). All that said, I'm waiting for your solver! ...and don't forget to make the porkchop plots for reference, they are extremely valuable tools. Oh, ask me if you do not know how to deal with the ephemerides from JPL Horizon (it's not always easy to set the options or understand the outputs!)

The idea is that you look at the orbital periods of your bodies, and then you select the most reasonable time discretization. Example: you are considering the Jupiter moon system, and you want to move from one of the four moons discovered by Galileo to another one (e.g. from Europa to Io); since these moons experience orbital resonance, it makes sense to consider the time interval between a certain angular configuration and the next time you have (almost) the same configuration. Then you can choose if you want to consider the intermediate positions every day, every six hours, etc. If you do not have resonances, you can still select significant time intervals in order to have a good statistics of the possible intermediate phase angles, in such a way that your optimization covers a large variety of cases. Take the Earth-Mars transfer: launch windows occur approximately every two years, because every two years the Earth and Mars are approximately in the same relative configuration. It makes sense to subdivide this two years interval into months. If you want to be more precise, you select weeks, then days, and so on. Look for the best compromise between accuracy and computational load: you don't want the optimization to be too shallow but, at the same time, you don't want your pc to take fire after two months of wild computations just to understand that launching your spacecraft one second later grants a gain of 20 cm/s of delta V.

Dear @Jovus, I did something similar in the past on Matlab for a university project. The idea is that you can use the ephemerides (there is a Matlab extension incorporating them, or you could visit ssd.jpl.nasa.gov/horizons.cgi ) in order to know where every planet/moon is, in terms of orbital parameters, whenever you like. Then you select specific moments to compute the current position of your bodies, apply a Lambert problem each time, and finally build a vector of delta Vs. By selecting the lowest value in the vector, you have the cheapest transfer. This is rather simple if you have just one Lambert arc between two bodies rotating around the same attractors; it becomes extremely complex (and a computational nightmare) if you consider also multiple gravity assists, since you have to rely on genetic algorithms and other horrible things (we had to reach Saturn with an incredibly low delta V and GAs were the only way!), but I assume you are not interested in this. If I remember all of them, you have to worry about: - Choosing discrete times to check for the current position of your bodies and building a huge table of orbital parameters at any time; - The implementation of the Lambert problem (the hardest part); - Managing orbital parameters -> position/velocity vectors conversion, and vice versa (every book of Orbital mechanics tells you); - Managing the time law, required to relate the length and shape of your Lambert arc to the time needed to cover it (again, books are gold). If you are stuck at some point, feel free to ask. Good luck!

A medieval Ptolemaic geocentric mod using physics by Aristotle could be interesting only to show how strongly the civilization evolved in the last centuries. At least a part of the humanity.

Looks interesting. Do you know the possible efficiency and the output power of those cells?

Both @Phineas Freak and @Starwaster are right. The specific impulse is defined as the ratio between thrust and mass flow rate of propellant needed to grant that thrust (and the acceleration of gravity ASL if you like, but this is not important now); for this reason, it is right that Isp measures the thrust per unit mass in a given time, or thrust/the time derivative of mass in infinitesimal terms. At the same time, there are no possibilities to have both high specific impulses and high thrusts with the usual thrusters. Chemical rockets can be used as launchers because of their very high TWR, but their Isp is considerably lower than that of electrical thrusters (like 460 s against 1000 s); on the other hand, electrical thrusters have very low TWR and can be useful only in space, during very long burns. Due to the highest specific content of energy in fuel, what is closer to "high-thrust, high-Isp" is the nuclear propulsion, nothing you can see in practice.

Current state of RealisticComponents Suite (02-14-2017): RTGs (v. 0.7.0) now includes all of the intended radioisotope thermoelectric generators - in a strict sense. There are still two space nuclear reactors to implement (SNAP-10A and BES-5), plus config files for Realism Overhaul and improved .dds textures for all of the RTGs to do; ChemEngines (v. 0.1.0) is still in its early phases. This mod will take more time than the others; Antennas (v. 1.0.0) now includes three antennas: one high gain antenna and two low gain antennas. Possible improvements include config files for Realism Overhaul and improved .dds textures. I will create the release thread once ChemEngines is a bit more mature. In the meantime, you are free to download RTGs and/or Antennas! If you have suggestions or requests, I will do my best in order to satisfy those wishes.

This indicates that there are still some issues, or the compatibility with KSP 1.2.2 has not yet been established. In any case, I can tell you that ProceduralFairings works in 1.2.2 (I just checked yesterday)! Instead, I have experienced serious issues with RemoteTech: as long as I had it in my RO mods collection, the game did not recognize antennas on my vehicle. I was able to place them correctly, everything seemed fine, but then I could not have probe control even at launch - exactly what happens if you have no antennas on board. After removing RemoteTech, the issue disappeared.

1) Exactly! 2) I think so, they should be currently working on it. 3) If you now download the pre-release zip file of RO 1.2 from Github, you will not find the full collection of mods. You will have to download all of them manually. 4) I'm sure the new RO will be hosted on CKAN, but this may take some time.

If you have just updated to 1.2.2 and still want to play RO, you can try the pre-release. There are some issues, but a lot of mods such as RSS work well. Otherwise, if you want everything as you were accustomed to in the past, I suggest reinstalling KSP 1.1.3 and using the old RO.

If you have KSP 1.2.2 (the last version), RSS should work - just check if you have the last version. Regarding RO, there is currently only a pre-release for 1.2.2. There are still some issues; if you want to have the old RO and the old RSS, you have to reinstall KSP 1.1.3.

This is extremely useful if, as a modder, you want to understand the structure of config files of similar parts: just take the stock ones, copy them, and edit them!