Devlog 9 — Kerbal Gravity Program: the REPL is (almost) done

No devlog last week — life happened, then OpenCode helped me absolutely cook.

Newcomers: KGRP is a mission planner for KSP (runs outside the game). You
define a spacecraft, stack events on a timeline, and the sim runs them. Plan
in the tool, fly in the game.

Where we are

The REPL is nearly feature-complete. Every mission action is a TicketEvent —
coast, maneuver, burn, engine toggle, science. The REPL never touches your
ship directly; it just advances a ticket in UT and events fire when the
timeline reaches them. One plan drives the renderer, physics, and save file.

Also closed the loop on “one source of truth”: the fancy integrator used to
run in a vacuum (zero gravity) when fired from a ticket. Now go, advance,
and reset all agree on where you are.

go

Pick a start and end orbit from the presets and it works out burns,
coasting, and delta-v, then schedules them:

> go current moon:3a
Transfer plan:
  Current (200,000m circular, 0.0 deg)  ->  Mun orbit (11,400,000m circular, 0.0 deg)  (about Kerbin)
  Burns: 2   Total delta-v: 1,112.7 m/s   Duration: 27,130.1s
    burn   @ 0.0s  dv=764.2 m/s  Raise apoapsis to transfer
    coast  0.0s -> 27,130.1s  Coast to apoapsis
    burn   @ 27,130.1s  dv=348.5 m/s  Circularize / match target
  Resulting orbit: pe=12,000,000m ap=12,000,000m i=0.0 deg around Kerbin

Presets are editable (and saveable to presets.json); the planner core is a
plain importable function (go_plan(ticket, ...).total_dv).

Usability

• Time input isn’t a math exam: advance 2d 5h, time "Year 2, Day 100".
• Per-use overrides without touching presets: go current preset:molniya incl=30.
• go shows the plan and asks before committing (gradual / instant / cancel).
• edit now handles ships, not just bodies: mass, fuel, orbit elements.
• New-ticket wizard hands you an engine and 3,000 kg of fuel instead of a paperweight.
• After a reset you can clear/redo the timeline without fighting the guard.

What’s next

Some math is still coarse: plane changes are exact only for moon targets,
synchronous orbits are a placeholder (no body rotation yet), arg-p/LAN drift
isn’t modeled, and error messages need work — for when you type
advance 5 bananas.

Fun one I found: escaping at exactly escape velocity puts the orbit at
eccentricity 1.000000 and the math gives up — the craft freezes and frame
switches / go turn to nonsense. Interplanetary go is broken because of it,
but burning slightly past escape fixes it (properly hyperbolic, maths happy).
Just needs wiring in.

In the meantime

Planning to put it up on PyPi and hope it works

Devlog 8: Kerbal Gravity Program

For anyone who’s new here, KGRP is a mission planning tool I’m building for KSP (and hopefully real-world missions too). The goal is to make planning orbital transfers and interplanetary missions a lot easier. Think of it as something inspired by libraries like Skyfield and Poliastro, but with a bigger focus on actually planning missions

Today and the days after i gave my last devlog were actually useful, i mainly just created a new class based system (yes i am forced to, because my idea needs tooo many moving parts) called the Ticket:

• The Ticket allows you to plan entire journeys using TicketEvents, stuff that define what can happen to a spacecraft (14 of them).

for example, you can have a ticket that contains a maeuver, a coast, an rcs translation, a docking and more.

and one more thing, instead of a CLI (one command and forget), i am instead making a REPL (it remembers what you did).

so yeah, that sums most of it up and also i made a new banner for KGRP (kinda yay???)

What’s next

so the main thing is to just start making the REPL using prompt-toolkit and other stuff.

until then, see ya

Devlog 7: Kerbal Gravity Program (KGRP)

For anyone who’s new here, KGRP is a mission planning tool I’m building for KSP (and hopefully real-world missions too). The goal is to make planning orbital transfers and interplanetary missions a lot easier. Think of it as something inspired by libraries like Skyfield and Poliastro, but with a bigger focus on actually planning missions.

What happened today?

Today was surprisingly productive and useful.

The biggest thing is that the renderer finally works. I spent way too long fighting with it over the past few days, so it’s nice to finally be able to move planets around without everything exploding.

I also added a few other things:

• You can now create entire planetary systems from a planet.json file.
• Added adapters for PySide6 and NiceGUI, so there are a couple of different ways to use the renderer now.
• Started working on a more realistic gravity simulator that can deal with things like Lagrange points.
• KGRP finally has an actual logo (＼(＾▽＾)／) instead of me pretending the text was good enough for docs and stuff.

One thing I still need to fix is the JSON loader. Right now it only really likes absolute paths, which is… less than ideal.

The renderer tried to gaslight me

I swear I’m not making this up.

Earlier today I found this absolutely cursed bug where, if you flew the camera into the Sun and zoomed out, the whole scene turned into this weird fisheye effect with random lines stretching across the screen.

I was already mentally preparing myself to spend the next few hours digging through camera code and VTK documentation…

…and then it just stopped happening.

I didn’t fix it.

I didn’t even change anything related to the camera.

It just… disappeared.

So either I accidentally fixed it without realizing, or it’s waiting until I show someone the project before it decides to come back.

What’s next?

Nothing too exciting, mostly polishing things up.

• Fix the JSON loader.
• Squash whatever bugs are still hiding in the renderer.
• Improve the CLI a bit more.

Anyway, here’s the renderer doing the thing (oh, gotta fix that) and the logo (idk if it’s good, comment about it).

Devlog 6: Kerbal Gravity Program (KGRP)

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

Today was a very, very buggy day. I had to tackle the core rendering systems, but I ended up running a grueling gauntlet through almost every Python graphics library out there—Panda3D, Ursina, ModernGL, VPython, and more.

Every single one of them introduced some kind of blocking issue:

• Windows that were supposed to pop up via Tkinter or Pygame-CE started doing random things like teleporting wildly across my screen or rendering with completely broken layout dimensions.
• Even when a window finally initialized and stayed stable, it would just mock me with a dead black screen entirely missing our blobs of color (the actual planets and calculated orbit lines).

This black-screen loop is exactly what hit me when I switched over to PyVista.

Why the Viewport went Black

Staring into a blank 3D canvas is a rite of passage when writing an engine from scratch. After tracking down the pipeline bugs, the black screen in PyVista boiled down to three classic astrodynamics simulation mistakes:

1. The Compound Drift Bug (mesh.translate)
   Using mesh.translate(inplace=True) directly mutates the underlying vertex memory of the sphere meshes. Because my physics engine loop advances frames based on absolute coordinates (get_absolute_pos_at_ut), relative delta transforms compounded exponentially. Within frame one, the planets physically flew millions of kilometers away from the camera.
2. The Camera Initialization Trap
   Setting camera_position = 'iso' while the newly instantiated planet objects were still sitting uninitialized at (0, 0, 0) forced the viewport to lock its focus onto a microscopic bounding box. The moment the first timer tick updated positions, everything teleported way past the active field of view.
3. Scaling
   Using a singular scale factor for both orbit diameters and planetary dimensions created a massive rendering mismatch. A planet with a 6,000 km radius shrinks down to a fraction of a single pixel when drawn on a canvas scaled to capture massive astronomical unit (AU) trajectories, rendering it invisible.

Next Flight Steps for Devlog 6

With a stable graphics viewport finally up and running, the graphics engine foundation is secure. The next challenge is implementing the actual trajectory planning functionality. My primary focus items for the next devlog will be:

• The Trajectory Tracer: Working out how to render a dynamic, rolling polyline tail behind a Spacecraft body as it traces arcs across different coordinates.
• Camera Tracking Hooks: Hooking into interactor mouse clicks so that double-clicking a planet or vessel pins the camera target matrix to that object, keeping it centered even at high time warp rates.
• Optimizing Kepler Solvers: Ensuring the underlying analytical Newton-Raphson solvers can handle high eccentricities without dragging down frame rates.

Devlog 5: 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 4: 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):