[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

[eggrobin]

23 hours ago, scimas said:

I've been noticing a bug recently, but haven't been able to reproduce it on demand and so haven't opened an issue on github. I will detail it here, perhaps you can figure it out.

Sometimes, when I return to kerbin from space (the point where the calculation of the trajectory goes from principia to ksp), if I'm time warping, the orbit gets set to ~265000 m x ~63000 m. So I've just burned retrograde, the plotting frame set to kerbin surface fixed, the apoapsis and periapsis reported by both principia and kerbal engineer are around 80000m and 10000m, respectively. I start timewarping. The 70000m atmosphere encounter stops the time warp and suddenly my orbit is set to that weird one.

I tried to reproduce it multiple times with the same craft, but haven't been able to do it reliably. It happens randomly as far as I can tell.

We think this is the result of an interaction between 1416 and the fact that re-entering makes the vessel unmanageable for Principia. We do not understand 1416, however in the longer term we intend to manage vessels even at lower altitudes, which would solve this problem.

In the meantime, you can work around this bug by getting out of timewarp before reentry.

[pleroy]

21 hours ago, scimas said:

I also found another possible bug. I'm sending an orbital station to minmus, so it has a lot of parts. There are 3 crew capacity parts, the hitchiker storage, mobile processing lab and an mk1 lander module. If I EVA out of the mk1 lander module and then try to board the ship again, ksp is crashing. The principia logs are showing this:
[...]
I could give you the save file, but I don't know how to attach those here.

Please open an issue on github and attach your logs and save to that issue (maybe as a zip archive) just like you did for 1416.  It's just too hard for us to track bugs here on the forum.

[scimas]

1 hour ago, eggrobin said:

We think this is the result of an interaction between 1416 and the fact that re-entering makes the vessel unmanageable for Principia. We do not understand 1416, however in the longer term we intend to manage vessels even at lower altitudes, which would solve this problem.

In the meantime, you can work around this bug by getting out of timewarp before reentry.

Ah, I see. The change is too drastic though. In 1416 I haven't noticed any deviation of more than 500m, here its going in the order of hundred thousand meters.

1 hour ago, pleroy said:

Please open an issue on github and attach your logs and save to that issue (maybe as a zip archive) just like you did for 1416.  It's just too hard for us to track bugs here on the forum.

Done!

 

Looking forward to the cauchy build, the improvements and bug fixes in the change log look exciting!

[tater]

Got the Mac version going. Awesome!

[TheRagingIrishman]

5 hours ago, tater said:

Got the Mac version going. Awesome!

Macster Race unite! 

Edited June 19, 2017 by TheRagingIrishman

[tater]

All sorts of fun stuff I want to play with. I really need to use a rescale though, since then doing ballistic captures, etc will actually mean something (it's nearly impossible not to make stock craft that are not grossly OP).

[eggrobin]

For the new moon (lunation number 216), 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.

This release fixes:

• physics bugs:
  • 1307 reported by @Damien212 and @maccollo,
  • 1404 reported by @Bocian and @lawndart,
  • 1415 reported by @scimas,
  • 1421 reported by @NathanKell and @rsparkyc;
• a UI bug, 1402, reported by @lawndart and @maccollo;
• crashes:
  • 1422 reported by @maccollo,
  • 1441 reported by @rsparkyc.

See the change log for details.

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.

[lawndart]

I think there may have been a misinterpretation of my navball request.

With Cauchy and prior to launch at KSP the navball shows KCKF instead of Surface. On ascent past 36km the navball is still switching to KCI, whereas I was expecting KCKF to maintain the planetary horizon for orbital insertion while the vessel was still suborbital. Toggling the mode by clicking the navball only switches between Surface and KCI; KCKF is only reselectable by the Principia interface. Prior to this version I was selecting KCKF in the Principia interface prior to launch so the navball would switch from Surface to KCKF at altitude instead of KCI.

Once the 36km altitude has been passed and the navball switches to KCI you cannot set it to KCKF until you have reached 70km. Trying to switch to KCKF in the Principia interface just switches to Surface on the navball, with Surface velocity. Once in space the navball displays KCKF but the velocity is still the Surface velocity - KCI reads ~200m/s higher.

Unless I am doing something wrong? 

Edited June 23, 2017 by lawndart
More text!

[eggrobin]

1 hour ago, lawndart said:

I think there may have been a misinterpretation of my navball request.

With Cauchy and prior to launch at KSP the navball shows KCKF instead of Surface. On ascent the navball is still switching to KCI, whereas I was expecting KCKF to maintain the planetary horizon for orbital insertion while the vessel was still suborbital. Toggling the mode by clicking the navball only switches between Surface and KCI; KCKF is only reselectable by the Principia interface. Prior to this version I was selecting KCKF in the Principia interface prior to launch so the navball would switch from Surface to KCKF at altitude instead of KCI.

Unless I am doing something wrong? 

The navball is switching to KCI when stock KSP would switch to Orbit mode; this is perhaps too early, but it is not in our hands.

Switching to Surface mode does switch the reference frame to KCKF, as you can check in the reference frame selection UI or in map view; however, while the craft is in an atmosphere, the speed display is not overriden; this is to allow compatibility with FAR, which overrides the surface speed display in the atmosphere (to show things such as Mach number, other units, IAS, etc.). Since (Kerbin) Surface is consistent with KCKF, this speed is still the speed in the selected frame, so the UI remains consistent.

Thus, during ascent, once KSP annoyingly switches to Orbit (inertial) mode, you can click back on the speed display to switch back to KCKF, as in stock; the speed label will say Surface (or, with FAR, might also say Mach, IAS, or EAS) while in the atmosphere, and KCKF in space. The goal for this change was to make it easier for you to switch between the two as needed, by simply clicking the speed display, rather than going to the clumsy Principia UI, and at the same time to clarify the strange state of Surface mode, which was unrelated to the plotting frame. KSP's mode switch remains.

There is a bug here however, namely that it was showing KCKF from launch until the switch to Orbit mode; it should have said Surface (or Mach or IAS or EAS), since you were in an atmosphere.

EDIT: You edited your post while I was replying, so:

1 hour ago, lawndart said:

Once in space the navball displays KCKF but the velocity is still the Surface velocity - KCI reads ~200m/s higher.

KCKF is the same thing as the surface frame of Kerbin, see the concepts page.

Edited June 23, 2017 by eggrobin

[lawndart]

Ah, thanks for the clarification and all your hard work on this. Although it is a pity we have lost the functionality to have Principia transition seamlessly from Surface to KCKF instead of KCI at 36km.

 

[eggrobin]

On 6/24/2017 at 0:08 AM, lawndart said:

Ah, thanks for the clarification and all your hard work on this. Although it is a pity we have lost the functionality to have Principia transition seamlessly from Surface to KCKF instead of KCI at 36km.

 

It may be possible for us to entirely disable stock's automated mode switch, though I'm not sure that's entirely a good idea; alternatively, we could change the altitude threshold (but it's hard to determine a "good" altitude threshold), or it might be possible to trick the game into using a more elaborate condition for switching (however that may be complicated, and it's not clear what condition we should use anyway).

[lawndart]

The stock mode switch at 36km is fine. I agree it is probably not a good idea or worth the time and effort to try and defeat the switching.

To be honest I'm not sure that I was making myself sufficiently clear as to what I was doing in my original request post. In Catalan I was able to prevent the switch to KCI by selecting KCKF as the frame of reference at any point on the pad or during ascent below 36km. The program switched from Surface to KCKF instead of KCI as it passed the 36km threshold and remained that way until I manually set it to KCI after ascent and orbit circularisation.

Launch a Catalan rocket. Don't touch the navball. At 36km it switches from Surface to KCI. Ok, revert to pad. In Principia set frame of reference to KCKF. Again, don't touch the navball and launch. At 36km it switches from Surface to KCKF.  

In Cauchy the process that pins the frame to KCKF has clearly changed the way this works and the switch to KCI cannot be overridden (I've tried). While I appreciate the work done on unification, this is not really what I was hoping for. It is still confusing for people new to Principia and it doesn't help when you are trying to coax a recalcitrant rocket through the upper atmosphere with both hands on the keyboard trying to stop it biting its own backside and the navball horizon disappears. I guess I was hoping for "If not vessel sit = ORBITING then set frame of reference = <body> Centred <body> Fixed" whenever a vessel was created.

Sorry if this sounds like a whinge; I'm not whining, but trying to explain.    

[eggrobin]

2 hours ago, lawndart said:

To be honest I'm not sure that I was making myself sufficiently clear as to what I was doing in my original request post.

I had understood what you meant; the issue is that the whole scenario relied on a mode we wanted to get rid of (having the navball and its speed display inconsistent with Principia's reference frame). We got rid of that inconsistency, and we made switching between "Surface" (body-centred body-fixed) and whichever meaning of "Orbital" is chosen as easy as it is in stock (a click on the speed display).

Unfortunately, the switch between the two is more intrusive than in stock, since it also involves changing the navball (and the map view plotting frame), rather than just the speed display; therefore it might make sense to check whether the vessel is orbiting to do trigger the switch, as you suggest (which could be a little tricky, but we can try).

[Benjisaur]

Edit:  Nevermind

Edited July 3, 2017 by Benjisaur

[scimas]

Very much liking the new ascending and descending nodes, they help a lot! There is an issue with the body centered body fixed frame at launch time. It gets set to it properly when coming from VAB or SPH, but it switches to body centered inertial frame if I use revert to launch. I don't know this but my guess is that the game loads a save file when reverting and does something different when coming from VAB/SPH, which might be causing this. But its not that big of a deal and as such I haven't opened a new issue on github. There are a couple other issues I have opened on github.

@eggrobin @pleroyThe changelog says that Moon landing in RO/RSS has been fixed, does this apply to stock bodies too, like minmus, mun? It was impossible to land on minmus even at midlands in Catalan, haven't checked in Cauchy.

[pleroy]

8 hours ago, scimas said:

Very much liking the new ascending and descending nodes, they help a lot! There is an issue with the body centered body fixed frame at launch time. It gets set to it properly when coming from VAB or SPH, but it switches to body centered inertial frame if I use revert to launch. I don't know this but my guess is that the game loads a save file when reverting and does something different when coming from VAB/SPH, which might be causing this. But its not that big of a deal and as such I haven't opened a new issue on github. There are a couple other issues I have opened on github.

It would be cool if you could open an issue for this on github.  Easier to track for us and to incorporate in the release notes, etc.

8 hours ago, scimas said:

@eggrobin @pleroyThe changelog says that Moon landing in RO/RSS has been fixed, does this apply to stock bodies too, like minmus, mun? It was impossible to land on minmus even at midlands in Catalan, haven't checked in Cauchy.

The work-around was actually in RSS, so it only applies to the Moon.  The underlying issue is still open, but it will take a while to fix.

[scimas]

Man, those stock orbits sure don't remain stable now! 16 Maneuvers just to reach that orbit; not to mention that even on the immediate next pass it doesn't resemble the original orbit at all..

Didn't actually perform those maneuvers, just plotted it.

[eggrobin]

On 7/8/2017 at 11:17 AM, scimas said:

Man, those stock orbits sure don't remain stable now! 16 Maneuvers just to reach that orbit; not to mention that even on the immediate next pass it doesn't resemble the original orbit at all..

Didn't actually perform those maneuvers, just plotted it.

Yes, Ike is very large (so large in fact that orbits around the L4 and L5 points of the Duna-Ike system are unstable). What are the red and green conics? Are they from contracts? We have not looked at contracts (or career mode in general), but I guess contracts that require following an elliptic orbit in a highly perturbed place won't work well with Principia (low orbits should be fine unless oblateness comes in). @rsparkyc has written some plumbing to allow people to make Principia-compatible contracts, I don't know whether that has been used yet: 

 

[Teilnehmer]

I think it would be more convenient if the mod was per-game. I mean, when starting a new game, you choose to enable or to disable Principia (just like CommNet). Is that possible?

[scimas]

On 15/7/2017 at 11:01 PM, eggrobin said:

Yes, Ike is very large (so large in fact that orbits around the L4 and L5 points of the Duna-Ike system are unstable). What are the red and green conics? Are they from contracts? We have not looked at contracts (or career mode in general), but I guess contracts that require following an elliptic orbit in a highly perturbed place won't work well with Principia (low orbits should be fine unless oblateness comes in). @rsparkyc has written some plumbing to allow people to make Principia-compatible contracts, I don't know whether that has been used yet: 

 

Yes, the red and green conics are from contracts. I have been playing a career mode with mostly just the stock game, principia and some utility mods like KER, KAC; and it has been mostly playable without a problem. As you said, low orbits around any body or high orbits in unperturbed places are pretty much stable. But contracts involving stable stock orbits near places like Duna-Ike or contracts involving landing at places above the timewarp limit are just impossible to complete. There is also the problem that KSP uses the stock values of parameters to determine the completion of contracts. So even if sometimes your principia orbits completely matches the target orbit, the contract doesn't get completed. That's when you turn on stock orbit and see that the stock Ap is 5 or so degrees ahead or behind the principia orbit.

So yeah, there are small annoyances like that, but nothing deal breaking. If something can be done to force the contract system to use principia's values, then I would be the first to jump on that mod! @rsparkyc's mod seems to be going in that direction, though I'm not familiar with the internal working of the contract system to know whether the mod takes values from stock game or from principia.. or even whether principia's values are accessible to other mods or not.

[eggrobin]

4 minutes ago, scimas said:

So yeah, there are small annoyances like that, but nothing deal breaking. If something can be done to force the contract system to use principia's values, then I would be the first to jump on that mod! @rsparkyc's mod seems to be going in that direction, though I'm not familiar with the internal working of the contract system to know whether the mod takes values from stock game or from principia.. or even whether principia's values are accessible to other mods or not.

Principia doesn't have an API for other mods at this time, however I think it should be doable to make contracts that just use the stock orbits if they are a bit more lax about their requirements (e.g. @rsparkyc's mod allows for contracts that simply check that the vessel stays close enough to a Lagrange point, rather than requiring specific orbital parameters).

Edited July 17, 2017 by eggrobin

[eggrobin]

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-0. This will be resolved in future versions.

See the change log for details.

Edited July 23, 2017 by eggrobin

[panourgue]

Hi, devs, enjoying your physics conversion mod very much. I have a small problem though

Why is the new version cripples fps in space center view? Occurs both with stock and rss.

On RSS (with clouds) I get 22 vs 99 fps. (clean install, new save)

Spoiler

 

Edited July 29, 2017 by panourgue
img

[eggrobin]

4 hours ago, panourgue said:

Hi, devs, enjoying your physics conversion mod very much. I have a small problem though

Why is the new version cripples fps in space center view? Occurs both with stock and rss.

On RSS (with clouds) I get 22 vs 99 fps. (clean install, new save)

  Hide contents

 

Interesting; is that only in the space centre view, e.g., is that the case when flying your rocket? Map view is sort of slow when the history has a lot of points but we know about it (and it will likely be solved in Чебышёв, we've been working on geometry libs for a few releases), but space centre should not be. However I think I have an idea why that may be the case. Can you open an issue on GitHub to track this? It is easier to follow these things there than on the forum.

[panourgue]

21 hours ago, eggrobin said:

Interesting; is that only in the space centre view, e.g., is that the case when flying your rocket? Map view is sort of slow when the history has a lot of points but we know about it (and it will likely be solved in Чебышёв, we've been working on geometry libs for a few releases), but space centre should not be. However I think I have an idea why that may be the case. Can you open an issue on GitHub to track this? It is easier to follow these things there than on the forum.

Done. Btw, how should I set "orbital drift compensation" and "ease in gravity" settings? Or it doesn't matter?