Trajectorize is far enough along now that someone might actually want to use this thing for transfer window planning. Add a short docs site somewhere, showing off how to use the single_transfer module.

Introduction

This comes as a result of #2 ; the current Lambert solver is basically a carbon copy of what's used in Curtis, but there are most certainly better options out there.

The two main goals for the solver moving forwards are the following:

1. Make the solver more robust, so as to get rid of the "banding" seen in the porkchop plots
2. Make the solver faster

Possibilities

Modifying "in-place"

The existing solver may be modifiable without many major changes to fulfill both performance goals

Pivoting to a new solver

There are a bunch of different implementations out there described in papers, which may be worth looking into both for better robustness as well as speed.

Introduction

This issue comes as as result of an outstanding request from #5, creating a framework for representing mission plans.

The goal is to produce a system and representation that allows describing a multi-part mission between celestial bodies in KSP, including starting/ending/phasing orbits.

Sequence representation is done in the context of gravity assist trajectories.

Requirements

• Produce a system which can represent a sequence of destination celestial bodies
• Provision for intermediate phasing/resonant orbits
• Starting and ending points will be circular orbits of arbitrary orientation around a celestial body

(TODO)

requirements-testing.txt should be eliminated in favour of adding optional dependencies in pyproject.toml.