Devlog 4: Kerbal Gravity Program

KGRP is a mission planning tool I’m building for KSP players and actual aerospace engineers to map out complex trajectories. It’s loosely based on libraries like Skyfield, Poliastro, and Trajectorize. The ultimate goal is to make it easy to plot out massive interplanetary trips, whether you’re trying to reach Jool and Sarnus (with the Outer Planets Mod) or calculating a real-world journey out to Neptune.

What Happened Today

We need to talk about a major turning point for this project. Today was the day I finally broke.

I sat down ready to write some beautiful orbital physics code, but instead, I spent hours staring at a screen full of red squiggly lines. I was trapped in a seemingly endless loop of configuring MinGW paths, updating JSON files, wrestling with Conan, and trying to force VS Code to recognize where the Eigen math library was hiding. I realized I was spending 90% of my energy fighting a stubborn C++ compiler and only 10% actually thinking about gravity and orbital transfers.

As a solo developer trying to build something massive, that is a recipe for burning out. I was totally fed up.

So, I had a choice: keep sinking precious hours into configuration hell, or do something radical to save my velocity. I chose velocity. I opened up my file explorer, went to the project root, and completely ripped out the entire cpp folder. Shift + Delete. Gone.

(To any C++ purists reading this: I am deeply sorry, but it had to be done.)

By committing to a pure Python architecture, I can keep the code lean, fast, and remarkably lightweight (for an interpreted language):

• NumPy: We are using the best library for 3D math operations.
• SciPy: Gives me instant access to rock-solid root-finding algorithms. This means my Lambert solver is going to be incredibly robust and fast. Using this, We can get C++ execution speeds with the absolute bliss of plain Python syntax.
• Pyrr: A new Library that i am going to learn, this acts as a wrapper for numpy, allowing for easy rendering
• moderngl_window a pythonic librayry that allows one to easily show and render stuff.

Next Steps

Now that the compiler weight is off my back, I can actually focus on making this program amazing. The real fun starts now:

1. Setting up a clean Python environment with scipy, pyrr, moderngl and numpy installed.
2. Rendering stuff (Yahoo!).
3. Building the profile structures for the Kerbol system and our real-world solar system.

well then here is me installing pyrr and thinking of how to use and learn the library.

Devlog 3: Kerbal Gravity Program (KGRP)

KGP—well, actually let’s call it KGRP now because apparently “kgp” is already taken by some Kubernetes stuff, and I don’t want stuff breaking anyone’s cloud infrastructure—is a mission planning tool I’m building for KSP players and actual aerospace engineers to map out complex trajectories. It’s loosely based on libraries like Skyfield, Poliastro, and Trajectorize. The ultimate goal is to make it easy to plot out massive interplanetary trips, whether you’re trying to reach Jool and Sarnus (with the Outer Planets Mod) or calculating a real-world journey out to Neptune.

What I did today

Well, today was mostly chill on the numerical part. I got the RKF(4)5 adaptive step solver fully up and running, and the burns produced by the Lambert solver are perfect and insanely accurate. The physics side of things is feeling really solid.

But then came the C++ transition, which immediately humbled me.

For hours, this was only working in Python because CMake seriously hates me. Seriously, why does a plain text file have so much attitude? Even though I explicitly gave it the include paths in VS Code, the thing still refused to find where Eigen was. I was getting so incredibly frustrated that I was genuinely on the verge of ragequitting, deleting the whole directory, and typing sudo rm -rf out of pure spite.

And then I realized what a complete idiot I was being.

CMake wasn’t failing to compile the library. It had actually built the thing perfectly. The issue was that I was stubbornly typing ./build/kgrvs like a caveman, completely missing the fact that the compiled binary was sitting right there inside ./build/Release/kgrvs.

Once I actually typed the right path, the C++ code ran flawlessly and matched my Python results perfectly down to the decimal point. The engine is officially alive, and I need to go look at a wall for a few minutes to recover from the self-inflicted psychological damage.

(BTW here is me almost bricking my computer)

Devlog 3: Kerbal Gravity Program

KGP is a mission planning tool I’m building for KSP players and actual aerospace engineers to map out complex trajectories. It’s loosely based on libraries like Skyfield, Poliastro, and Trajectorize. The ultimate goal is to make it easy to plot out massive interplanetary trips, whether you’re trying to reach Jool and Sarnus (with the Outer Planets Mod) or calculating a real-world journey out to Neptune.

Hey there, i am very, very sorry for the wait, got caught up in school and illness, so ima try and be more punctual, maybe a devlog every week?

well, we will see if my timetable is free or “unstable”

What I did today

• Finally make a Lambert solver, the math was insanely hard and i am still getting insanely wrong numbers. (like a burn of 11,000 m/s to go to Duna in perfect conditions).
• for the Lambert solver, i had to create a new class, the Spacecraft class, this is the actual spacecraft that is going to go on the arduous journey to another planet or moon (basically a moving body class).
• I am in the process of making the Orbit class, the LambertSolver class and the solve_anomaly() function resistant to non elliptic orbits.

well then here is Ruff and Vs code screaming at me because of a single equal sign

Devlog 2: Kerbal Gravity Program (KGP)

KGP is a mission planning tool I’m building for KSP players and actual aerospace engineers to map out complex trajectories. It’s loosely based on libraries like Skyfield, Poliastro, and trajectorize. The ultimate goal is to make it easy to plot out massive interplanetary trips, whether you’re trying to reach Jool and Sarnus (with the Outer Planets Mod) or calculating a real-world journey out to Neptune.

What I did today

Today was way more math-heavy than I expected. I spent most of my time building out the core infrastructure:

• The Orbit class to actually handle orbital mechanics.
• The Body class for celestial bodies and barycenters.
• The absolute_position function to figure out the exact coordinates of an object in a nested system, tracking it all the way back to the root central body as the origin.

What I learned

• Planet tracking is wild: The sheer amount of math required to find the exact position of a planet at a specific timestamp is honestly mind-boggling. It took a lot of staring at equations, but once I finally understood the logic, implementing it became a lot smoother.
• The heavy lifters are terrifying: The core system is going to rely on a Lambert solver and an RK4 integrator. I’ll be honest—these algorithms are so intensely complex that it looks like scribbles on paper.

Anyway, here is a small test run of the Python prototype in action:

Devlog 1: Kerbal Gravity Program (KGP)

KGP is a mission planning tool I am building for KSP players and actual aerospace engineers to map out complex trajectories. Loosely based on Skyfield, Poliastro and trajectorize, The goal is to make it easy to plot out massive interplanetary trips, whether you are trying to reach Jool and Sarnus (with the Outer Planets Mod) or calculating a real-world journey out to Neptune.

What I Did Today

1. Mapped out the 4-phase development roadmap

   • Decided to use a mix of C++ for raw execution speed and Python for fast development.
   • Phase 1 (Basic Systems): Building out the underlying math frameworks and foundations.
   • Phase 2 (CLI Interface): Creating simple command-line helper functions.
   • Phase 3 (GUI Interface): Designing a desktop app version with a clean installation setup.
   • Phase 4 (Web Interface): Deploying a browser version so anyone can use it without downloading a thing.
     (Note: Organized it this way to work around the Stardance demo link limits while keeping the scope clear).

2. Coded the Universal Time Converter

   • Wrote the core function that converts calendar dates directly into raw seconds.
   • Made sure it seamlessly handles both Kerbal time standards and real-world J2000 epoch timelines.

What I Learnt

• Numba memory management: I found out that numba (the Python library I’m using to get close to C++ speeds) really struggles when handling pointers and raw memory addresses.

• Python can actually segfault: It actually threw a segmentation fault—which felt crazy to see inside Python code! Because of this, using nb.defered_type() is completely out of the picture for this architecture, so I’ll have to use something like scipy and numpy.

well for your entertainment, here is a screenshot of me trying to figure out why the hell was VS code giving me a problem (i forgot a semicolon on the line before):