[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[pleroy]

5 hours ago, Abstract_Kerman said:

Can I smash gilly into Kerbin by attaching rocket engines to it, since it's not on rails.

No, engines don't have any effect on planets in Principia.  Only planets have an effect on planets, it's a useful optimization to speed up the computations.  But even if the mod allowed it, as explained by Scott Manley, there is no way that you can use engines and tanks to move a planet.

4 hours ago, Galacticvoyager said:

I heard this mod allows planets to have an axial tilt... Has anyone of you got evidence of this...

Yes, it does, it was one of the major improvements in Cardano.  From the change log:

Quote

 

Celestials may now have proper axial tilt and rotation. This is particularly useful when using RealSolarSystem. For instance, the rings of Saturn are (correctly) shown in the same plane as its satellites. Previously they would show up as being in the plane of Earth's equator, at an angle from the satellites. Similarly the lightning of the Earth correctly reflects the seasons.

 

 

[Planetace]

51 minutes ago, pleroy said:

Yes, it does, it was one of the major improvements in Cardano.  From the change log:

Soooo... How do you program it to you're planets? Like make it so that there is major axial tilt...

[msnbcorp]

On 25/04/2017 at 9:30 PM, GrahamsNumber said:

I guess that is possible (I mean, who cares about which planet it's orbiting?). But I doubt that this would solve the problem. Sarnus (equivalent of Saturn) has a lot of moons, and these are not necessarily stable either. I'm guessing there would be a way to find a region of stability, but as pleroy mentioned above, it's not easy and would take a lot of work. If we want a stable, bigger solar system, I guess that means waiting until RO and FAR are out of beta. (For those interested: Yes, if you are determined, you can get Real Solar System, Realism Overhaul, FAR, and a whole bunch of other mods working in 1.2.2. But, fair warning: it is a pain in the neck, since you can't use CKAN, sometimes you need to build the mod yourself from the source code, run Perl scripts and in general have to live with some bugs until these are ironed out). Personally, I would love to help in the development, but I think my programming skills are pretty amateurish

Don't understand that post.

Why, in your scenario we can't use CKAN ?

[GrahamsNumber]

11 hours ago, msnbcorp said:

Don't understand that post.

Why, in your scenario we can't use CKAN ?

Try finding the dev version of FAR on CKAN for 1.2.2. Try finding Realism Overhaul. Try finding Infernal Robotics. Try finding all the many mods that are almost a requirement for RSS. You'll see the problem.

[msnbcorp]

Hum i see, but you can install via CKAN the large mass of mod and leeave to manual install the rest no ?

Beside, don't see why realism overhaul is important for RSS XD or even infernal robotics ...

[GrahamsNumber]

On 5/17/2017 at 5:22 PM, msnbcorp said:

Beside, don't see why realism overhaul is important for RSS XD or even infernal robotics ...

To put it simply: Kerbin is smaller (a lot smaller) than earth. In fact, it is smaller than our own real life Moon (!!). Just google "comparison size Kerbin earth", and you'll see just how strongly scaled everything is.

In addition, all the celestial objects are ludicrously close, compared to real life. Now, why would this matter, you wonder? Because RSS rescales all the planets and solar system to its real size, which means: If you have a rocket that gets you from Kerbin to Mun, and you try the same from Earth to the Moon, it will never succeed (actually, I think you would not even reach orbit). In particular, fuel to weight ratios in KSP stock are not the same as in real life. Playing RSS without any other mods is possible, but a pain in the neck. That's where RO comes in. Together with it, the rocket designs you build in KSP actually get remarkably similar to real life designs (given that KSP is an awesome, but very crude approximation to how complex real space travel is).

[eggrobin]

For the new moon (lunation number 215), the new release, Catalan, is out. It brings no new features, but fixes a number of bugs and improves the underlying libraries.

See the change log for details.

[eggrobin]

IMPORTANT NOTE:

If you downloaded Catalan before the time of this post, you may have ended up with a defective version that will crash when creating a new RSS save. To fix, simply re-download Catalan.

[lawndart]

A request:

Would it be possible to use the <body> Centred, <body> Fixed frame of reference as a default for vessels launching from the surface?

When the navball switches to Orbital during ascent it defaults to <body> Centred Inertial. This is all well and good for real-life computerized launches ( I know the Shuttles switched to inertial during ascent ) but most Kerbal launches are the familiar manual fin and engine waggling ascents and the horizon line on the KCKF Orbital navball is really useful for guiding rockets into a near circular orbit. It's just another thing to remember to switch over before launch and must cause considerable confusion for people new to the mod when everything goes Right Ascension.

 

 

[Bocian]

Anyone else have this bug:

When quickload to situation in atmospheric fligth, the vesel speed increasing by planet surface rotation speed.
eg. flight 100m/s, quicksave....qiuckload.. now your speed is 300m/s. You can repeat this until you reach extreeme speed.
KSP 1.2.2, Principia Catalan, clean install

[pleroy]

4 hours ago, Bocian said:

When quickload to situation in atmospheric fligth, the vesel speed increasing by planet surface rotation speed.
eg. flight 100m/s, quicksave....qiuckload.. now your speed is 300m/s. You can repeat this until you reach extreeme speed.
KSP 1.2.2, Principia Catalan, clean install

Thanks for the report.  This rings a bell, @eggrobin had seen it in a video by Scott Manley.  Created issue 1404 to track this.

[lawndart]

Confirmed. On quickload the vessel's horizontal velocity is increased. If you are going straight up when you save the vessel rotates towards the 90 degree line as it compensates for the increase.

 

 

 

Edited May 27, 2017 by lawndart
Gibberish at the end

[pleroy]

On 5/26/2017 at 6:27 PM, lawndart said:

A request:

Would it be possible to use the <body> Centred, <body> Fixed frame of reference as a default for vessels launching from the surface?

Thanks for the suggestion.  In 1411 @eggrobin has unified the speed display mode and the selection of the reference frame, which should make things much more natural.

[lawndart]

Thanks to both of you modders.

[scimas]

Ships also keep jumping altitude and position when timewarping. Its not really noticeable with just one ship, but when you're trying to rendezvous, the jumps are of around 100 m. The ships also jump distance and speeds when you EVA. Its like I park 2 vessels for rescue mission, switch ship, EVA and suddenly my rescue craft is 150 m (made up number, but its around that) farther than it should be and moving too when it shouldn't be.

It would be really nice if you could add inclination value to the ascending and descending nodes. Right now we have to rotate the camera perfectly to make sure the orbits have aligned, there is simply no quantitative display. Or is it not possible for some reason? And if its not possible, could you plot the target ship's trajectory? Even the patched conics version helps with timing / positioning of the burn.

And what @lawndart said about surface fixed reference frame for launch.

I'm using stock game, not RSS, if thats relevant to bug fixing.

Thanks for the great mod btw, been using it for past 2 weeks or so and enjoying it very much!

[eggrobin]

4 hours ago, scimas said:

Ships also keep jumping altitude and position when timewarping. Its not really noticeable with just one ship, but when you're trying to rendezvous, the jumps are of around 100 m. The ships also jump distance and speeds when you EVA. Its like I park 2 vessels for rescue mission, switch ship, EVA and suddenly my rescue craft is 150 m (made up number, but its around that) farther than it should be and moving too when it shouldn't be.

I have not observed this, do you know whether it is a bug that was introduced recently? Any detailed reproduction instructions?

Quote

It would be really nice if you could add inclination value to the ascending and descending nodes. Right now we have to rotate the camera perfectly to make sure the orbits have aligned, there is simply no quantitative display. Or is it not possible for some reason?

The relative inclination is a feature of planar (Keplerian) trajectories in the body-centred non-rotating frame; it is tricky to turn that into something that makes sense for arbitrary trajectories. There is however something we can do, and have done in 1406, which will be in Cauchy: we can indicate the speed out-of-plane at the node (that is, the minimum Δv needed at that node to remain in the reference plane). I think this is an adequate substitute. In addition, 1406 will also show relative speed at target approach, as well as periapsis and apoapsis speed (in the selected frame, so surface speed at periapsis in KCKF, orbital speed at periapsis in KCI, and a speed for which stock KSP does not have a word in KCSA).

Quote

And if its not possible, could you plot the target ship's trajectory? Even the patched conics version helps with timing / positioning of the burn.

This does not really make sense: in the Local Vertical, Local Horizontal frame of the target, by definition the target does not move, so there is nothing to plot. We could plot both trajectories in a frame that's not target-centred (like stock that plots both in the KCI frame for Kerbin orbit rendez-vous), but we decided against it, because for more complicated orbits this would become utterly unreadable. Besides, the LVLH frame is the thing people actually use for rendez-vous:

As an example of using the LVLH frame to plan a rendez-vous with more complicated trajectories, see @maccollo's recent video; note that the initial transfer to the vicinity of a Lagrange point is planned in the MCKA frame, the LVLH frame is then used to rendez-vous:

 

Quote

And what @lawndart said about surface fixed reference frame for launch.

As @pleroy said above, the stock "Surface" speed mode will be fused with our "KCKF" reference frame in Cauchy; this should make switching between it and one of KCI, KCSA, SKB much easier.

On 5/28/2017 at 8:01 PM, pleroy said:

Thanks for the suggestion.  In 1411 @eggrobin has unified the speed display mode and the selection of the reference frame, which should make things much more natural.

 

[lawndart]

I have also seen the time-warp position jump when attempting rendez-vous, however I am running a heavily modded KSP so I wasn't too sure where the issue lay. The vessels jump back on restoration of 1:1 time. 

Might be related: I am also getting excessive supplies depletion in Tac Life Support when time warping and flying a ship in space, with the time remaining on the supplies clocks running down faster than the warp is accelerating the time. This does not happen when time warping at KSC,

I'll try and reproduce the jumping issue in Stock + Principa for you and create a save file.

 

5 hours ago, scimas said:

It would be really nice if you could add inclination value to the ascending and descending nodes. Right now we have to rotate the camera perfectly to make sure the orbits have aligned, there is simply no quantitative display. Or is it not possible for some reason? And if its not possible, could you plot the target ship's trajectory? Even the patched conics version helps with timing / positioning of the burn.

If you don't mind a mod that should be in the stock game anyway, Kerbal Engineering Redux can show relative inclination on screen, presumably because it's looking at the conics value. I use this for getting my alignments - seems to work so far. Pleroy and eggrobin will now tell me that KER is using inaccurate values and shouldn't be used  

As for plotting the target's trajectory, I find the Principa method more intuitive than the stock method once you get used to it.

[eggrobin]

3 minutes ago, lawndart said:

I have also seen the time-warp position jump when attempting rendez-vous, however I am running a heavily modded KSP so I wasn't too sure where the issue lay. The vessels jump back on restoration of 1:1 time. 

Might be related: I am also getting excessive supplies depletion in Tac Life Support when time warping and flying a ship in space, with the time remaining on the supplies clocks running down faster than the warp is accelerating the time. This does not happen when time warping at KSC,I'll try and reproduce the jumping issue in Stock + Principa for you and create a save file.

Interesting, thanks for your help.

Quote

If you don't mind a mod that should be in the stock game anyway, Kerbal Engineering Redux can show relative inclination on screen, presumably because it's looking at the conics value. I use this for getting my alignments - seems to work so far. Pleroy and eggrobin will now tell me that KER is using inaccurate values and shouldn't be used  

Admittedly until Cauchy it is the only indication you have of how badly out-of-plane your trajectory is; in Cauchy the out-of-plane speed indication should be more useful than the relative inclination.

[scimas]

2 minutes ago, lawndart said:

I have also seen the time-warp position jump when attempting rendez-vous ... The vessels jump back on restoration of 1:1 time.

...

I'll try and reproduce the jumping issue in Stock + Principa for you and create a save file.

Exactly, it happens when going to 1x time from any higher time warp. I'm creating a save file for that too.

4 minutes ago, lawndart said:

If you don't mind a mod that should be in the stock game anyway, Kerbal Engineering Redux can show relative inclination on screen, presumably because it's looking at the conics value. I use this for getting my alignments - seems to work so far. Pleroy and eggrobin will now tell me that KER is using inaccurate values and shouldn't be used  

I have KER installed too, don't know why I didn't think of using those values

4 minutes ago, lawndart said:

As for plotting the target's trajectory, I find the Principa method more intuitive than the stock method once you get used to it.

@eggrobin I got your point about the target reference frame. I guess we got our contexts mixed. What I was referring to was the early adjustments to the orbit; like my ship is in 80km circular orbit and my target is something like 5Mm x 3Mm orbit; having a target Ap and Pe visible helps in that case, right? Or am I wrong here too and the target frame takes care of it and I just have to figure it out? But anyway, the KER values should take care of that.

11 minutes ago, lawndart said:

however I am running a heavily modded KSP so I wasn't too sure where the issue lay.

I'm using ksp 1.2.2, KER and KAC. KER doesn't do any modifications to the orbit, so I guess its not a problem. KAC allows ship jumps, so that could be a cause, but I haven't checked that. Will try it if possible.

Also, if anyone can tell me how to share save file that would be helpful. I'm new to the forum and can't find any 'attach new file' button.

[lawndart]

Possible bug?

Stock + Catalan. I've been getting random loss of function while setting up a rendez-vous to cover the issue mentioned earlier. When switching between two vessels the switched-to vessel appears as normal but I am unable to access the map view, escape, load or time warp. All flight controls are working normally and so does the return to Space Centre button, fortunately. Dropping back to the menu and reloading doesn't help; the only recourse is to close KSP and restart. Also had this when I went from the Tracking Centre to a vessel that had its engine deactivated.

Can someone please confirm this is happening? 

[maccollo]

37 minutes ago, lawndart said:

Possible bug?

Stock + Catalan. I've been getting random loss of function while setting up a rendez-vous to cover the issue mentioned earlier. When switching between two vessels the switched-to vessel appears as normal but I am unable to access the map view, escape, load or time warp. All flight controls are working normally and so does the return to Space Centre button, fortunately. Dropping back to the menu and reloading doesn't help; the only recourse is to close KSP and restart. Also had this when I went from the Tracking Centre to a vessel that had its engine deactivated.

Can someone please confirm this is happening? 

It's a known issue that they have fixed for the next release. For now you can fix it by using the debug menu (Alt+F12) -> console -> input locks -> clear input locks.

[lawndart]

Excellent, thanks

 

[eggrobin]

9 hours ago, scimas said:

my ship is in 80km circular orbit and my target is something like 5Mm x 3Mm orbit; having a target Ap and Pe visible helps in that case, right? Or am I wrong here too and the target frame takes care of it and I just have to figure it out?

Hmm. I feel like it does, but then I can't think of a good way of handling that; I am somewhat reticent to also displaying the target trajectory... Certainly something we will not do is showing closest approaches if both trajectories are shown: we have decided that we only show apsides with respect to a body if that body is fixed, and we should do the same for vessels. On the other hand maybe it would make sense to show the trajectory of the target vessel without any approach or node markings (just apsis markings for both). We'll think about that; it's definitely not in the Cauchy timeframe though.

4 hours ago, maccollo said:

It's a known issue that they have fixed for the next release. For now you can fix it by using the debug menu (Alt+F12) -> console -> input locks -> clear input locks.

Specifically, 1402, fixed by 1403.

[GrahamsNumber]

Okay, so, quick question: How long will you guys support 1.2.2? Given that 1.3 (again) wiped out most of the mods (many of them crashing right now, see link below), I am hoping that 1.2.2 gets supported for a while longer, so we can enjoy the many mods that are available for it (including, finally, FAR!)

 

[Damien212]

Hi,

I'm having an odd issue with Principia that I can't seem to nail down.

While playing RSS/RO with Principia (latest releases as of today), during a mission similar to Explorer I (rocket booster stage, coast to apo, chained SRB to orbital velocity) the SRB stage was suffering from what looked like misaligned thrust, pulling the craft from orbital prograde, towards radial-out with reference to Earth. While trying to diagnose the problem I tried the following:

• Delete/Fresh install of KSP, with RSS, RO & dependancies as per CKAN latest. Also FASA for test craft. Principia as per latest on github. - no change
• Spin stablization of SRB stage - no effect. craft nose still pulled towards radial-out causing spin.
• Disabling/reenabling of RCS/SAS - no effect (not installed on craft anyway)
• SRB stage activated while pointing retrograde - no effect, nose still pulled towards radial-out causing spin.
• SRB stage activated while pointing radial-out - no alteration of vessel orientation, remains pointing radial-out
• Craft (FASA Juno/Explorer I craft file sergeant SRB stages as per github) replaced with alternate model to rule out FASA part issue - no effect, procedural parts SRB with a MK1 crew capsule on top exhibits same issues
• Noticed Moon was directly above launch site, timewarped Moon to other side of Earth before launch to rule out weird gravity effects from Moon - no effect.
• Force stopped Principia before stage ignition - issue eliminated, works as expected
• Force started Principia again before stage ignition - issue returns.

The only constant I can find regarding this issue is that it only occurs when thrust is applied out of atmo. At 139,999m everything works as normal, at 140,000m+ the problem appears. If you start a burn in atmo, and the burn continues across the boundary, the issue takes effect only from the moment the craft passes the boundary.

The craft I was testing has 3x SRB stages to push Explorer I into orbit. During the first burn towards orbital prograde, the craft noses upwards, towards radial-out and then towards orbital retrograde, putting it into an anticlockwise spin if viewed from south to north. If this was asymmetric thrust or a simple spin, you'd expect the spin to continue in the same direction if you ignited the second stage when pointing retrograde. This doesn't happen. Instead you can start the spin anticlockwise with stage 1 ignition when facing prograde, ignite stage 2 during the spin when at retrograde, which changes the direction of the spin to clockwise towards radial-out and prograde, then ignite stage 3 at prograde again to reverse direction. In all cases the craft spins towards radial-out during thrust.

 

I recorded several attempts at performing the maneuver as per the above list. The video is here: https://www.twitch.tv/videos/148710758

My KSP.log is here: https://www.dropbox.com/s/0tvzdx4spaw0lm7/KSP.log?dl=0

Any ideas?