Jump to content

pleroy

Members
  • Posts

    185
  • Joined

  • Last visited

Posts posted by pleroy

  1. 13 hours ago, HereComesTheBoom said:

    I have tried to figure out how to install your custom config in to my GameData folder in order to correct Bop, Vall, and Tylo, but I can't ever seem to get it working

    The Kopernicus configuration here needs to be put somewhere in the GameData folder (anywhere), and to have the extension .cfg.  You should not have to mess with anything else.

    One important point is that you must create a new save.  The configuration of the solar system is recorded in the save the first time it is created, and the .cfg files are not re-read after that.

  2. On 11/29/2023 at 11:08 AM, Krazy1 said:

    One thing that's still baffling is the dramatic change in frame rate between landed and in flight. It's literally 10 FPS in flight and the instant it touches down it's 30 FPS . Vacuum or atmosphere, doesn't seem to matter.

    Believe it or not, we don't do N-body physics for landed vessels.

  3. 5 hours ago, CobalTech said:

    I'm sorry if this has been asked before, but is there a version of Principia that simplifies its complex physics slightly? Potentially one that only retains the interactions that celestial bodies have on crafts? For my playstyle the gravitational interactions that celestial bodies exert on each other, as well as crafts on other crafts, or crafts on celestial bodies are not integral.

    Would removing those physics interactions improve performance? And does a version of Principia that does so exist? Thank you!

    There is no "simplified" version of Principia and there won't be because the time is not spent where you think it is.  The interactions between celestial bodies cost virtually nothing: we can compute about 6 months of interactions per second, which corresponds to warp 15,000,000.  Nobody is limited by that.

    The problem with large spacecrafts is that Principia needs to position every single part at every frame.  If your vessel has, say, 1000 parts, that leaves us with 40 μs for each part.  That's not much, and sure enough we will sometimes slow down the game.

    We are aware of the problem and there is an issue for that (#3230) but unfortunately, there is no easy solution.

  4. 38 minutes ago, Wilds said:

    I enabled journal... I compressed it in 7zip format. If that is an issue, I can reupload.

    https://www.mediafire.com/file/rkwgtdinquz85f5/JOURNAL.7z/file

    Thanks.  I created issue #3697 to track this.  I verified that I could uncompress the journal.

    PS: Don't expect a quick resolution, it's a big journal and probably a hard problem.

  5. 3 hours ago, mateusviccari said:

    Does this affect time warp speed?

    Maybe.  Maybe not.

    First, the speed-up only concerns the rotating-pulsating frame where we display equipotentials.  Second, if you have many cores, it won't make much of a difference, equipotentials will burn some of your cores but won't affect interactivity.  So we are left with the case where you don't have many cores (2-4) and you display equipotentials, then yes, there will be an improvement on warp speed.

  6. 1 hour ago, Wilds said:

    This is not the log that we need.  As a matter of fact, for such a tricky bug we'd need a journal taken while the problem happens.  Details here.

    ETA: We would actually very much like to be able to investigate this issue.  We have had a report years ago of a similar problem but we never managed to get to the root cause.  Interestingly, there was a Service Module.  So maybe that tells us something.  You would help us greatly by providing a journal.

  7. 1 hour ago, cygnus008 said:

    Had Principia been tested with Ventura or am I missing something.. I am not a c++ programmer . Just did Oracle DBA stuff for a really long time :)

    We don't test on macOS as we don't have access to macOS machines.  We just build for it.

    There are people using macOS on the Principia Discord channel.  You might try to ask there.  We haven't heard of problems so far, so it might be your install.

  8. 27 minutes ago, jd284 said:

    Do these have to get recalculated from scratch every frame, or do you use the previous frame as initial condition and only make small adjustments each frame?

    We constantly recompute them, but not at every frame, because it takes may be one second to do the computation.  You might observe that they update in a somewhat janky manner.

    And we don't try to do things incrementally, because that way lies madness.

    28 minutes ago, jd284 said:

    It sounds like this computation is somehow much slower on my computer than it should be. I've noticed the FPS also scales very strongly now with the prediction steps setting, at 6.4e1 or below it's above 10 fps in the EML frame, and at 1.6e4 it's down to 1-2 fps. In other frames I have 40+ fps all the way up to 1.6e4.

    That's good feedback.  I'm sure that there is room for optimization, but getting something out was our priority.

  9. 1 hour ago, jd284 said:

    I absolutely love this, even though it kills my FPS dead (from 45 to less than 2). Is there some setting to reduce the number of equipotentials? I would really only need two or three; the ones "crossing" at L1/L2 and possibly those around L4/L5. The other ones are nice for sceenshots though.

    How many cores do you have?  The equipotential computation is completely asynchronous so it should be invisible if you have enough cores.

    We will work on optimizing the equipotential computations in future releases.  However, I don't see us having a setting for the number of equipotentials, the heuristics to decide what to plot is already complicated enough.

    Edit: Actually, computing the equipotentials is cheap (comparable to computing trajectories, which we do much faster than 50 fps for a single trajectory).  The really expensive part is the computation of the maxima of the potential, because that's a global optimization.  But the whole point of the feature is to locate these maxima, so there is no easy way out.

  10. On 11/3/2022 at 11:33 AM, chankloong said:

    Today, I updated version 12.4. I found that after Principia was installed and all files were loaded, ksp was automatically closed. This MOD is the second most important MOD for me except RSS. I use translation software because my English is poor. I don't know if you can understand it

    There is a mechanism to override the version check.  No support if you do this.

  11. On 9/14/2022 at 6:39 PM, mhoram said:

    Do I understand it correct, that Principia takes over the physics of part-movement? If so, is it possible to switch off that functionality and just keep the N-body-orbital movement active?

    Technically, Principia doesn't quite control the movement of parts.  It does control the movements of parts-that-are-in-contact-with-each-other (we call these things "pile-up") and let KSP do the part placement within the pile-ups.  There is no way to separate this from N-body physics because precisely N-body physics is the integration of the motion of pile-ups.

    On 9/14/2022 at 6:39 PM, mhoram said:

    This picture below shows my problem. Initially, the parts (stock + USI-mods) were all aligned to each other, but over time they diverged more and more.

    At least, that's a nice picture :confused:.  But obviously, it's not supposed to happen.

    Ideally, if you could reproduce the problem with the stock game and give us a save, that would be great.  If not, I would suggest looking at the mods that you use and see if any one of them believes that it can change the location of parts; mods that do this are typically incompatible with Principia (see the FAQs for details).  You can try removing the mods one-by-one to determine which one interacts with Principia.

  12. 1 hour ago, yomahabaca said:

    Is this normal? A ship in a perfectly circular orbit would be supposed to always stay at the same geocentric speed, wouldn't it?

    Believe it or not, the Earth is not a perfect sphere.  It is flattened at the poles (oblate) and it has mountains and oceans that make its gravity field inhomogeneous.  Principia simulates this, so for instance geostationary orbits are only stable in some places (over India and Mexico), elsewhere they need stationkeeping.

    The effect you are seeing is mostly due to oblateness.

  13. 5 minutes ago, DA299 said:

    Thanks, the gravity model should be pretty easy to change, however the initial state is something which would take quite some time. I just wanted to ask, did you make the initial state manually, or is there some kind of calculator that you used (For the 6 values.)?

    For the real solar system, it's quite easy, we used the JPL Horizon System which gives us real-life numbers.  For a fictitious system, however, things might get more challenging.

  14. 23 hours ago, DA299 said:

    How might one go about making Principia configs for a planet pack(KSRSS)? Just looking for someone to point me in the right direction, won't ask for any help if the configuration isn't stable. 

    The configuration files which are used to describe a solar system are documented here.

  15. 2 hours ago, justaRegular911 said:

    Hello, is the latest version( "Hesse") not compatible with KSP 1.12.0? I tried to run it, and it gives error in KSP/glog. If so, what is the last version compatible wit 1.12.0

    There was never a version that supported 1.12.0.  Any reason why you couldn't upgrade to 1.12.3?

  16. 16 hours ago, MAFman said:

    I'm really confused about the interface. I'm just trying to get something into the Kerbin-Sun L2 Lagrange point, and I have no clue what I'm doing.

    Have you read the concepts page and taken a look at @rsparkyc's tutorial?  I'd suggest doing so before randomly clicking buttons.

  17. 5 hours ago, Makrom said:

    The version 2022020106-हरीशचंद्र (whatever that means)  is the last one that gives me a stable gaming with no abnormal issues using MJ2 2.12.3 , and it is the version that I use on my installs now.

    Just to clarify: are you saying that हरीश चंद्र works for you but Hausdorff (the version immediately after) does not?  That's interesting to know and quite puzzling as there were very few changes in between.

  18. 1 hour ago, Ned000 said:

    So the question is? Is there a recent version of Principia that will work with libm.so.6 v2.24 `GLIBC_2.24'?

    I think you'll have to try progressively older versions of Principia (older download links can be found in the history of README.md on GitHub).  We are building on Ubuntu 20.04, which apparently pulls this version of libm.  I believe that the last version built on Ubuntu 18.04 (which may or may not have the version of libm you need) was Hardy.

  19. 1 hour ago, Ned000 said:

    Hi, The latest Principia.hermite won't load on my system Debian9.13. Which uses libc++1:11.0.1-2~deb9u1 & libc++abi1:11.0.1-2~deb9u1. I am using running KSP-v1.12.3.

    You have version 11 of the libraries, we require version 8, so that should not be the problem.  Is there any useful message in KSP.log?

  20. On 5/8/2022 at 1:55 AM, SquirrelBomber said:

    The Principia DLL failed to load.
    An unknown error occurred; detected OS Unix 5.15.0.27 64-bit; tried loading dll at 'GameData/Principia/Linux64/principia.so', 'GameData/Principia/MacOS64/principia.so'. Note that libc++abi1-8 and libc++1-8 or later (Linux) or Sierra or later (MacOS) are required.

    Warning: don't load a Principia save before you have fixed this error; it might get damaged.

    So, do you have libc++abi1-8 and libc++1-8 (or later) installed?  If so, which version?

×
×
  • Create New...