[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

[John FX]

15 hours ago, pleroy said:

This is not a known bug.  We'll need you to open an issue on Github and give us your complete logs to investigate, as explained in the FAQs.

Don't read too much in the similarity to #1561, it's unlikely to be the same problem because the code has changed quite a bit.  Also, the glog message that you mention is innocuous.

Will do.

EDIT : just reproduced the bug and went to post but someone else has posted about it.

Edited November 23, 2017 by John FX

[nervv]

Hello. I finally managed to get my principia working. Great mod! I would like to know if it is possible to get it working together with the flight computer from remote-tech. When I select "show on nav-ball" the flight computer registers the node. But it does not execute the maneuver correctly for some reason. It orients itself well but then only aplies very short burst.

[olangu]

On 2017-11-25 at 4:20 PM, nervv said:

Hello. I finally managed to get my principia working. Great mod! I would like to know if it is possible to get it working together with the flight computer from remote-tech. When I select "show on nav-ball" the flight computer registers the node. But it does not execute the maneuver correctly for some reason. It orients itself well but then only aplies very short burst.

When flight planner is open it continuously updates the navball. But if you create the maneuver, push it to the navball then close the flight planner it shall work as expected. Or at least does so for me. Good luck!

[scimas]

5 hours ago, olangu said:

When flight planner is open it continuously updates the navball. But if you create the maneuver, push it to the navball then close the flight planner it shall work as expected. Or at least does so for me. Good luck!

You would also need to use inertially fixed burn then, otherwise the direction of the delta V vector would be wrong.

[MarvinCZ]

Hello,
I have a suggestion for the Principia Wiki - Concepts page. I'd suggest the reference frame fixing the centre of a celestial, the plane of its orbit around its parent, and the line between them is ideal for maintaining orbit around an L2 point, or at least the Earth-Moon L2. It's certainly better than the Earth-Moon Barycentric reference frame, which is what the page suggests for Lagrangian points.

I'm not sure about the other Lagrangian points, the barycentric reference frame may be the best there. For the Earth-Moon L2, though, the EMB reference frame makes it harder than MCEA because an orbit is harder to recognize. It's especially noticeable when attempting orbit insertion.

For illustration, this shows how an orbit around the Earth-Moon L2 point is displayed in both reference frames. It's even more evident with longer orbits. In EMB, the orbit appears almost random.

Earth-Moon Barycentric:

Spoiler

Moon-Centred Earth-Aligned:

Spoiler

 

Edited November 29, 2017 by MarvinCZ

[eggrobin]

18 hours ago, MarvinCZ said:

I have a suggestion for the Principia Wiki - Concepts page. I'd suggest the reference frame fixing the centre of a celestial, the plane of its orbit around its parent, and the line between them is ideal for maintaining orbit around an L2 point, or at least the Earth-Moon L2. It's certainly better than the Earth-Moon Barycentric reference frame, which is what the page suggests for Lagrangian points.

Yeah, this makes sense for L₁ and L₂; in general what you're seeing is that the appropriate frame would be the barycentric rotating-pulsating reference frame (keeping both bodies fixed, by stretching along the line between them) for an eccentric two-body system (the Moon's eccentricity is not negligible here), but we can't easily support a pulsating frame in the current state of our libraries (our abstractions break down because we lose the inner product). L₁ and L₂ are close to the smaller body, so the frame centred on it works well enough.

[MarvinCZ]

Thank you for the explanation, it makes more sense now. I'll try adding a sentence to the Concepts page on the project wiki, I hope that's OK. It should help people like me, trying to navigate L2 orbits and frustrated at the weird trajectories they get with the regular barycentric frame.

Edit: I added this sentence to the Wiki: "This frame may also be useful for navigation around Lagrangian points L1 and L2 thanks to their proximity to the smaller celestial."

And thanks for being able to even have a discussion about libration points in KSP

Edited November 30, 2017 by MarvinCZ

[影之瑒]

I really appreciate that you bulid this mod, it gives me much more fun.But I have met a problem:  When I click "Force Stop", the game crashed....

The version of the game is 1.2.2(with RSS,RO,RP-0), and the version of Principia is "陈景润"

Edited December 6, 2017 by 影之瑒

[lawndart]

Occurs with Stock + KER + Principia

Info log (part):

1206 16:10:34.231690  4012 interface.cpp:779] End plugin serialization
I1206 16:10:35.001734  4012 interface.cpp:674] Reinstating stock gravity
I1206 16:10:42.080139  4012 interface.cpp:262] Destroying Principia plugin

Lots of objects being destroyed...

I1206 16:10:42.087139  4012 interface.cpp:268] Plugin destroyed
    @   000007FEED07E28D      principia__GetPlottingFrame [0x000007FEED07E28C+236028]
    @   000007FEECFEBA2B      principia__SetBufferedLogging [0x000007FEECFEBA2A+573390]
    @   000007FEED0100CB      principia__SetBufferedLogging [0x000007FEED0100CA+722542]
    @   000007FEECF4B8AC      principia__CurrentTime [0x000007FEECF4B8AB+75]
    @   00000000154D4E0C      (No symbol) [0x00000000154D4E0B]
F1206 16:10:42.097139  4012 interface.cpp:252] Check failed: 'plugin' Must be non NULL 

[pleroy]

@lawndart, @影之瑒: Thanks for the reports.  It seems that the capability to start/stop Principia has decayed over time.  It was useful at the beginning of the development, when the mod was experimental, but it has probably overlived its usefulness.  In particular we know that running without Principia and re-enabling it causes no end of trouble because KSP and Principia get into inconsistent states.  I have created #1643 to remove this capability.

[itsthatguy]

A few suggestions for the future of this mod:

I would LOVE to integrate this mod into my Realism Overhaul experience. I am always up for a little bit of added realism in games, and this seems like the ultimate realism upgrade for KSP. After using it a short amount of time I can say that I love everything about this mod. Unfortunately, I will not be using this mod. Here's why:

My issue is not the mod itself or anything about it. My issue is one of the side-effects that is produced by the mod: constantly changing orbits. Now, I don't have a problem with this outright. It has always frustrated me that in KSP orbits are set in stone and never decay or change unless the user wants to change them. However, because of this there is no built in system in the game to actually HANDLE more realistic constantly changing orbits. Once again, I enjoy the added realism here. The problem is the MASSIVE amount of micromanagement crap that this produces. 

For example: If I want to create a network of communication satellites in geostationary orbit, it is pretty simple in the vanilla physics model. Put them there and forget about them. However, when you introduce a more realistic model, the gravitational influence of the Moon and Sun create constant changes in the orbits of ALL of these satellites, meaning that if you want them to actually stay in their orbits, you have to constantly make small correction burns for EACH one of these satellites.

What could be done to help alleviate all of this micromanagement? I propose that if this project teamed up with the creators of the Time Control and Remote Tech mods, we would have a solution. You see, Remote Tech has this very useful feature called the flight computer. This allows you to command your probe to do certain actions including performing maneuver nodes ahead of time so that, for example, if you lose connection for whatever reason your probe will still perform that action without you having to control it directly. 

What I am saying here is that you guys could team up to create an option in the flight computer that essentially says "hold this orbit" or something like that. Of course, because of the way that KSP handles time warp, you would have to make sure that this would work in conjunction with the Time Control mod, which, among other things, allows you to have REALLY high physics warp for performing REALLY long burns. This way, even when using time warp, the flight computer would still be able to perform those small correction burns.

When you put all of this together you have a solution that essentially solves the issue at hand by eliminating the need for the player to constantly do manual orbit corrections.

Edited December 16, 2017 by itsthatguy

[scimas]

There is already a recent issue open on Principia's github requesting an API. But, given the mod's inherent complexity, I guess it will be a very long term goal at best. I would have liked to contribute to it, but I simply don't have enough experience with programming. Even someone who has experience will need to get familiarized with Principia's complete code, which I'm assuming would be a time consuming task.

It doesn't mean that I'm opposing that request, but I understand why it may not happen. I'm really thankful that the devs give regular significant updates to the mod!

[lawndart]

I already use Remote Tech's computer, but due to the way Principia has the node as the burn initiation rather than the mid point, I use it to set the node orientation and use the Burn xxxm/s function to trigger a precise burn at the node point. If you run the Execute function it tries to perform the burn early, so this is going to throw the plan out. Once the burn is complete the computer automatically switches to prograde or the next node, so messing up your orientation for any fine tuning. So not perfect.

In that regard would it be possible to have a toggle to set Principia to fake a Node-At-Mid-Burn by adding 50% to the initiation time? That way automated systems using a Node-At-Mid-Burn timing would be in sync with Principia.

[rhoark]

Does anyone have a principa-friendly config for 3.2x scale with OPM?

[pleroy]

 

14 hours ago, itsthatguy said:

What could be done to help alleviate all of this micromanagement? I propose that if this project teamed up with the creators of the Time Control and Remote Tech mods, we would have a solution. You see, Remote Tech has this very useful feature called the flight computer. This allows you to command your probe to do certain actions including performing maneuver nodes ahead of time so that, for example, if you lose connection for whatever reason your probe will still perform that action without you having to control it directly. 

@itsthatguy: You must be new to mod development.

See, developing a mod is quite a bit of work, and it takes some dedication to keep spinning out releases to fix bugs, add improvements, and generally address user feedback.

Now add to that the issues that arise because of coexistence with other mods;  we get a fair number of reports along the line of: "I am using mod XYZ and it causes Principia to crash"; this is hard to debug and sometimes require that we sync up with the other mod authors to understand what's happening or to get them to change their code.  Also add the fact that different mods are on different release cycles: we support KSP 1.2.2 not because we love it but because RO is not on 1.3 yet; it does make our release cycle significantly more cumbersome.

The bottom line is that there is no way that the authors of three distinct mods can coordinate and synchronize to come up with a consistent design and implementation to make those mods work together smoothly.  The overhead would just be overwhelming; and, to be honest, it's not the fun part of mod development.  As @scimas said, having an API would help to some extent, but so far no-one has volunteered to help with that work.

[Jim DiGriz]

On 12/16/2017 at 10:18 AM, itsthatguy said:

A few suggestions for the future of this mod:

You're not suggesting anything that isn't obvious.  Orbital decay, stationkeeping and low-thrusting-spacecraft-on-rails are all mod ideas that have occurred to everyone that has used Principia.  The mod authors are a busy with issues more directly related to the N-body physics simulation though.  I also doubt that the correct solution is tighter remotetech integration.  The problem is more that you need a mod which looks at the actual principia orbit (not the tangent orbit) and applies a perturbation to the orbit and drains some RCS, and can handle that process through timewarping (which is why decay, stationkeeping and low-thrust probably all should go into the same mod), and remotetech has none of the correct internals for that.

[eggrobin]

For the new moon (lunation number 222), the new release (Christoffel) is out.

Vessels no longer pass through a planet unharmed at sufficiently high timewarp like in stock, and are detected by Principia as having collided with the planet, and are destroyed. In particular, this resolves the crash that occurred in 陈景润 when a vessel went through a planet unscathed (#1628, reported by @awang and @John FX).

Support for KSP 1.3.0 has been dropped. We support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load).

See the change log for more details.

[pleroy]

@Jim DiGriz has actually a very good point.  For things like station-keeping and orbital decay, code would need to be executed inside the inner loop of the integrator.  The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved).  Everything would need to be done in C++ using the Principia abstractions and linked into the Principia DLL.  When you do this, well, you are just beefing up Principia and not interfacing with another mod.  I am not saying that we won't be doing this one day, but not using 3rd party mods.

The interested reader might want to look at the PRs that fix #1628 in the new Christoffel release.  It took me many pull requests and close to three weeks to just figure out if a vessel is inside a celestial during the force computation and bring that information up to KSP.

[Jim DiGriz]

Was thinking about this thread on my walk to grab lunch and the other thing is that HyperEdit doesn't work with Principia either, and from what I understand the approach of removing Principia, tweaking your keplerian orbit with HyperEdit and then dropping Principia back in just corrupts your save.  And then on top of that there's the issue pleroy brough up which was performance -- although I'm not sure I'd model it that way, you can probably get by with doing impulsive station keeping once per orbit, and you can take a nap for the rest of the orbit.  You also would probably want to allow the algorithm to be a bit 'sloppy' for performance reasons (you'd probably look at the whole prior orbit, decide where you 'did' your station keeping, perturb the orbit there, then remove RCS from the vessel or something along those lines).  Also, I'm not sure what kind of algorithm you'd want to use for station keeping since some N-body perturbations are going to be smoothed out by e.g. the lunar cycle.  If you can just wait 2 weeks and let the moon yank you back into position then it makes no sense to fix your orbit with great precision right now.   There would also likely need to be some kind of limits placed on station keeping and different station types of station keeping.  LEO station keeping is reasonable.  Station keeping at a libration point is reasonable.  Random low energy orbits probably not so much (although maybe you could just grind up the user's CPU and waste all their RCS until that problem went away).

[R-TEAM]

Would be nice to have a list/link to common Stock system + Additional Planets/System configs ...

I have atm Stock system + OPM-Galileo ... and i have no clue how i get this two work nice in principia ....

[scimas]

Take a look at this Principia stock modification of Bop. I guess almost any planet pack here uses the Kopernicus mod to create the system. Kopernicus uses cfg files to describe what characteristics a planet has, like mass, radius, orbital parameters and such. You will just have to mostly modify the parameters, mainly the orbital ones, to see which ones work and which don't. There isn't any concrete method of balancing a system. It is actually surprising that the stock system is so stable with real gravity; then again it might be because of its similarity to our actual solar system.

Also, take a look at this, @rhoark, @R-TEAM.

 

[nanomage]

8 hours ago, R-TEAM said:

Would be nice to have a list/link to common Stock system + Additional Planets/System configs ...

I have atm Stock system + OPM-Galileo ... and i have no clue how i get this two work nice in principia ....

hale used to collide with ovok in 13 kerbal years in OPM. Definitely try out Scotskerb's patches mentioned here, if that doesn't help get rid of ovok or stash it someplace safe (like low eve orbit)

[R-TEAM]

Thanks - will try the config file from Scotskerb ....

 

Regards

[Jim DiGriz]

Kepler-90 might be an amusing solar system to create with Principia:

 

https://en.wikipedia.org/wiki/Kepler-90

 

Throw a few plausible, and vetted for stability, moon systems in there.  Delta-V map is probably horrendous though(?), particularly for getting to that closest inner planet...

[pleroy]

8 hours ago, Jim DiGriz said:

Kepler-90 might be an amusing solar system to create with Principia:

@Jim DiGriz: So at some point @eggrobin and I looked into the TRAPPIST-1 system, where quite a bit of data is known.  There is a significant amount of work needed to go from the Nature paper to a proper KSP configuration, but I suspect that it would be great fun.  We might decide to do that in some upcoming release.