HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
mockingbirdnest
Principia
C++2015–2026
mockingbirdnest / Principia

Principia

𝑛-Body and Extended Body Gravitation for Kerbal Space Program

16Distinct people
22Mentions
0Explicit recommenders
940GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

𝑛-Body and Extended Body Gravitation for Kerbal Space Program

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year22 dated mentions

Observed mentions: 2015-03-18 17:19:54 UTC to 2026-06-29 17:23:25 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC505
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

22 sources
> And I'm not aware of any KSP mod that helps you plan slingshots If you're willing to go for the full n-body package, Principia [0] has a pretty nice flight planner that is quite usable for planning more complicated missions. KSP Trajectory Optimization Tool [1] is a non-mod alternative with some additional capabilities beyond flight planning as well. I think this one is designed for stock gravity so it should be usable in an otherwise vanilla install. [0]: https://github.com/mockingbirdnest/Principia [1]: https://github.com/Arrowstar/ksptot
In The Parker Solar Probe will make its closest approach yet to the Sun
I haven’t read all of it, but the Principia source code has a comprehensive units system and makes effective use of Unicode: https://github.com/mockingbirdnest/Principia/ https://github.com/mockingbirdnest/Principia/blob/master/ast... is a decent example of both: // We compute the mean rate (slope) of the mean anomaly M(t), the mean // argument of latitude u(t), and the longitude of the ascending node Ω(t). … Product<Angle, Square<Time>> ʃ_Mt_dt; Product<Angle, Square<Time>> ʃ_ut_dt; Product<Angle, Square<Time>> ʃ_Ωt_dt; … ʃ_Mt_dt += (Mt + previous_Mt) / 2 * dt; ʃ_ut_dt += (ut + previous_ut) / 2 * dt; ʃ_Ωt_dt += (Ωt + previous_Ωt) / 2 * dt; … anomalistic_period_ = 2 * π * Radian * Δt³ / (12 * ʃ_Mt_dt); nodal_period_ = 2 * π * Radian * Δt³ / (12 * ʃ_ut_dt); nodal_precession_ = 12 * ʃ_
Read the rest
Ωt_dt / Δt³; The advantages are concise notation plus compile–time guarantees that the units work out. I don’t care much for C# in general (or C++ for that matter), but I like the results here. Sounding out the Greek names occasionally used as release names is always fun too.
In Ask HN: What's the best source code you've read?
Two recommendations for KSP1 mods, if you want progression from the base game and to learn a ton about real spacefaring history: RP-1: Realistic progression career using the real solar system, real part configurations, etc. Actually a mod pack of about 80 different mods including the Realism Overhaul base pack. Start in 1951 and build your space program. Newly updated for v1.12 (the last KSP1 minor version) and has an express install option now. Forum Page: https://forum.kerbalspaceprogram.com/index.php?/topic/190040... Wiki: https://github.com/KSP-RO/RP-0/wiki Principia: N-body orbital mechanics. Actively developed, works with the stock solar system & Real Solar System. A truly stunning achievement. https://github.com/mockingbirdnest/Principia
In Release Date Update from the KSP2 Team
> For a basic example-numbers implementation, replacing an n-body simulation that updates every 10 seconds, I was imagining that you might update the force vector 1/100th as often, every 1000 seconds. That's plenty fast to accurately handle a multi-day orbit around a lagrange point or a low energy transfer. The paths the craft take should look completely normal. I'm honestly curious about what Principia's largest step size is when calculating predictions. Best I can tell, the step size starts large and shrinks until the tolerance-to-error ratio is small enough [0]. I can't seem to figure out how large the initial step is, though. But in any case, I suppose it'd come down (again) to how important accuracy is. I'm now extremely tempted to fire up KSP with Principia to see what happens if I were to mess with the timesteps. Don't think I'm fa
Read the rest
miliar enough with the codebase to mess around with it properly, though. > If you then combine a normal single-influence orbit with that force vector, you could summarize 1000 seconds of orbit into one moderately complex equation. A lot hinges on the combination being as simple as the sentence makes it look. I'm not entirely convinced that the analysis is straightforwards (fewer forces, but you might lose some useful properties) but I'll be the first to admit that I'm not exactly an expert on this subject. I really wish I had more time and knowledge; this sounds like a good candidate for some test code. I have absolutely no faith I'd be able to pull off something proper, though; good n-body integrators are well out of my skill range, and I don't know how I'd even begin approaching your proposed scheme outside naive integration (which wouldn't exactly be a fair comparison to high-quality n-body integrators). Did you have a particular method of combination in mind? > Treating the forces as constant over a stretch of time, when they actually are almost constant, shouldn't have all that much error, unless I'm missing something glaring. Well, maybe; I'm honestly not confident enough in the possible models I had in mind to stand behind what I said (I was thinking in terms of the relative magnitude of the "correction" of the second force, but looking back I'm not entirely sure how relevant that is). I really shouldn't have been so confident in that particular line of questioning. Sorry about that. [0]: https://github.com/mockingbirdnest/Principia/blob/f84c96953a...
In Orbit Tessellation developer diary for Kerbal Space Program 2
A few comments: There are a few points where I feel the author might have been taking force/velocity diagrams a bit too literally (and is a bit sloppy with the difference between force and velocity). > the following main velocity vectors acting on it: > gravity acceleration > thrust > rocket's velocity and > Once in orbit, the spacecraft will have two main forces exerting their grab onto it: the tangential velocity and the gravitational pull. I'm not sure whether someone new to those concepts would notice, but it's a potential source of confusion. > Gravity Turn or Pitchover is the second maneuver that is executed as early as possible by using the gimbal of the engines or by using cold gas thrusters on the nose of the rocket or a combination of the both. Honest question here: do any rockets use their cold gas/RCS thrusters for th
Read the rest
e initial pitchover? I feel like they wouldn't be powerful enough in most cases to pull it off. > The velocity vectors are similar to the vertical flight phase but because the gravity acts on the same vertical plane it makes the spacecraft change it's pitch without additional input from the engines, tasking them with the only job of increasing the speed of the spacecraft. Technically, it's a combination of gravity and aerodynamic forces that cause the pitch to change. Gravity causes the velocity vector to turn, but doesn't exert a (noticeable) torque. It's aerodynamic forces that work on the rocket to (hopefully) keep it aligned with the velocity vector. This is why some rockets have fins at their base - additional drag at the base ensures that the aerodynamic forces keep the rocket pointed the right way. Rockets without enough drag near their base or too much drag at their nose will tend to flip right around with interesting consequences. ---- That being said, it's one thing to read about orbital mechanics, but it's hard to beat hands-on experience for really wrapping your head around things. As mentioned in the article, Kerbal Space Program is one frequently-recommended way to go about this, and does a fairly good job with the basics. Not to say that the basics aren't much; you can get quite far with "just the basics", and arguably they'll work just fine for the most common mission profiles. KSP does use a simplified gravitational model, though, taking into account the gravitational forces of only a single body at a time, which means it's missing some more interesting features of full n-body dynamics, such as Lagrange points and low-energy transfers. If you're interested in those, consider trying the Principia mod, which adds n-body dynamics, non-uniform gravitational fields, and more [0]. There's also the Realism Overhaul mod if you wish to work with more realistic rockets and celestial bodies [1]. [0]: https://github.com/mockingbirdnest/Principia [1]: https://forum.kerbalspaceprogram.com/index.php?/topic/155700...
In Orbital Mechanics – How do rockets get to where they're headed?
The vanilla KSP physics aren't realistic, only the nearest/most influential body exerts gravity on the spaceship. With the Principia mod[0], more realistic and complex maneuvers[1] can be simulated. "Orbit Type Diagrams"[3][4] show the fractal-like complexity of three or n-body problems[5][6] [0] https://github.com/mockingbirdnest/Principia [1] https://www.youtube.com/watch?v=l3PCCJZzVvg [3] https://www.semanticscholar.org/paper/Crash-test-for-the-res... [4] https://www.semanticscholar.org/paper/Crash-test-for-the-Cop... [5] https://en.wikipedia.org/wiki/Three-body_problem [6] https://en.wikipedia.org/wiki/N-body_problem
In Orbit Tessellation developer diary for Kerbal Space Program 2
> It's not like you need to update orbits nearly as often as part physics. The max time warp is 100000x, and at that speed if you updated orbits every 10 game seconds that would only be 400 calculations per tick, per craft. So without that simplification you might need a smaller cap on satellite swarms, or a max speed of 10000x, but time warp would still be well inside the realm of "possible". KSP's most well-known n-body physics mod does precisely this. 1 integration step is performed every frame by default, but during warp an integration step is performed every 10 in-game seconds for vessels and every 35 minutes for bodies [0]. > You could probably get processor use really low by using an exact curve for the most influential object and a very slowly updated offset for other influences. The Keplerian curve no longer applies once you int
Read the rest
roduce additional influences, though, so it doesn't really matter how (in)frequently updates are applied for those other influences. The approximation wouldn't be very good farther away from a body as well, as the difference in effect between the "most influential" and less-influential bodies would be smaller. [0]: https://github.com/mockingbirdnest/Principia/issues/2247#iss...
In Orbit Tessellation developer diary for Kerbal Space Program 2

Showing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.