eggrobin
-
Posts
504 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by eggrobin
-
-
56 minutes ago, theleg said:
This is the bug I am facing. The burn indicator doesn't decrease the delta v required for the maneuver. Is there a fix? Please help...
And which tutorials would you recommend me to learn principia from? I did a fly-by with mun just by the tutorial above, but I don't think this is too much of an in-depth guide...
This is not a bug, this is how Principia manœuvre execution works: see https://github.com/mockingbirdnest/Principia/wiki/Concepts#flight-planning-user-interface.
QuoteNote that, unlike stock KSP, the Δv counter next to the navball doesn't count down as you burn, and the manœuvre marker does not move. This is because that countdown is only useful as guidance for burns that are modelled as instantaneous (as in stock KSP), but in Principia burns are applied continuously. In order to execute a manœuvre you have to either take a look at the times in the flight plan editor (a countdown to ignition is provided, followed by a countdown to cut-off), or take a look at the shape of the prediction (which should change to become similar to the flight plan) and control your burn accordingly.
With Principia, manœuvre execution is either closed-loop by hand (look at map view, cut the engine when the trajectory does what you want), or open-loop based on the countdowns given in the flight plan (this latter approach is hampered by spool-up times in RO though, so it is better to keep an eye on map view).
Note that MechJeb has an implementation of the timing-based approach (an « Execute next Principia node » button) since around the time of Fuchs (May 2020).
QuoteAnd which tutorials would you recommend me to learn principia from? I did a fly-by with mun just by the tutorial above, but I don't think this is too much of an in-depth guide...
I don’t think we have much in the way of guides beyond what is on the wiki and the odd video. On the other hand, you may wish to ask questions on the Discord/IRC/matrix channel listed in the OP, there is a fairly active community there.
-
For the new moon (lunation number 265), the new release (Gröbner) is out.
It addresses one part of #2400, namely the lag on scene change far from 1951 in the absence of vessels. This means that @scimas’s custom initial states are no longer needed for late-starting games.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
On 6/2/2021 at 6:01 PM, Xurkitree said:Is there any way to extract Keplerian orbital elements from principia orbits at a particular time? I'm hoping to try out something and I'd like to know whether this is possible.
It depends what you mean by « Keplerian orbital elements » (and possibly on what you mean by « extract »), which in turns depends on what « something » is. In this perturbed Keplerian context, there are many kinds of elements, suitable for various applications.
In a lot of cases you care about mean elements. These encompass many definitions, but the concept is « elements that smooth out the perturbations that are on the scale of one revolution », so as to tell you something meaningful about the whole orbit around a given time ; they will still change over time (in particular you will encounter nodal and apsidal precession). The orbit analyser gives you mean elements.
Osculating elements do not really tell you meaningful things about the overall orbit, since they change significantly along the orbit; they are primarily useful as a way to express the exact position and velocity at the current time, for systems that prefer that to cartesian coordinates. KSP handles osculating elements, so this is what is surfaced in the stock UI, and in other mods (MechJeb, KJR, etc.).
-
For the new moon (lunation number 264), the new release (Green) is out, fixing a few bugs (two crashes and a temporary but potentially very long freeze).
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
3 hours ago, pipai said:
Principia seriously lags while the Principia window is open during landing. This also affects Kerbals walking on the surface.
This sounds like a symptom of the same issue as https://github.com/mockingbirdnest/Principia/issues/2957 and https://github.com/mockingbirdnest/Principia/issues/2953; it should be fixed in the next version, Green.
The Principia window spawns an asynchronous orbit analyser (this is used to give you a short description of orbit you are currently in, e.g., « circular semisynchronous Kerbin orbit » or something around those lines). This is not new, and is not a performance problem in itself (it runs fairly rarely and does so in the background). When the vessel lands, it becomes « unmanageable » by Principia, and all Principia-side state is destroyed. Due to a bug in our handling of the interruption of a numerical integration, the destruction of a running analyser is very slow, especially since Grassmann. This explains lag on landing. A walking Kerbal just keeps landing and taking off.
-
1 minute ago, DanDucky said:
should I re-record with the ui open?
That might be slightly less useless; please also film a launch that doesn’t crash, so that we can actually see a transition to lower lag in space (without an intervening scene change), and figure out if it is correlated with something on the Principia side.
-
For the new moon (lunation number 263), the new release (Grassmann) is out.
- Support for KSP 1.11.2 has been added.
- The mechanism for overriding the version check so as to try new versions before we support them has been documented. Note that no support will be provided when this override is used.
- Some strings were untranslated in the Chinese version; this has been fixed. Thanks to @WC12366 for this contribution.
- A bug leading to steadily increasing memory usage up to crashing out of memory (#2919), reported by @Al2Me6 and @hxl11211, has been fixed.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
For the new moon (lunation number 262), the new release (Goldbach) is out.
- Performance has been significantly improved, especially on macOS. Thanks to @rnlahaye for this significant contribution.
- A bug found by @Robot_V1, which affected the handling of some aircraft, was fixed.
- The Chinese localization was improved.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
Calling Part.Add(Torque|Force(AtPosition)?) is the only way for a mod to apply a net force to a vessel in the presence of Principia.
Calls to RigidBody.Add(Torque|Force(AtPosition)?) will have no net effect on the vessel (though they may deform it).
Mods that use RigidBody.Add(Torque|Force(AtPosition)?) are Principia-incompatible.
-
For the new moon (lunation number 261), the new release (Gödel) is out.
- Support for KSP 1.11.1 has been added.
- Principia is localized in simplified Chinese. Thanks to @CindyRIng for this significant contribution, and to @Zaikarion for helping with linguistic questions.
- Some crash-inducing bugs have been fixed.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
18 minutes ago, AccidentalColonies said:
If you want to be able to push farther, you'll have to make a new node right after that goes prograde
or use an inertially fixed manœuvre, which will use the initial Frenet frame throughout the burn.
-
18 minutes ago, R-T-B said:
Also not questioning the concept, but how do your zips work? They don't seem to be a "platform dependent installer" at all.
They are not, which is why the installation process requires installing the right system dependencies metioned (and, for Windows, linked to) in the FAQ.
-
2 hours ago, R-T-B said:
What is Principia's policy on bundling your mod builds with another planet pack that basically depends on it? Is that considered an ok practice? Or do you prefer me to point users to your page? (and deal with the inevitable "helpmes" when they fail to install it?).
Please don’t bundle Principia. Instead direct users to the README.md page on GitHub.
There are several reasons for that:
- Principia has its own (system-level and platform-specific) dependencies, which you cannot bundle without a platform-dependent installer: if Principia is provided in a bundle, it will simply not work out of the box;
- we want users to know where the concepts & FAQ pages can be found, as well as the specific bug reporting procedures, and the readme will tell them about that—Principia is complicated enough that if users get it as part of a bundle, there will be an enormous amount of confusion (for instance when it come to plotting frames) that will require support from your part or ours;
- we very much prefer that users upgrade in a timely manner, which is much harder to do for a bundle that may or may not track our releases closely, especially in the longer term—few mods are updated every new moon for years;
- we like to track usage and analytics of the mod, and, again, that’s impossible through a bundle;
- we would like new users to be able to find the existing community of Principia users (on IRC, discord, this thread, etc.), so that their questions may be answered by more experienced users rather than us.
-
For the new moon (lunation number 260), the new release (Germain) is out.
- Support for KSP 1.11.0 has been added.
- The orbital analysis of the final trajectory is now available in the flight plan, making it possible to plan accurate orbital insertions and corrections.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
A notice to all Principia users: DO NOT use the « fix » provided in the above post.
@100055 you have completely misunderstood how the axial tilt configuration works, and therefore your so-called fix is incorrect. All orientations of the planetary axes are given by right ascensions and declinations in the International Celestial Reference System (ICRS), whose reference plane is the mean equator of the Earth at the standard epoch J2000; in particular, this means that the axis of the Earth has a declination of 90°.
This is the convention used by the International Astronomical Union, and specifically by its Working Group on Cartographic Coordinates and Rotational Elements.
Our use of these conventions is documented.
It is also evident by looking at your « fix » that you do not understand how the Principia initial state configuration works: you patch the Kopernicus orbits, whereas those are completely ignored in the presence of the initial state file. If this part of your patch has any effect at all, it means you improperly installed Principia or RSS.
The initial positions and velocities of the planets, given in the sol_initial_state_jd_2433282_500000000.cfg file, are in the ICRS.
Having axis orientations given in a reference frame different from the positions and velocities of the bodies means, obviously, that the orientation of the axes with respect to the solar system will be incorrect.
Nothing should be relative to the ecliptic, everything should be in the ICRS. Indeed, to quote Nicole Capitaine,
Quote(i) no ecliptic is needed for the realization of the reference systems currently used in astronomy, (ii) the ecliptic is no more needed as a reference for the astronomical coordinates, (iii) the modern numerical barycentric ephemerides are referred to the ICRF, (iv) the modern description of precession-nutation of the equator is the motion of the CIP in the GCRS without reference to the ecliptic, (v) numerical integration, as well as modern semi-analytical integration, of precession-nutation do not use an ecliptic.
As a side note
QuoteBy default RSS tilts the ecliptic by 23.4 degrees in order to simulate Earth's axial tilt, which made the tilts of all other bodies incorrect. Since Principia implements axial tilt, there is no reason to do that anymore
You also do not understand how Principia implements axial tilt: Principia does the exact same thing as RSS, except with respect to the current main body, so Principia will always tilt the universe so that the current main body is horizontal. This is, however, invisible with Principia, because we then tilt the camera according to the currently-selected reference plane. If you play with the reference frame selection (e.g., switching between Earth-Centred Inertial and Sun-Earth Barycentric), you will notice that your view is differently-oriented.
Don’t try to fix things that you don’t understand, you are doing a disservice to everyone. If for some reason your game is showing you things that you don’t expect, ask about it ; maybe you don’t understand what you are seeing, maybe your install is misconfigured. What is definitely not the case is that a configuration used by hundreds of people, with which they have accurately replicated astronomical events dependent on axial tilt, is wrong in such an egregious manner.
-
For the new moon (lunation number 259), which is a total eclipse, the new release (Гельфонд) is out.
- The orbit analyser now provides a short description of the current orbit, e.g., “highly eccentric semisynch. Earth orbit”.
- The trajectory colours can now be configured, thanks to a contribution from @Flibble (#2816).
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
For the new moon (lunation number 258), the new release (Гельфанд) is out.
Performance of operations based on iteration over trajectories has been improved thanks to a contribution from @rnlahaye.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
[Note: this was clarified over Discord; answering the questions asked here for posterity]
6 hours ago, WarriorSabe said:I'm currently testing long-term stability of my system in Principia after preliminary success in US2, and I'm getting spammed with "apocalypse occured" errors, all on the exact same body, which hasn't deviated from its orbit at all in at least 1700 years. The first error occurs only a couple months in, and there seems to be a little over one a year.
What exactly does this mean?
Your system is either unstable, or doing things too quickly for the default integration settings (« unstable » is just a special case of that, where close encounters happen too quickly; Principia doesn’t (yet) care about orbits nor whether things remain on them). US2 tends to be an unreliable predictor of what happens to a solar system with Principia (probably because of different conventions for the representation of the initial state, possibly of its choice of numerical methods and timesteps ).
QuoteIs it just a side effect of running at a very high timestep
Time warp does not affect the time step used by the integrator (this is why max time warp can be slow with Principia).
Quotewith a GPU and CPU that aren't really all that great?
Nor do your system settings matter for anything but performance.
You may want to look at https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files#the-principia_numerics_blueprint-configuration and https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files#annex-choosing-a-fixed-step-size-integrator.
-
For the new moon (lunation number 257), the new release (Gauss) is out.
- A bug that would occasionally lead to crashes when parts exploded has been fixed (#2716).
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
For the new moon (lunation number 256), the new release (Gateaux) is out.
- Support for 1.10.1 has been added. Note that the behaviour of Principia in the presence of comets is hard to test; users who encounter problems when comets are present are invited to report bugs.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
On 8/25/2020 at 3:06 PM, epicfailure2020 said:
im playing with RSS and RO
47 minutes ago, epicfailure2020 said:Eeloo
If we look for a gravity model for Eeloo, this means Eeloo is present. If Eeloo is present with RSS, this means RSS is improperly installed.
-
For the new moon (lunation number 255), the new release (Galois) is out.
- It is now possible to insert and delete manœuvres in the flight plan; in particular, this makes it possible to insert correction manœuvres after rebasing.
- Manœuvres can be collapsed and expanded, making it easier to manage flight plans with many manœuvres.
- A bug involving incorrect thrust when planning RCS manœuvres was fixed. Thanks to @Flibble for contributing this fix.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
On 7/22/2020 at 7:50 PM, décepteur said:
So my question is : is the lack of tidal locking a result of my own misunderstanding of moduleManager, or is it a limitation of Principia itself ?
The stock tidal locking flag never really works in the presence of Principia, and leads to aberrant spin and de-spin; Principia thus always disables it.
It should be noted that, in a non-Keplerian world, finding the correct rotation period for tidal locking is tricky. As you have seen in the orbit analyser, satellites have three different orbital periods, none of which are equal to the osculating period (the period of the stock Kepler orbit at a given instant), and the same holds for a celestial body.
Since we do not model pressions of the axes at this time (the rotation axis is fixed in space), you want to use the sidereal period of the body as its rotation period.
Computing that period may prove to be a challenge, as the orbit analyser does not currently work for celestial bodies.
-
For the new moon (lunation number 254), the new release (Gallai) is out.
- As previously announced, this release dose not support KSP 1.7.3 and earlier.
- A rebase button has been added to the flight plan, to take changes to the actual trajectory into account without having to recreate the flight plan.
- Altitude-related information has been added to the orbit analyser.
- A number of bugs have been addressed: EVA collision leading to absurd movement, EVA parachutes being broken, vessels disintegrating at absurd speeds, vessels deforming when coming out of warp.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
-
@pleroy and I are the authors. This is not our job, no managers are involved (except of course for @sarbian’s ModuleManager).
5 hours ago, MAFman said:it needs to be updated
As for your remark, there is a new Principia release every new moon; whether the mod needs to be updated or not is entirely irrelevant to that schedule.
I think with that needs you are alluding to 1.10 support; even when things go smoothly, it often takes several Principia releases before we support a new KSP version, just to check that everything is fine with the new version.
Here things may not be completely smooth, as, depending on how they were implemented, correctly handling the comets may require a lot of work.
[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version Καραθεοδωρή, released 2024-04-08—n-Body and Extended Body Gravitation
in KSP1 Mod Development
Posted
For the new moon (lunation number 266), the new release (Grossmann) is out, fixing a couple of bugs reported by @Flibble and @Al2Me6.
See the change log for more details.
For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.