Write a separate standalone application for generating boot scripts.

[ElWanderer]

Currently boot scripts have to be manually edited to set the desired parameters.

Issue #78 exists for providing a GUI on launch that allows a user to enter parameters. This idea is similar, but different - a standalone application (e.g. written in Java) that allows a boot script to be generated based on various inputs.

Being standalone, this could read in the game's savefile to pull out the parameters of certain contracts and offer them in a dropdown. It could also be used to enter craft/mission-specific details that otherwise would have to be hand-edited into a craft-specific file with the right name.

[ElWanderer]

Validating the solar system map generation against the game for Y1 D1:

[ElWanderer]

As part of calculating the position on an inclined orbit: latitude = arcsin(sin(inclination) sin(true anomaly + argument of periapsis)) The radius as seen from directly above (i.e. within the ecliptic plane) would then be given by actual radius for that true anomaly cos(latitude)

There may be a shortcut for that - having implemented it, it seems to have come out with similar planet-placing to the version I'd come up with myself.

[ElWanderer]

Another work-in-progress screenshot: The white flecks below some of the orbit lines are where the orbit ellipse would be if the inclination were 0. I don't think the scaling I'm doing accurately shows inclined orbits, though. It is good enough for now, I guess.

[ElWanderer]

I have put together the very first stage of a Lambert solver for determining interplanetary transfers. It is currently hard-coded to produce a specific transfer orbit's semimajor axis, eccentricity (and hence orbital period, with the central body taken into account), true anomalies and flight time. These can then be compared to the example on the Wikipedia page(!)

Things to do with that:

• Put a solver around that. Currently one of the inputs if effectively random and we need to try different values until we get a flight time that matches the transfer time we want for the target body to be there when we arrive.
• Wrap that solver in something that will query a combination of departure and arrival times, so as to allow a pork chop plot (and the "best" transfer)
• Enhance the calculation to determine all the elements of the transfer, and therefore the size of the ejection burn from a stable orbit. Also the arrival burn if intending to go into a stable orbit. Without those, we can't calculate the delta-v requirement for each transfer. Also we want to know what information to try to feed back into kOS.
• Wrap the thing in a GUI

[ElWanderer]

Or I could look to existing implementations such as this one in C#: https://github.com/TriggerAu/TransferWindowPlanner/blob/master/TransferWindowPlanner/SharedStuff/LambertSolver.cs

[ElWanderer]

This may no longer be necessary if we can use the kOS-Career plugin I've seen, if that can pull details out of contracts.