eggrobin

Буняковский is out. A change log can be found here.

And thus we have another case of accidental Turing-completeness. Proof—see also gist: Machine { State { state = a } } @Machine:HAS[@State:HAS[~state[halt]]] { MM_PATCH_LOOP{} // Clean up the mess. !MM_PATCH_LOOP{} @State:HAS[~stepped[*]] { stepped = false } @State:HAS[~left_tape[*]] { left_tape = ... } @State:HAS[~right_tape[*]] { right_tape = ... } @State:HAS[~symbol[*]] { symbol = 0 } // Feed tape for one step. @State:HAS[~left_tape[*,...]] { @left_tape = 0,... } @State:HAS[~right_tape[*,...]] { @right_tape = 0,... } // We step only once per iteration, that way the tape fed above is enough. @State { @stepped = false } // Transition table (3-state 2-symbol busy beaver). @State:HAS[#symbol[0],#state[a],#stepped[false]] { // Write 1, move left @right_tape = #1,$right_tape$ @symbol = #$left_tape[0]$ @left_tape ^= /[^,]+,(.*)/$1/ @state = b @stepped = true } @State:HAS[#symbol[0],#state[b],#stepped[false]] { // Write 1, move right @left_tape = #1,$left_tape$ @symbol = #$right_tape[0]$ @right_tape ^= /[^,]+,(.*)/$1/ @state = a @stepped = true } @State:HAS[#symbol[0],#state[c],#stepped[false]] { // Write 1, move right @left_tape = #1,$left_tape$ @symbol = #$right_tape[0]$ @right_tape ^= /[^,]+,(.*)/$1/ @state = b @stepped = true } @State:HAS[#symbol[1],#state[a],#stepped[false]] { // Write 1, move right @left_tape = #1,$left_tape$ @symbol = #$right_tape[0]$ @right_tape ^= /[^,]+,(.*)/$1/ @state = c @stepped = true } @State:HAS[#symbol[1],#state[b],#stepped[false]] { // Write 1, move left @right_tape = #1,$right_tape$ @symbol = #$left_tape[0]$ @left_tape ^= /[^,]+,(.*)/$1/ @state = b @stepped = true } @State:HAS[#symbol[1],#state[c],#stepped[false]] { @state = halt @stepped = true } } // Cleanup. @Machine:HAS[@State:HAS[#state[halt]]] { @State { !stepped = delete } } // Output: // Machine { // State { // state = halt // left_tape = 1,1,0,... // right_tape = 1,1,1,0,... // symbol = 1 // } // } The above is the 3-state 2-symbol busy beaver, but it is straightforward to encode any Turing machine in a similar manner. As an immediate corollary, whether ModuleManager will halt on a given set of cfg files is undecidable. Thanks to @Sigma88 for helping me understand ModuleManager's features.

Thanks! Prasenjit Saha and Scott Tremaine, Long-term planetary integration with individual time steps, The Astronomical Journal, 1994. Also on arXiv.org.

I would not really consider the current release stable enough (an use-after-free was still in there, and forgetting of histories is broken so saves quickly get unmanageably big). Fortunately, Буняковский should come out soon-ish (targeting 1.1). Nice demonstration of launching into a target plane there!

This will not be in Буняковский, because it would require some significant modifications to the logic of the flight plan and its UI. Apsides, on the other hand, will be in Буняковский (they have already been implemented). They are shown with respect to the fixed body in the reference frame, if any: in the barycentric rotating frame neither body is fixed, since the barycentre is fixed instead, so no apsides are shown; in the body-centred non-rotating frame the apsides are shown with respect to that body, just like in stock. In future (post-Буняковский) versions we plan to add the surface frame of a body (there the apsides will be shown with respect to that body, obviously), and the frame centred on a (secondary) body and fixing the direction of its primary (e.g. the frame fixing the centre of the Moon and the Earth-Moon line), where apsides will be shown with respect to the secondary (in that example, with respect to the Moon). Nice video! It showcases the various reference frames and the use of flight planning very well. One remark concerning the Frenet trihedron and navball, once you're in space you probably want to check "Fix navball in plotting frame"; that aligns the navball with the reference frame (so that you can see the Kerbin-Mun orbital plane on the navball), and more importantly, it makes the tangent/normal/binormal (or prograde/radial/normal in stock KSP terminology) correspond to the plotted trajectory. If you check that option, you'll see that at your L4 orbit insertion manœuvre you will have the navball markers aligned with the tangent, normal and binormal markers shown for your manœuvre, rather than aligned with the Kerbin-centred trajectory. Since at that point on your trajectory the tangent direction in the rotating frame is nearly opposite stock KSP's prograde marker, confusion can easily result from keeping the stock markers. We should really document that option and make it more intuitive to use.

It's SRKNs and explicit embedded RKNs (really only one of the latter). The implementations (including obsolete ones, the ones with abbreviations in the name) can be found in https://github.com/mockingbirdnest/Principia/tree/master/integrators (https://github.com/mockingbirdnest/Principia/blob/master/integrators/symplectic_runge_kutta_nystr%C3%B6m_integrator.hpp are the available SRKNs, https://github.com/mockingbirdnest/Principia/blob/master/integrators/embedded_explicit_runge_kutta_nystr%C3%B6m_integrator.hpp is the available variable-step embedded explicit RKN). Additional documentation on composition methods can be found in https://github.com/mockingbirdnest/Principia/blob/master/documentation/Composition%20methods.pdf. Interesting overviews of these subjects can be found in some of the references in the bibliography (along with completely unrelated aerospace and astronomy technical reports and normative documents), see for instance Mclachlan, Reinout, and Quispel, Geometric Integrators for ODEs. As for terms beyond J2, maybe (for instance, the Moon has a fairly significant C22).

@Dolin, the next version, Буняковский, which will target 1.1, will work with win64; as you may be aware, win64 is unsupported for now.

I tried looking at a real eclipse with scatterer (it worked! ), see the post linked below.

@nilof: very nice orbits! Unrelated: a solar eclipse (RSS by @NathanKell et al. for the bodies, Scatterer by @blackrack for their shadows, Principia for their motions). It goes without saying that without Principia, real-life eclipses cannot be observed in RSS, since in stock RSS the nodes of the Moon's orbit do not precess, whereas they do so in 18.60 years in real life. The shadow looks very nice, for comparison see the recent Himawari-8 images (video by @illectro). Note that this required a bug fix to Earth's rotation (which is off by a day per year in RSS since 1.0.5).

The 2015 ones for x86, linked in the FAQ: https://github.com/mockingbirdnest/Principia/wiki/Installing,-reporting-bugs,-and-frequently-asked-questions#its-not-starting-dllnotfoundexception.

It is also the only mod that will cause actual crashes (as opposed to just breaking and throwing exceptions), that has its own logs, that requires the user to download different binaries for different platforms (even within Linux, things vary, the Ubuntu build seems to have trouble on arch), that requires the user to install the appropriate C++ runtime (this is probably what @FreeThinker is running into by the way, missing or misinstalled C++ runtime), etc. As a result, a (small) potential barrier, and one that hopefully heightens the chances of having the user read the FAQ, is welcome while the mod is still very unstable: In addition, the IRC channel allow users to get support fairly quickly with the usual stuff (e.g. misinstalled C++ libs), and facilitates bugreporting (since I can quickly specify which logs are needed, how to start a journalling instance to replicate the bug, etc.). When we consider that things are stabler, we will switch to a more conventional release mechanism. In the meantime this minor inconvenience helps us fix issues more quickly by interacting with users, which helps us find and diagnose the bugs.

NOTICE: There is a bug in Buffon (2016022220-Buffon-0-g0455d0cb0e4b0b584a84caf40520cf7993903e0c) that causes a crash when starting a new save with RSS (loading an existing save works fine). The hotfix "2016022220-Buffon-12-g1298cffba22d90119bd59e9933a9ef261922a423" (let's call it "Buffon + 12") resolves that, so if you run into this issue just go back to the IRC channel to get the latest build, it will be Buffon + 12. There are no other changes between Buffon and Buffon + 12. Unrelated: On the flight plan, coasting is in blue, while burning is in orange-red.

Buffon is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Changes: The integrators now limit the number of steps they perform, and terminate if their step size vanishes. This avoids issues where the plugin would hang when the trajectory would accidentally get very close to the centre of a celestial body or spend a long time in a low orbit. A use-after-free bug has been fixed which caused a variety of crashes (#872, #881, #889, #896) when the historical trajectory was shortened in a way that would cause it to start after the beginning of the flight plan. The version identifier of the plugin is now displayed in the UI to make it is easier to assert what version is running. A verbosity option has been added to the journalling which makes it easier for us to reproduce crashes. The first two items above are illustrated by the following two reports. For more details see all 19 pull requests between Brouwer and Buffon.

Some clarifications regarding reference frames and flight planning. Reference frames. At the moment, two types of reference frame are available: the nonrotating reference frame centred on one body, and the barycentric rotating reference frame. The nonrotating reference frame centred on one body (let's call that body ⨁) is the one that stock KSP uses inside the sphere of action of ⨁. In that reference frame, if ⨁ is a point mass and the orbit is unperturbed, the orbit will be a conic. The navball's reference plane is the celestial equator, and its reference direction is the origin of right ascension (this navball is grey and black, the reference direction is marked ♈, right ascension is labelled in hours and declination in degrees). The barycentric rotating reference frame fixes the barycentre between a body and its primary (let's call them ☽ and ⨁ respectively), the line between them, and the plane of their orbit. The navball's reference plane is the orbit plane, and its reference direction is the line from the secondary to the primary (this navball is purple, its reference direction is marked I for primary, and the opposite direction is marked II for secondary). A nice feature of the barycentric rotating navball is that one can see launch windows into inclined orbits: when a rocket sitting upright on the launch pad on ⨁ points into the orbit plane (the grey band between the hemisphere of the navball), launching at that inclination will put it in the plane of ☽'s orbit. As an illustration, the following shows a free-return trajectory (fuchsia) and a convoluted insertion into some sort of loose orbit around the Earth-Moon L4 point (royal blue), in all three relevant reference frames. Let us consider the (fuchsia) free-return trajectory. In the Earth-centred nonrotating reference frame, we start on a conic, then "something non-Keplerian happens", then we end up on another conic. This is (approximately) what one would see in stock KSP (using conic draw mode 3). It hard to see what is happening when we interact with the moon, or how close we come to it. In the Moon-centred nonrotating reference frame, we start on a highly non-Keplerian trajectory, pass by the moon in a nearly-straight hyperbolic arc, and go back to non-Keplerian motion. Here it is easy to see how close we get to the Moon, but the parts of the trajectory that are far from the moon are very confusing. In the barycentric rotating reference frame, we can see that we go around the moon, staying far away from it, and come back to Earth: this reference frame gives us the clearest overview, while details close to either body are best investigated using the body-centred reference frames. Note that the Moon (and the Earth) are not fixed in the barycentric rotating reference frame; instead they move towards each other and away from each other over the course of their orbit. If the Moon's orbit were perfectly circular, the bodies would be fixed in the barycentric rotating reference frame. The frame in which the trajectories are plotted can be chosen by clicking on "Plotting frame selection...". Prediction and history. The history (drawn in acid green) shows the trajectory that the craft has followed up to now. The prediction (drawn in fuchsia) shows the trajectory that the craft would follow in free fall (without engine thrust), much like stock KSP's plotted orbit. See for instance the following launch from Kourou: Flight planning. A principia manœuvre is a rocket engine burn (following Циолко́вский's equation), in a fixed inertial direction. The direction and intensity of the burn are specified by giving three components (tangent, normal, binormal) of the Δv. The tangent, normal, and binormal direction form the Frenet frame of a free-falling trajectory in the manœuvring frame; in particular, in the body-centred frame, for a Keplerian orbit, they correspond to stock's yellow, blue, and pink markers respectively (confusingly, the KSP wiki calls the binormal "normal"). A flight plan consists in a series of manœuvres. A flight plan can be created by pressing "Flight plan..." → "Create flight plan". Once the flight plan is created, it is no longer affected by what happens to the craft: in particular, the initial mass used by to solve Циолко́вский's equation is the initial mass when the flight plan was created. The coasting phases of the flight plan are plotted (in the plotting frame) in royal blue; the burning phases are plotted in orange-red. Manœuvres can be added to the flight plan by pressing "Add manœuvre". By default the manœuvring frame is the current plotting frame. A trihedron marks the beginning of the manœuvre, showing the tangent, normal, and binormal directions for that manœuvre. See below for an illustration of the plotted flight plan and manœuvre marker. By default, a manœuvre will be configured to use all active engines; if there are none, it will fall back to all active RCS thrusters; if there are none, it will fall back to an unrealistic stock-style instant impulse. This does not work well with solid engines (since they cannot be activated without providing thrust), we will attempt to improve engine specifications in a future release. Note that there is no check of available Δv: the user can plan a burn that requires more fuel than is available, just like in stock. A countdown to the beginning of the next manœuvre is shown at the top of the flight plan, or, if a manœuvre is in progress, a countdown to the end. To execute a manœuvre, select "Show on navball". This will create a stock manœuvre node in the direction of the upcoming or ongoing manœuvre, SAS (or MechJeb) can then be set to Node to point in the right direction. The node can be used for timewarping with Kerbal Alarm Clock. When the ignition countdown reaches 0, light the engines that were used to plan the burn; as the burn progresses, the prediction can be seen to converge towards the flight plan; when the cutoff countdown reaches 0, shut down all engines. Note that the stock node is only here for guidance: its Δv counter does not decrease as you burn, and it does not show a residual Δv like in stock.

Brouwer is out, you can get it by asking on IRC (#principia on EsperNet), as usual. User-facing features: The whole Frenet trihedron is now displayed in the correct reference frame when "fix navball in plotting frame" is selected. The initial state (and thus the evolution) of the system is now deterministic even when not using RSS. Tidally locked bodies no longer spin back and forth madly (on the other hand, they may not be tidally locked if their mean period differs from their Jacobi osculating period). When using stock, the Jool system is modified, cancelling the apocalypse. Specifically, we make the inner Jool system nonresonant, since we have been unable to replicate the results (Manley, priv. comm.) according to which some interpretations of the orbital elements yielded a stable Laplace resonance, despite systematic searches of the Jacobi osculating elements. In addition, at Scott Manley (@illectro)'s and @UmbralRaptor's suggestion, we put Bop in a surprisingly stable, though highly precessing, retrograde orbit. The modified system is stable for upwards of a century. Flight planning has been implemented. Modder-facing changes: When a Cartesian initial state cfg is not given, the KSP orbital elements are interpreted in a hierarchical osculating Jacobi fashion; for instance, the orbital elements of Jool are the osculating elements at game start of the orbit of the barycentre of the Jool system around the barycentre of the (sun, moho, eve, gilly, kerbin, mun, minmus, duna, ike, dres) system; the elements of Laythe are the osculating elements at game start of the orbit of Laythe around Jool; the elements of Vall are the osculating elements at game start of the orbit of Vall around the Laythe-Jool barycentre. Optimizations: The Windows build now uses profile-guided optimization (we estimate that this improves performance by ~20%); in theory this could be extended to other platforms. The evaluation of the Чебышёв series has been significantly optimized. @sarbian made trajectory rendering faster (as he pointed out, there is still lots of room for improvement). Other features: Everything that crosses the interface can now be journalled if the right flag is set, allowing us to replay the C++ side of a session; this is useful for tracking down tricky bugs, and it enables profile-guided optimization. Highlights of miscellaneous library changes; beware, this gets technical: In order to get the full Frenet trihedron, which in turn was needed for manœuvres, since the Δv is defined in the Frenet frame at the point of ignition, geometric acceleration (the acceleration of a free-falling trajectory) in any reference frame was needed. To that we created two abstractions, RigidMotion, the derivative of a RigidTransformation, and DynamicFrame, the definition of an arbitrary reference frame. The navigation frames (the frames in which the trajectory is drawn, or with which the manœuvres are defined) implement that (see BodyCentredNonRotatingDynamicFrame and BarycentricRotatingDynamicFrame). In order to interpret the orbital elements of KSP in the hierarchical Jacobi fashion described above, support was added for Kepler orbits (implementation), Jacobi coordinates, and hierarchical systems. Discrete trajectories were reworked, with a heavy dose of CRTP. In preparation for the surface frame in the future, RotatingBody was added. The C++ interface headers and C# extern declarations were repetitive and error-prone, this was exacerbated by the addition of journalling code and replaying code, so a generator was written to produce all of that from an annotated proto. @UmbralRaptor contributed some tests of lunar eclipse timings. For both Kepler orbits and lunar eclipse timings, a simple root finder was needed, bisection does the job for now. A bibliography was written, at @UmbralRaptor's request (it is somewhat out of date). SolarSystem, a class for initializing ephemerides from protobuf text format configuration files for testing purposes was written. A script for generating the initial state configuration files from the emails sent by JPL's HORIZONS system was written (the gravity model configuration file is hand-curated). An utility turns the protobuf text format configuration files into KSP ModuleManager configuration files for RSS support. Various geometric utilities were added: angles (implementation), spherical coordinates (more are needed). More C++11/14 features were used as they became available (for instance, the units are now constexpr), in addition we now use std::experimental::optional. C++14-related improvements were made to not_null. For more details, see all 195 pull requests between Bourbaki and Brouwer.

Fortunately, there is a steady supply of fun things to do (although they will be far more accessible once we get manœuvre nodes working).

Thrusting does not move planets (it doesn't in stock, and we just grab the change in velocity from what the stock game does). Even if we handled thrust ourselves, it would be significantly more convenient to ignore the effects of thrust on celestials: their orbits are (since Bourbaki) precomputed by the Ephemeris class, allowing us to use a larger timestep for that, as well as compute it only once. Ephemeris then provides functions to integrate the trajectories of massless bodies within the system (optionally with some proper acceleration), and that is what we use for vessels (stock's asteroids are vessels too).

It would, but it's somebody else's problem. Ah, on the surface, yes.

Yes, but that requires physical assumptions about the bodies (and in practice, it's a really bad way to get this number for planets). Considering the impossibly-dense material the Kerbin system is made of, we will leave the design of its physical properties to people who design solar systems (they might want to add fjords ). Surely you mean oblate, the gravitational field from a homogeneous sphere is that of a point mass.

Only J2 at the moment, so that's just the quadrupole. We only added oblateness for bodies where we had readily-available data, so the sun, the planets, the Moon, and Vesta, in our real solar system (it turns out that JPL doesn't have SPICE kernels for the Kerbin system ). It's in config files, so it could be added, but you'd need to add a Cartesian initial state too. Yes, but it won't be soon. On the other hand, I'm working on manœuvre nodes right now. This first cut of manœuvre nodes will use extended burns (rather than instant burns like stock), but inertially guided (following some fixed inertial direction, rather than tied to the prograde vector; in order to make the interface palatable, we'll enable specification of that direction with respect to the prograde vector at the start of the burn, but it won't track), and constant-thrust (so the fancy SRBs from Realism Overhaul won't be accurately predicted). Other things on the roadmap for Brouwer include new plotting frames: surface frame, two-body frame centred on one body rather than on the barycentre, enabling this sort of plot, or better visualization of heliosynchronous orbits (the barycentre frame is nice for Lagrange points or transfers, but with even mildly eccentric orbits it's not pretty for orbits around either body).

I do offer the mod as a download, just go on the IRC channel and ask for it. You're probably asking why I don't simply put the link on the forum though. Well, this: In particular, there are some atypical considerations (bugreporting is different than for other mods, we have our own logs and our main failure mode is crashing, you need different builds for different platforms, you need to have the proper C++ runtime for your build). More generally, I'm afraid of this place turning into the FAR or MechJeb thread while this mod is under heavy development; I'd rather spend my time writing the mod than managing a messy forum thread, especially since it tends to take me a while to write a post (this one took me 25 min). Drag is mentioned in the OP, in the "Further modding" section, however it will be a while before we add that. When using RSS with Bourbaki, you already get interesting precession of low or medium Earth orbits due to oblateness, which requires you to either correct every now and then, or to pick stable orbits (üþûýøѠorbits are fun!). Edit: Oh, I had entirely forgotten this "prototype useless for gaming purposes" thing. I wrote that back in the days of the C# prototype in February 2014, that plugin ignored thrust (and was ridiculously slow)... I should probably remove that, considering I always play with principia.

You don't need to understand the technical details discussed in the OP to use the mod, much like you don't need to understand control theory to use MechJeb; these details are just there for people interested in what happens behind the scenes (this is a development thread after all).

To clarify, initial state and gravity model configs are not needed, if there are none we'll use the gravitational parameters, positions, and velocities given by KSP when the plugin starts. They are needed if you wish to get oblateness (KSP has no concept of this, so I do not have this information), or to use a very accurate initial state (the initial configs are directly fed into the plugin, without going through KSP's orbital calculations).

Note to Principia users regarding this mod: The new version of Principia (Bourbaki) comes with initial state and gravity models configs for all bodies in Real Solar System as of 2015-08-16. Moreover, initial states and gravity models are provided for the following bodies from this mod: Charon; Titania; Oberon; Ariel; Umbriel; Miranda; Ceres; Vesta (fresh data from the Dawn mission ). We very strongly recommend that you use Charon, since otherwise Pluto keeps its motion around Charon without having Charon to pull it back, and ends up in a strange orbit. No other bodies are supported, so if you do install pozine's pack, make sure you remove all other bodies: if Real Solar System is installed and unsupported planets are found, the game will crash. This means that you must remove them from the RSS Planets & Moons.cfg file, as well as remove their respective folders. You should probably remove their textures too, to reduce memory usage.

Status update: Bourbaki is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Please bear in mind that the channel operators may be away from keyboard, so you should wait until you're noticed (it also helps to say the name of the channel operators since that pings them). As of 2015-08-16T15:38Z, the build for Win32 is ready, we're waiting for Norgg and armed_troop for the Linux and Macintosh builds respectively. Note that you should read the FAQ before installing principia. Rough changelog: Reimplemented integrators: the symplectic Runge-Kutta-Nyström integrator was reimplemented more cleanly, an embedded explicit Runge-Kutta-Nyström integrator was implemented. Abstractions for differential equations were created. Ephemeris: the celestial bodies are integrated on their own, with their own (much larger) timestep (45 min); their trajectories are then fitted using çõñышёò series, yielding continuous trajectories. This means that when there are no vessels (including asteroids, see the FAQ), timewarp at very high speed (6'000'000x was tested in RSS) is smooth. The predictions are computed using an adaptive step size, so they're faster and less fiddly (you still get a tolerance setting, but it doesn't need as much attention as the step size setting; the step size will shorten near periapsis and lengthen near apoapsis on its own). The histories are still in fixed steps of 10 s, that will likely change in Brouwer, since it is one of the biggest performance costs now. There is an initial configuration for Real Solar System: the planets will start in the right places as given by the JPL HORIZONS service, and they are given gravity models using the freshest data available (Vesta's model is from Dawn data, some Cassini data gets used). Please note the RSS-specific recommendations in the FAQ. A side effect of that is that the moon becomes far more accurate: since the motion of the moon is very much a 3-body problem, it cannot be accurately represented in RSS alone. In particular, real-life eclipses can be observed in principia + RSS (please note the unexpected inaccuracy mentioned in the FAQ). This initial configuration also includes J2 for the Sun, the planets, the Moon, and Vesta, so the resulting effects are felt (precession of Earth orbits, the possibility of heliosynchronous orbits, etc.). Bourbaki is save-compatible with Borel, for RSS users, please note that unless you reset the plugin, the new initial state and gravity model configuration files will not be taken into account.