For the new moon lunation number , the new release Chasles is out. A long-standing bug, , initially reported by maccollo , and also reported by Cristi , DaMichel , goldstarstickergiver , lyttol , nanomage , Parafaragarmus , rsparkyc , et al.
This bug prevented landing on peaks of some bodies notably Minmus as well as on the Moon in the current version 12 of RealSolarSystem. The fix involves making Principia handle vessels even when KSP's physics operate in a rotating reference frame, all the way down to the ground; as soon as a Kerbal jumps on Minmus, Principia computes its trajectory.
Note that vessels within an atmosphere are unaffected; we intend to also handle these down to the ground, but this requires an update in ferram4 's FAR since we want to remain FAR -compatible. Further, Principia now supports KSP 1. See the change log for details. The histories of the vessels are now computed in parallel, speeding up high timewarp on multi-core processors. A bug was fixed that caused a crash when crashing two vessels into each other.
The speed of the plotting of histories has been improved by about an order of magnitude. The slow plotting in previous versions was responsible for most of the slowdown in map view.
Further, the predictions are now plotted smoothly even when they are integrated with a large tolerance. The flight plan now supports burns that guide themselves to follow the Frenet trihedron, e. Select "Inertially fixed" in the flight planner to use an unguided burn instead, e. For the first time, Principia supports two versions of KSP: downloads are available for 1. A couple of bugs reported by panourgue and scimas were fixed.
Note to RSS users: Principia correctly simulates the motion of the moon, so the eclipse occurs as expected when using Principia, even after more than 66 years of numerical integreation, see below. Conversely, without Principia, the Moon's motion cannot be simulated with the requisite accuracy to get correct eclipses, since it is a heavily perturbed orbit.
For the new moon, the new release Cayley is out. It brings trajectories in map view, an update reminder driven by the Moon, a fix to a whole class of off-by-one physics bugs, and further bugfixes. Further, the build includes a binary for Macintosh, thanks to Jim DiGriz.
Note that the version string on Macintosh will mention Cayley-4 instead of Cayley This will be resolved in future versions. For the new moon lunation number , the new release, Cauchy , is out.
It brings relative speed markers on nodes, the unification of navball speed mode and reference frame selection, and displaying the trajectory of the target vessel if it moves in the plotting frame. This addresses requests by lawndart , maccollo , and scimas. NOTE: due to a forum mishap stares at technicalfool this thread has changed address, and all followers have been lost; if you had bookmarked the thread or followed it, you may want to do so again.
For the new moon lunation number , the new release, Catalan , is out. It brings no new features, but fixes a number of bugs and improves the underlying libraries. For the new moon lunation number , the new release, Cartan , is out, bringing with it a utility for rendezvous: the target local vertical local horizontal reference frame.
There is a guide to low orbit rendezvous using the new reference frames screenshots to be added in the near future. Please read the concepts page carefully, it has been expanded since Cardano. Remember to also have a look at the FAQ if you have a question. Thanks again to Iskierka for testing the Linux build. For the new moon lunation number , the new release, Cardano , is out, bringing with it axial tilt, new reference frames, and timewarp-independent free fall.
It marks the beginning of lunar releases. In particular, note that Cardano is save-incompatible with Cantor. Please read the concepts page carefully, it has been expanded since Cantor. Thanks to Iskierka for testing the Linux build. In the meantime, progress has been ongoing note that this is about a future release, Cantor contains none of the features below.
This allows us to specify dates more cleanly in our tests. We tested the difference between the orbits of Mercury predicted by our ephemeris and by JPL's over a century, and we find the expected error in perihelion precession due to general relativity.
On the side of flashier features, we seem to be well underway to having working axial tilt, by tilting universe the current main body with terrain is aligned with the axis used by KSP, and rotating the other ScaledSpace models appropriately; in a future release of Principia, the Jupiter, Saturn, and Uranus systems should look much nicer, with the planet properly aligned with its satellites.
A change log can be found here. Burnside is out. There is a bug in Buffon Buffongd0cb0e4b0ba84cafcfe0c that causes a crash when starting a new save with RSS loading an existing save works fine. 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 , , , 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. Great work. Every time I've tried to do that, my flight planner crashes the game because I plotted a trajectory that intersects earth.
One thing that will crash it is if your trajectory history becomes less than the starting point of your flight plan. For more details see all 19 pull requests between Brouwer and Buffon. Some clarifications regarding reference frames and flight planning. For more details, see all pull requests between Bourbaki and Brouwer. 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.
Note that you should read the FAQ before installing principia. 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.
The new version, Borel , is out you can get it on IRC, as previously; the same caveats apply. With Windows bit, Linux bit and Macintosh bit, we should be covering most users I don't think it's worth doing a Linux bit build.
Serialization has been implemented , and rudimentary predictions have been added. I am currently implementing as many symplectic integrators as I can find in order to compare them, and I will also be comparing various splittings as as nonsymplectic methods in use for computing ephemerides.
I will probably write a post about these at some point probably an advanced one, rather than an elementary introduction, this is quite a complicated topic. It seems that there is some interest in builds of Principia, no matter how unstable or slow they may be. The refactoring of the physics bubble has been done and some tests have been added , as well as some cleanup in the C adapter including some performance improvements, a lot of the performance issues occur on the C side since the implementation is a bit careless there.
The next step on the path towards playability is persistence: the state of the plugin must be persisted so that we remember the states of the planets, the histories of the vessel trajectories, etc. Persistence of our types will be achieved using protocol buffers , stored in config nodes: we don't want to use KSP's config format directly, since we have lots of highly structured data and operate far from KSP's API it would be inefficient and clumsy.
We'll probably also use protobufs for caching when implementing trajectory predictions later on. Some work has already been done in that direction. Here are some more screenshots, showing a flight from Kerbin to the Kerbin-Mun L4 Lagrange point the reference frame for each screenshot is indicated in the "Traces of various description" window. Support for intrinsic acceleration has been added.
In the first image, the trajectory of the vessel is displayed in the nonrotating reference frame centred on the Mun, in the second it is displayed in the nonrotating reference frame centred on Kerbin, and in all subsequent images it is displayed in the barycentric corotating reference frame of the Kerbin-Mun system.
Code has been written to plot the trajectories in nonrotating body-centred reference frames and barycentric corotating, not reviewed yet. While abstractions will have to be written to do that more cleanly and efficiently, this yields some pretty pictures. Caveat lector : While some of the following orbits may look very wild, bear in mind they are in non-inertial reference frames. Two of these wilder trajectories are followed by the same trajectory in a more pedestrian reference frame.
In the Kerbin-centric non-rotating reference frame, they would all look like two or three elliptic orbits connected by strange segments. The last picture below in the barycentric corotating frame of the Kerbin-Mun system, that is, the unique frame in which the Kerbin-Mun barycentre as well as the line through Kerbin and the Mun are invariant shows a trajectory that differs strongly from what stock KSP would have yielded: in stock this would have been a circular orbit around the Mun near the edge of its SoI.
Instead it is a transfer to an eccentric Kerbin orbit, which is picked up by the Mun again after a while and ends with a crash on the Mun. After the abstractions for plotting are written we will add the remaining interesting reference frames in the process , the next step will be to take care of altering the trajectory when, e. Trajectory, an abstraction for a tree of trajectories that can be forked into child alternatives useful i. The plugin has returned, first as a simple orbit-freezing plugin , then as a plugin that actually integrates the motion of vessels only on-rails for the moment.
Is does not plot yet, so it is still behind the C prototype in terms of features, but it is significantly faster. It should be noted that the plugin uses glog everywhere for logging since logging from native code is needed. I have been informed by Sarbian et alii that this will result in Fun support. I wrote the second explanatory post, on Hamiltonian mechanics PDF.
Prerequisites are chapters 4, 8, and sections and of Richard Feynman's Lectures on Physics. A significant change of plans has occured: As Unity uses the. NET Framework v2.
This means there will be separate x86 and AMD64 builds for each target operating system Microsoft Windows and 57 varieties of Unix , possibly more if we decide to do specific optimisations for Intel chips though ICC is not cheap. Moreover, this will allow a switch to clang in the near future, so that we can have saner error messages and better compliance with the standard.
This means the code gets reviewed and that development is faster. We have started switching to gmock, gtest and glog for mocking, testing and logging.
These tools are more convenient and powerful than the Visual Studio testing framework and are open source, so that users of Visual Studio Express which does not support Microsoft's testing framework will be able to build and run tests if they want to.
The Geometry assembly seems to be mostly feature complete, so I'll start writing tests tomorrow Saturday after changing a few access modifiers, replacing the ugly switch statements in Permutation by something nicer, and a few optimisations. See here for an overview of its features. NET can be used, but wrappers in one of the above languages are needed due to its case-insensitivity. Unity does not support mixed-mode DLLs, so calls to native code have to be made using DllImports in one of the above languages.
I have started doing some refactoring since the sphaghettiness of the code was getting on my nerves. I have written strongly typed wrappers for the numerous reference frames spawned by KSP direct vs. Of course, since KSP has the brilliant idea of using both direct and indirect reference frames, I needed distinct types for vectors, bivectors and trivectors basically I had to strongly type Grassmann algebras; there can be no cross product, only wedge products, commutators and left and right actions of alternating formswhere is identified with through the inner product, and is identified with.
It turns out I have trouble properly setting the position when off-rails finding out where the reference frame actually is is hard. However, there are some nicer news: I seem to have found the source of the phantom acceleration bias not the ones arising from rotation, the bias that is removed by timewarping. The floating origin sometimes floats several km away from the ship, so that's probably just floating-point inaccuracies the usual Kraken.
If that hypothesis turns out to be true, this particular acceleration bias will be easy to fix, just reset the floating origin often enough. I have successfully implemented the integration of proper acceleration for the active vessel when off-rails. Extensive experimentation has failed to yield a better velocity, so we are stuck with computing the proper acceleration from the rather mysterious Vessel.
For instance, one finds the proper acceleration is strongly correlated with the rotation rate of the ship.
Smarter post-processing will be needed. I have tried not only to explain how Runge-Kutta methods work this can easily be found on Wikipedia but why they have this structure.
I fixed a bug or two since , added a few TODOs, but have not cleaned up the code to any measurable extent. Caveat Compilator : As previously stated, this is just a proof of concept with a bunch of traces. Pressing the wrong buttons in the wrong order will result in lots of NullReferenceExceptions and off-rails crafts will behave weirdly. Using HyperEdit to set up initial conditions, then switching to Newtonian physics and fooling around with reference frames can be entertaining though.
The 'Simulator' project probably won't compile, it's leftover from my Alternis Kerbol simulations. It's not needed. This is currently hardly more than a proof of concept.
The simulation only affects on-rails vessels, thrust is ignored thus you can't actually play while the simulation is running and the integrator is too slow. However, it shows a few interesting things:. Expect a slow development cycle, due to a combination of laziness, exams, and this actually being a complicated project.
I'll put the source on GitHub as soon as I can clean things up a bit there are quite a few traces that were too hastily implemented for my taste. This might take a few days, see above. Therefore, before using the mod we recommend that you read the concepts document which explains the most important parts of Principia.
In particular, you should learn about the plotting frame and flight planning. You might also want to go through our tutorial which shows how to go to the Mun with Principia in an energy-efficient manner. We also have a guide explaining how to use the support for rendezvous. The FAQ explain how to install, how to report bugs and documents the known issues and limitations.
The change log gives a fairly detailed description of the new features in each release. Principia is released on every new moon with whatever features and bug fixes are ready at the time. This ensures relatively timely improvements and bug fixes.
Download the binary Ubuntu, macOS, and Windows here for 1. Or, if you don't trust our binary, build the mod from the Halley release. You might also want to go through our tutorial which shows how to go to the Mun with Principia in an energy-efficient manner. We also have a guide explaining how to use the support for rendezvous.
The FAQ explain how to install, how to report bugs and documents the known issues and limitations. The change log gives a fairly detailed description of the new features in each release. Principia is released on every new moon with whatever features and bug fixes are ready at the time. This ensures relatively timely improvements and bug fixes. Download the binary Ubuntu, macOS, and Windows here for 1. Or, if you don't trust our binary, build the mod from the Halley release. Skip to content.
0コメント