pleroy

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.

I suspect that you have a mod that simulates a 32-bit architecture by claiming that the pointers are 32 bits. Something like that was in use when KSP didn't really work on 64-bit machines.

What do you mean by "when I use my build"? Build of what? Built how?

You need to have (1) a 64-bit processor (2) a 64-bit installation of Windows (3) a 64-bit installation of KSP. At least one of these prerequisites is missing (I suspect that you have a 32-bit installation of KSP).