pleroy

Members
  • Content Count

    89
  • Joined

  • Last visited

Community Reputation

79 Excellent

3 Followers

About pleroy

  • Rank
    Rocketry Enthusiast

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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".
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. It is actually a bug, it has been reported a few days ago (#2154) and will be fixed in the June release.
  7. 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...
  8. 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?
  9. 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.
  10. 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).
  11. 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.
  12. 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.