Jump to content

pleroy

Members
  • Posts

    192
  • Joined

  • Last visited

Everything posted by pleroy

  1. From the main thread: Notice that I was talking about Vagrantfile, not Dockerfile. We have not used the Dockerfile for 2 years, so it's probably awfully out of date. Anyway, I just removed it as it was only causing confusion. If you want to build on a Linux, you need to execute by hand all the commands in the Vagrantfile (from "echo Provisioning Principia" to the marker "SCRIPT". Then you need to make sure that you have the KSP assemblies in a directory named "KSP Assemblies" next to the "principia" directory. Don't go modifying the Makefile unless you really understand what it is doing (and what you are doing). Ah, good point, fixing it now.
  2. Please open an issue on github and attach your logs and save to that issue (maybe as a zip archive) just like you did for 1416. It's just too hard for us to track bugs here on the forum.
  3. There is a MacOS version build by lamont-granquist on github here. His builds lag a few days behind ours but he is keeping up with the changes we make. Well, the README file on github is a good starting point...
  4. Good point. We are creating a new thread (below) to help people who want to build Principia themselves. @Rory Yammomoto@HebaruSan
  5. No, this is a question that gets asked periodically (see e.g., issue 1420) and this cannot be made to work. Basically in order to implement proper N-body physics Principia wants to control the positions and velocities of the celestials and therefore has to ignore everything that comes from the game. That includes changes done by other mods such as Hyperedit. Kopernicus works since it produces an initial configuration, not random changes during the game. Same thing for our configurations for RSS.
  6. Indeed, you are not going to space today For the Linux release we use Vagrant. There is a Vagrantfile in the repository and then once the virtual machine is started it's just good old `make`. It works for us, but I have no idea how hard it would be for someone who doesn't know where all the traps are. Each time we cut a release we have to fix quite a bit of stuff just to make Clang happy and get to a point where the tests kinda pass.
  7. If you feel adventurous you can try to build from the latest commit of the github repository. You should follow these instructions and then you'll find the plugin in the `Release\GameData` directory. Beware, this is not for the faint-hearted. Or you can wait until the next new moon for the Cauchy release.
  8. We are in no hurry to move to 1.3. We want to remain compatible with RO/RSS which as you mention currently only works with 1.2. When a good number of mods have moved to 1.3 we'll look into what it would take to migrate Principia.
  9. Thanks for the suggestion. In 1411 @eggrobin has unified the speed display mode and the selection of the reference frame, which should make things much more natural.
  10. Thanks for the report. This rings a bell, @eggrobin had seen it in a video by Scott Manley. Created issue 1404 to track this.
  11. No, engines don't have any effect on planets in Principia. Only planets have an effect on planets, it's a useful optimization to speed up the computations. But even if the mod allowed it, as explained by Scott Manley, there is no way that you can use engines and tanks to move a planet. Yes, it does, it was one of the major improvements in Cardano. From the change log:
  12. I guess we should make an effort to fix these exceptions. To the best of our understanding they don't cause problems, but it would be nicer to avoid spamming the logs and the UI. I created an issue to track this.
  13. Closing the discussion on the 200 m/s acceleration: thanks to a save and detailed instructions provided by @lawndart we were able to reproduce, debug and fix the problem (see this issue for details). The fix will be in the Catalan release, planned for May 25th.
  14. Great, it seems that we are getting close to something that we should be able to reproduce. Could you give us your save (or saves) as close as possible to the point where the problem shows up, as well as your INFO log? The best way to go is to create a github issue with detailed explanations of what you are seeing and links to one or several gist with the save/INFO files. Thanks for your perseverance in trying to nail down this bug. With some luck we might be able to fix it in the upcoming Catalan release, planned for May 25th.
  15. The Jool system was unstable. We don't patch existing saves, so if you keep using a Cardano save, the unstability will still be there. You'll need to create a new save with Cartan to avoid running into the unstability. We apologise for the inconvenience.
  16. (Mod co-author here.) Unfortunately no, this is a hard problem. Basically you need to explore the phase space of the parameters of the modified solar system until you find a stability zone. It took @eggrobin weeks to do that with the stock KSP system. I am not familiar with OPM, but basically the KSP system is a bad starting point because the planets are way too light (Jool's mass is about 2/3 of that of Earth and 1/500 of that of Jupiter) so they get moved around very easily. The KSP system is just not very interesting from the perspective of n-body physics. It would be much more interesting to simulate real-life extrasolar planetary systems (these are known to be stable otherwise we would not be observing them). I don't think so, we'll just need to try to reproduce the problem by landing on the Mun with enough logging enabled. (But the fix won't be in the upcoming Cartan release.) Use the FAQs, Luke! As explained above, no. And trying to do that in the game is going to be an awful waste of time. For the stock KSP system @eggrobin used a mix of C++ and Mathematica to efficiently explore the phase space.
×
×
  • Create New...