pleroy

The centre of coordinates coincides with the barycentre of the solar system. All the celestials rotate around it. The Sun is not special in any way. 8700 au is quite large. We try to fit the trajectories of celestials to within 1 mm, and 8700 au is 1e18 mm, which is significantly more than the accuracy of 64-bit floats. So there is a risk that the motion of celestials would become jerky, or that polynomial fitting would fail. It might be possible to alleviate problems by tweaking the numerics blueprint file, but it's likely that distant planets would "shake" when you try to land. Also, because Centauri C is weakly coupled to the other two stars it's possible that numerical innacuracies would appear. We know for instance that we do not do a great job at predicting the motion of Pluto. Finally, some people have noticed that predictions are getting increasingly short/slow as you move away from the centre of the solar system: you just cannot warp fast enough to go there. I'm afraid that you might be underestimated the complexity of station keeping. At least the following problems need to be solved: The orbit needs to be characterized and its mean properties determined. This is not easy in an N-body universe because there is a zoo of interesting orbits that must be considered, and therefore just finding an approximate ellipse requires care. @eggrobin has been spending the last 5-6 months looking into this specifically for perturbed Keplerian orbits, e.g. LEO; he read a treatise on the topic and numerous research papers, and is just starting to reach the point where he has an idea how to do that in the game. Once the target orbit is characterized, there is an interesting optimization problem to solve to stick to that orbit with minimum fuel. We are not particularly competent here, but we know that @Jim DiGriz has been spending years working on this topic. For what it's worth, there is actually a competition organised by ESA to find good algorithms for trajectory optimisation. Once the physics problems have been solved, there remains the challenge of integrating with Principia. This may sound like a "simple matter of programming", but it's certainly months of work: we would first need to design an API that allows modifying the behavior of vessels (that's much more complex than the read-only APIs we currently expose), implement it through our code base without breaking anything, putting tests in place on both sides of the API to make sure that there is agreement on the contract and that no regressions arise. And just to clarify: we are not interested in "implementing some frequent use cases". If this thing is worth doing, it's worth doing right. Windows is our main platform, and we don't play on Linux or Mac, we only build there. So it's possible that there would be performance problems, although we do run benchmarks to make sure that the main algorithms have reasonable performance. There have been problems with performance on MacOS in the past because of deep issues with the operating system (#1955) but they should have been fixed in Erdős and we haven't heard anything since then. It would be interesting to know if other Mac users are running into similar issues. So feel free to open an issue on GitHub, but we'll need considerably more details than "on my machine it's slow".

The right direction in this case are the FAQs.

Yes, there is conditional compilation in a few places to work around MSVC bugs. In the vicinity of the failing line you'll see references to _MSC_FULL_VER. You'll need to add a new condition for the value of _MSC_FULL_VER that corresponds to preview 2.

Good point, I'll update Setup.md to clarify how you can build with other editions of VS. I'll mention this requirement too. Note that you can install the SDK from the Visual Studio Installer by selecting "Universal Windows Platform development" and selecting it in the list of components (for some reason the default is 10.0.17763.0). As is documented in the Setup.md file. These DLLs are/were necessary on Mac I think. In Windows they just produce warnings, they should not get in the way of building. This is your problem right here: you need to download and build the Google dependencies. As @drake127 pointed out, in your first post you were missing the proto compiler, and in the second the glog libraries. Windows knows how to interpret / in paths in includes and other places. Otherwise how could you hope to write C/C++ code that can reasonably be ported from Linux to Windows or vice-versa? If you are "repairing" the source you are heading towards a world of pain. Following more closely the instructions in Setup.md would make you happier I think. Ah, and I forgot to mention: use the master branch, not the Fatou release, to build with VS 2019. Fatou was still built with VS 2017.

From the KSP documentation: uint Part.flightID a unique id to identify this part in flight. This one is guaranteed to be unique for all parts in the simulation. Not assigned in the editor.

No longer supported? Microsoft seems to differ, Visual Studio 2017 version 15.9, which we use, has a mainstream support end date of April 12, 2022. I have started looking into Visual Studio 2019, and the migration seems quite smooth, but in the past these things have ended up taking weeks: we need to update our tooling, check for performance regressions, report any bugs that we may find, etc. While it makes sense to use the latest greatest version from Microsoft, it's not like it's tremendously useful: we can hardly use C++17, not to mention C++20, because Mac has an antiquated version of Clang and libc++, and we need to be able to build on Mac.

It is actually a bug, it has been reported a few days ago (#2154) and will be fixed in the June release.

The two scales are multiplicative so setting the App Scale to 83% would cause the Principia window to go back to the normal size. It seems that at least some mods do it that way. Of course, it's hard to know if it's how Squad intended it...

The external interface is the only API where we will guarantee stability and compatibility. The rest is entirely internal and should not be used by other mods. Can you open an issue on GitHub to track this?

The comment on top of that page is outdated: I just removed it. The API is available starting with Fano. Note that as things stand it only gives you the parameters of the geopotential model. If you have other needs we would like to hear from them to understand how to best address them.

The issues should be more-or-less the same: the planets and vessels will be at semi-random locations. This will have no effect other than upgrading Principia. The saves will remain compatible (we maintain compatibility for years).

I was referring to the fact that Maneuver Node Evolved apparently let you snap a manoeuvre to the apoapsis or to the closest approach, etc., which would remove quite a bit of annoying hand-tuning. Yes, this is what we'll do in the next version, if only because editing the field that counts down was not going to work. As for editing multiple manoeuvres, it's something that I'd like to do but it goes pretty deep.

The next version (May 4) will have text entry fields in addition to sliders for the Δv and time. Not familiar with that mod, but it does look cool. Snapping manoeuvre nodes to "interesting points" of the trajectory is something we have in mind, but it's far from trivial.

We won't have 1.7 support in the May version (Fáry, May 4). Barring the unexpected we should have it in the June version (Fatou, June 3).

@Einstein_Cross_X1: A possible way to make progress would be to clone the test we use to check the stabilization of the KSP stock system and adjust it for the system(s) you are interested in. It would make it reasonably quick to experiment with various tweaks of the system. The drawback of course is that you'd need to build Principia (instructions here) and then do some C++ programming.

We should definitely replace the navball in IVA. I have created #2099 to track this. The interaction with RPM is another kettle of fish entirely. I don't think that we want to start having dependencies on other mods. I guess we could expose an API to read the orientation of the navball, and then other mods could use that orientation in their processing.

If you had done a quick search in this topic you'd have found this post:

@Xurkitree: The year is 2019, please use tools that support Unicode. FWIW we use 7-Zip to produce the archives.

Hmm, this has been reported by @scimas a long time ago (#1868) but somehow it fell off our radar screen. We have code to set the markers but apparently it stopped working with some KSP upgrade. We should try to figure out what's happening.

@Eriksonn: It is completely feasible, but it requires some understanding of the way geopotential modeling works. You don't directly use the altitude. Instead you specify coefficients (conventionally named Cnm and Snm) for spherical harmonics of various degrees and orders. This image gives an intuition of what the spherical harmonics look like (the poles are on the left and right, the equator is vertical on the image). For instance, degree 2 order 0 makes it possible to put more mass at the poles and less at the equator or vice-versa; degree 2 order 2 makes it possible to put more mass at Greenwich and Fiji and less in the Appalachians and Himalayas, etc. Unfortunately the Wikipedia article on Geopotential model is rather lame, so I recommend looking at section 6 of the IERS Conventions. In practice you'll need to write a custom principia_gravity_model configuration covering (at least) the body for which you want to specify the geopotential. This configuration is described here. Look in particular for geopotential_row and geopotential_column.

@Agustin: You would notice differences if you were trying to replicate very accurately real-life missions: the old geopotential would exhibit drifts of hundreds of kilometers over a few months to a few years depending on the altitude. Things will get more interesting though when we extend this to the Moon, where the geopotential is very weird and affects orbit stability, or to Mars, where the position of Phobos and Deimos is currently bogus. More to come in future versions: stay tuned. @Someone2018: We started working on this in August. Making it correct was the first challenge, and then making it fast was even more interesting.

Thanks for the nice videos @AloE, and thanks for reporting the problem with 1b. I believe that I understand what is happening: there is a stupid mistake whereby the configuration of the integrator used in the game differs from the one we used to do the transit-time variation optimization. For the transit at JD2457721.38747, the former produces an effective transit at 20:34:47 (pretty much what you observe), the latter an effective transit at 21:18:08 (pretty much the correct value). Note that this probably tells us that the integrator is not converged for 1b, presumably because the step size we used is too large. Darn, we'll need to rerun the optimization... Created #1999 to track this. Follow the music there.

All working as intended. KSP is just a bit confused by our DLL because they are unmanaged and it tries to load them as if they were .Net assemblies.

Thanks for taking the time to find the mod causing the problem. From reading its description it's clear that it alters the physics, apparently in ways that are incompatible with Principia. We'll get in touch with @ferram4 to understand more.

@IncongruousGoat: This is a very bizarre bug, and not one that has been reported before. My gut feeling is that this is a nasty interaction with some other mod, but these problems are exceedingly difficult to debug. The thing that is especially strange is that Principia only translates parts, and never rotates them. So we could be guilty for the engine being off-centre, for instance, but it's harder to see how we would cause the antenna to rotate. If you can put your save on dropbox we'll take a look, but don't hold your breath, more likely than not we won't be able to pinpoint the cause.