Jump to content

pleroy

Members
  • Posts

    188
  • Joined

  • Last visited

Everything posted by pleroy

  1. You can ignore these failures. What happens is that we use the mathematical libraries of the platform (libm on Linux) and these libraries deliver different results depending on the hardware (presence of an FMA instruction or not, for instance) and the version of the OS. This leads tu small numerical errors that can trip some of our tests. This should not be problematic for the actual game.
  2. Sure. Make a copy of the en-us.cfg file, name it es-es.cfg, translate all the strings and send us a pull request. Try to use the correct technical terms, e.g., obtained from Wikipedia, not the KSP jargon. (I seem to remember that you're in South America, so es-419.cfg might be more appropriate, but I am not sure that KSP knows about language subtleties.)
  3. This has been asked before, this will be asked again. Please take a look at this post, notably the reply to point #3. Also take a look at the subsequent replies from @Jim DiGriz.
  4. Right, as mentioned in the README there is a single binary for 1.8.1 to 1.11.0. Note that 1.11.1 is not supported yet (but see above in this thread if you got hit by a Steam update). No worries, English is not my native language either.
  5. Interesting. That happens from time to time. When I give VirusTotal the bit.ly link I get Comodo Valkyrie Verdict: Malware and when I give it the .zip file I get, as you do, Jiangmin: RiskTool.CoinMiner.j. The latter seems to be triggered by the glog.dll library that we are using. Antiviruses are full of this kind of false positives. There is not much I can say or do to prove that we are in good faith, other than tell you that the source is on github and you can inspect it and build from it.
  6. Add a cfg file containing: principia_override_version_check {}. Don't forget to remove it once the next version is out: we won't support you if you override the version check (we'll know from the logs).
  7. This has been asked before, this will be asked again... Pretty much the same reasons that were given recently in reply to a question by @R-T-B. Note that system-specific dependencies are particularly bad: since CKAN doesn't know about them (not even to the point of informing the user), 90% of the installs through CKAN would be broken and users wouldn't have a way to find help. See also CKAN issue #1739.
  8. From a quick look at your log, this is probably issue #2853 (which was itself similar to issue #2716). I am pretty confident that I have fixed it (once and for all!) by rewriting the algorithm used to diagonalize the inertia tensor. The fix will be in the next version, Gödel, to be released around Feb. 11th.
  9. This is open-source software, so it is not breaking any rules. This being said, we are not too keen on people posting random builds on the Interwebz: Custom builds typically go through very little testing ("seems to work fine") so non-trivial bugs may be lurking that would cause users to be disappointing/confused/annoyed. For instance, I believe that in 1.11 you can weld parts and store parts in other parts, and this will almost surely require changes to Principia to avoid breaking the laws of physics (even if it doesn't crash, conservation laws are probably violated). Custom builds are harder to support: if someone runs into problems, it might take us some time to figure out that it was a custom build (the logs would tell us that, but most users just report "it doesn't work" without giving the logs). I'd rather spend time on doing useful work than on wild goose chases.
  10. Probably never. Principia is not intended as a general-purpose astronomic calculator (there are much better tools for that), it's trying to add value to KSP. The precession of equinoxes is less than 1 degree per century, it's hard to believe that it would be useful in any game situation. Regardless, this is irrelevant for your tidal locking problem.
  11. So do you really believe that a loop from 1 to 3 is simpler than a loop from 1 to N? What problem are you trying to solve anyway?
  12. Let's ignore for a moment the inconvenience of having to special-case a solar system, of having new code paths to test, bugs that would show up only for some solar systems, etc. The real question is: why would anyone want to trade CPU for I/O? Computing a year of ephemeris for the real solar system takes about 10 seconds on an average computer, which means that, in the absence of vessels, we support timewarp at 3'000'000x. A representation based on an existing ephemeris (DE431, INPOP, EPM, etc.) would take tens of megabytes per year. That would require several seconds to load (for mysterious reasons KSP reads saves no faster than 5 MB/s even from SSD). And then we would have to be super-cautious to be consistent with said ephemeris when it comes to masses, geopotential, and the like. For instance, we truncate the geopotential at large distance, we might not be able to do that. On top of this, the real cost of integration is in the vessels: we use a step size of 10 seconds whereas we use 10 minutes for the ephemeris, and many games have dozens of vessels. Difficult enough that we have extensive documentation of the mathematical details, because the code is incomprehensible in isolation. A very insightful comment. We have been working on this thing for 6 years but the first cut of a symplectic integrator took a few days.
  13. Report the bug? I realise that you did so already back in April, but we were not aware that it was still around. We should obviously not have this kind of non-physical behaviour, and when do we try to fix the problem in a timely manner. The difficulties you are experiencing are not a physical consequence of the rotation effects, they probably stem from something that we never did right (tracking of CoM) that suddenly becomes very visible because it introduces funky rotations. We should have both nice rotation effects and flyable planes. Please cut us some slack. Bugs happen, and we try really hard to find them and fix them.
  14. We typically move forward as soon as RSS/RO/RP-1 is available for a version. We cannot keep supporting old versions forever. If you absolutely want to stick to 1.7.x, you'll have to stick to Fuchs. Fine, but this is an RSSVE problem, not a Principia problem: there are hundreds of mods around and we cannot track everyone of them. Have you opened an issue on RSSVE asking them to recompile for 1.8.1? No you haven't. You can, but you'll need to do some work. There is a configuration file for that. There was also a discussion earlier on this thread.
  15. It's a perfectly valid suggestion, in fact it has been suggested before, see #2295. With any reasonable GUI system it would be a 10-minute fix, but not so with Unity's GUILayout which doesn't support such an advanced UI feature. We'd need to program it ourselves and even so it couldn't be on the title bar but it would have to be in the window pane itself, which would probably look odd, and require some repositioning of the current UI elements.
  16. I believe that this is a well-know annoyance of the stock contracts with Principia. They are based on 2-body mechanics (a.k.a. conics) and don't work well in the presence of more complex trajectories. I also believe that KerbalismContracts plans to support more realistic contracts that would work well with Principia.
  17. The FAQs explain how to report bugs. Note that on Linux you'll need version 8 of libc++ and libc++abi. Since Xenial is fairly old, these libraries may not be installed on your system.
  18. This one looks hard. I have just updated the issue above with what we found so far, and I'll keep doing that periodically in case anyone is interested.
  19. This is very likely to be the same bug as in issue 2507, which will be fixed in Fubini. The funny thing is that this bug (which is quite subtle) has been with us for years, and we suddenly got three reports in the last month. Either people are playing with Principia more, or some change in KSP or in some other mod causes the bug to trigger much more frequently.
×
×
  • Create New...