Jump to content

pleroy

Members
  • Posts

    184
  • Joined

  • Last visited

Everything posted by pleroy

  1. It is conserved across time warp: the motion is completely continuous when warping and unwarping. This makes it possible to do spin stabilization but also more exotic rotational motions (we've played a lot with the Джанибеков effect in our tests). When resources move around the ship (or when the ship changes form), the masses and positions of parts change and Principia recomputes the moment of inertia; it then adjusts the angular velocity to preserve angular momentum (basically what figure skaters do). In essence, Principia is the source of truth for the angular momentum and it will correct what is done by KSP/Unity to make the motion physically correct.
  2. So @AloE I understand what you are trying to do, but I am not sure what I am seeing on these pairs of screenshots: what is on the left and what is on the right (I noticed different planet names and obviously different illumination)?
  3. Hmm, it does the same for me. But then when I go to Weiyun it tells me that the sharing link is indeed https://share.weiyun.com/5uxy0OG. Maybe they are having problems. Can you try with the non-Weiyun links (they go to Google Drive so may be hard to access in China)?
  4. Good to hear that you managed to make things work on 16.04, and thank you for reporting it. I just updated the links for Fréchet on github. Announcement coming in a few minutes.
  5. The reason why it's not going to happen is that we need a recent version of Clang and libc++ to build Principia. Essentially, we need complete support for C++17. The version of libc++ that shipped with Xenial was 3.7, where they had hardly started looking into C++17. We don't, at the moment, have complete C++17 support on MacOS (that only came with Catalina) and having to emulate the missing bits is a royal pain in the neck (and hampers development of useful features). That wouldn't help you. You'd need a Xenial version of libc++ version 8, or it would not even compile.
  6. The oldest binary that supports 1.6.1 is at bit.ly/2CWdvdo. You're on your own, though: we upgraded past Xenial (16.04) in June 2017 so if a binary produced after that date works on Xenial, it's pure luck. Recent versions of Principia want libc++-8-dev and libc++abi-8-dev, and I am not aware that these would be available before Bionic (18.04).
  7. As mentioned on the reddit thread, there is one thing that is noticeable in your log: From the forum thread, the supported versions are: Either you are using an ancient version of Principia that is no longer supported, or your crash is expected, since 1.4.5 is anterior to the earliest supported version. I suggest that you upgrade to a more recent version of KSP (1.4.5 is more than a year old), and download the latest greatest Principia (Fourier). If the problem persists, please report a bug as described in the wiki. We are interested in hearing about problems but we cannot debug them if we don't have the required information.
  8. The geopotential data also comes from astronomical sources (and is consistent with astronomical conventions). This file has all the references for the sources that we used. The RSS textures may or may not match that, but if they don't it just mean that they are inconsistent with astronomical reality.
  9. @AloE I wouldn't be surprised if the RSS textures were improperly aligned or even mirrored. Other than the Earth and the Moon, where it's easy to check for consistency, most users wouldn't notice this kind of glitches. In the Principia data files, the axis directions, mean radii, reference angles and angular frequencies are from "Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements: 2009", Archinal et al., http://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2009reprint.pdf. So we didn't invent our own conventions, we just followed established astronomical conventions. ETA: The values given in our files are for JD 2451545.0, i.e., 2000-Jan-01 12:00:00.0000 TDB.
  10. @AloE You are in unexplored territory here, but chances are that what you are doing is going to work. The reason is that Principia stops managing vessels (or vehicles or Kerbals, etc.) when they are in contact with the ground. So by putting your vessel on the ground on Mimas you are not doing anything that interacts with the Principia state. And once you launch it, sure enough, Principia is going to manage it as it should. The problems mentioned in older posts had to do with people who wanted to move their vessels in flight. That is surely not going to work.
  11. The Ferrari archive has the following hashes on my machine: &"C:\Program Files (x86)\File Checksum Integrity Verifier\fciv.exe" -md5 -sha1 "principia ferrari for 1.7.3.zip" // // File Checksum Integrity Verifier version 2.05. // MD5 SHA-1 ------------------------------------------------------------------------- 5395878d78edb96effb71112a93f6026 28b629b6c0cf439c29e6eacbc15750bf31b86f8f principia ferrari for 1.7.3.zip The date of most of the files in the archive is 2019-07-31 (with times like 13:38, 14:14 and 14:23). A few are older. I uploaded the archive to VirusTotal and the results seem clean. I suspect a false positive, although the part about "less than 1 week old" is weird.
  12. Nice! Make sure that you send a pull request to the author of KerBalloons to move the fix upstream: the next user of KerBalloons and Principia will thank you.
  13. 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".
  14. 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.
×
×
  • Create New...