Jump to content

pleroy

Members
  • Posts

    184
  • Joined

  • Last visited

Everything posted by pleroy

  1. @Jesusthebird: So I suspect that Sigma is the culprit here. From what I understand it's trying to do binary systems using the cheezy physics of the stock KSP. To do that it creates a bogus body at the barycentre of Duna and Ike. Then Principia comes along and tries to apply real physics to this mess. This is not going to end well. Even if we did not crash, the barycentre body would be shoved around and would not stay where Sigma wants it to be. It should be possible to design real binary systems and Principia would make them work naturally, although as usual finding a stable configuration may be tricky. The bottom line is that Sigma and Principia are mutually exclusive.
  2. Thanks for the logs. From a quick look at them it seems that you are using a nonstandard solar system (I suppose that some mod does that for you) in which there is a celestial named DunaIke that has a zero rotational velocity. This is not something that we support. I don't remember the exact reason for rejecting this (I think it introduced unnecessary complexity) but it is never something that happens in real life: planets are not inertially fixed. Do you have any idea what mod or config change could cause this?
  3. @Jesusthebird: We'll need the Principia logs to investigate. Please see the FAQs for how to report problems. Basically, what @scimas said... Are you sure that you have downloaded the version of Principia that's for 1.3.1? If you pick the version for 1.2.2, it will crash in mysterious ways.
  4. The reasons are a bit lost in the mists of time. I vaguely remember that when we started Principia 4 years ago, CKAN had limitations that were problematic for us. Also, we were only targeting Windows at the time and CKAN didn't support mods that wouldn't work on all platforms. It's possible that all the problems have been solved since then, and it's just a matter of writing a configuration. There may be minefields, though: for instance I see that they recommend to use ASCII digits and letters in the version names, but we take great pride in using all the possible writing systems in our version names.
  5. I think this is documented in the FAQs: if you have more planets than the basic RSS, the game will crash. You could confirm this by looking at the log files. Even if it didn't crash, it's unclear if RSS Constellations would work well with Principia as the floating-point granularity would become problematic when you move very far away from the main solar system.
  6. The bodies are modeled as oblate spheroids. We only go to the J2 term, and this introduces some inaccuracies for celestials where S22 or C22 are large (Mars is one example, and the orbits of Phobos and Deimos are significantly off). No higher spherical harmonics or gravitation maps as the force computations are in the critical loop and have a very tight CPU budget.
  7. @hypervelocity: This is a question that gets asked all the time. The answer is that you cannot do that, Principia doesn't let vessels exercise a force on celestials. That would be very expensive to compute and pointless as demonstrated by Scott Manley here.
  8. Yeah, this has been suggested before, see issue #947. The reality is that: We are not UI people so we are not very motivated to invest lots of times in the UI when we could be playing with numerics or astronomy. As is customary with UI, things get sticky when you look at the details, and everybody has their own opinion as to how it should work. Unity is somewhat limited in the kind of UI devices that it lets you build. So don't hold your breath. On the other hand, we would welcome contributions in this area: it's fairly isolated from the rest of Principia and could be developed/improved independently .
  9. @Bosun: The stabilization of the Jool system was introduced in Brouwer around February 2016. We have a regression test to make sure that it is not lost when KSP or Principia evolves, so I'd be surprised if it had vanished in Christoffel. Two observations, though: The stabilization only works for the stock solar system. If you have any mod that does any modification to the stock system, Principia won't try to stabilize Jool. In the case of a mod that just adds more celestials, the FAQ has some information about how to stabilize Jool. For more general changes to the system, you're on your own. If you are using a very old save, the Jool stabilization may not be present in the save. You'll need to start anew.
  10. @Jim DiGriz: So at some point @eggrobin and I looked into the TRAPPIST-1 system, where quite a bit of data is known. There is a significant amount of work needed to go from the Nature paper to a proper KSP configuration, but I suspect that it would be great fun. We might decide to do that in some upcoming release.
  11. @Jim DiGriz has actually a very good point. For things like station-keeping and orbital decay, code would need to be executed inside the inner loop of the integrator. The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved). Everything would need to be done in C++ using the Principia abstractions and linked into the Principia DLL. When you do this, well, you are just beefing up Principia and not interfacing with another mod. I am not saying that we won't be doing this one day, but not using 3rd party mods. The interested reader might want to look at the PRs that fix #1628 in the new Christoffel release. It took me many pull requests and close to three weeks to just figure out if a vessel is inside a celestial during the force computation and bring that information up to KSP.
  12. @itsthatguy: You must be new to mod development. See, developing a mod is quite a bit of work, and it takes some dedication to keep spinning out releases to fix bugs, add improvements, and generally address user feedback. Now add to that the issues that arise because of coexistence with other mods; we get a fair number of reports along the line of: "I am using mod XYZ and it causes Principia to crash"; this is hard to debug and sometimes require that we sync up with the other mod authors to understand what's happening or to get them to change their code. Also add the fact that different mods are on different release cycles: we support KSP 1.2.2 not because we love it but because RO is not on 1.3 yet; it does make our release cycle significantly more cumbersome. The bottom line is that there is no way that the authors of three distinct mods can coordinate and synchronize to come up with a consistent design and implementation to make those mods work together smoothly. The overhead would just be overwhelming; and, to be honest, it's not the fun part of mod development. As @scimas said, having an API would help to some extent, but so far no-one has volunteered to help with that work.
  13. @lawndart, @影之瑒: Thanks for the reports. It seems that the capability to start/stop Principia has decayed over time. It was useful at the beginning of the development, when the mod was experimental, but it has probably overlived its usefulness. In particular we know that running without Principia and re-enabling it causes no end of trouble because KSP and Principia get into inconsistent states. I have created #1643 to remove this capability.
  14. This is not a known bug. We'll need you to open an issue on Github and give us your complete logs to investigate, as explained in the FAQs. Don't read too much in the similarity to #1561, it's unlikely to be the same problem because the code has changed quite a bit. Also, the glog message that you mention is innocuous.
  15. That would be a lot of work. Such a mod would have to use the Principia APIs directly. This would be a nightmare because our APIs are quite complex and not-very-well documented, and we change them all the time; we are just not prepared to provide documented and stable APIs to the outside world; also, the autopilot mod would have to be written in C++. To put things in perspective, Principia has about 75,000 lines of hand-crafted C++ and another 25,000 lines of automatically generated C++. Understanding how it all works is not for the faint of heart.
  16. It would be cool if you could open an issue for this on github. Easier to track for us and to incorporate in the release notes, etc. The work-around was actually in RSS, so it only applies to the Moon. The underlying issue is still open, but it will take a while to fix.
  17. The .d files (not folders) are created automatically by make early in the construction and contain dependencies between the units. Are you sure that you have write access to the directory/ies where you downloaded Principia? I have seen problems with the .d files when I had forgotten to run sudo.
  18. 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.
  19. 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.
  20. 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...
  21. Good point. We are creating a new thread (below) to help people who want to build Principia themselves. @Rory Yammomoto@HebaruSan
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...