Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by pleroy

  1. On 8/19/2019 at 8:20 PM, AloE said:

    cloned the KerBalloons source, made the edit you recommended, built the dll, flew a high balloon with Principia (TRAPPIST1) ;-) 

    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.

  2. On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

    I'm planning to do my own realistic-ish trinary stellar system, using α Centauri ABC as a real-life counterpart - I think it may bring some interesting dynamics with it, including highly chaotic trajectories, hyperbolic transfers between subsystems, etc.

    That's why I have a couple questions.

    1. Do you move the Sun or is its position fixed?

    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.

    On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

    2. Does Principia work good with large distances? I intend to place the farthest companion star at some 8'700 au from the barycenter of the other two. If it's unsupported, maybe there're any known workarounds?

    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.

    On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

    3. (Not related to the trinary project) Is anyone currently working on station-keeping? If no, I will probably implement some frequent use cases over the next couple months and send as a PR.

    I'm afraid that you might be underestimated the complexity of station keeping.  At least the following problems need to be solved:

    1. 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.
    2. 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.
    3. 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.

    On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

    4. I tried Principia on my laptop, and it doesn't work as fast as the first post says it should. To be specific, in stock KSP with no other mods and with the only vessel launched, 10'000x timewarp runs smoothly, but 100'000x looks like 20'000x, and the UI is lagging. Given that I'm using the top model MacBook (the one with core i9), I'm surprised. Should I file a bug or the MacOS performance is not prioritized?

    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".

  3. 43 minutes ago, Rufferal said:

    I've compiled for 1.7.2 and the build succeeds, however I'm getting a System.BadImageFormatException on startup. I'll say I'm not familiar with this toolset or modding KSP so I may have missed something. Can anyone point me in the right direction?

    The right direction in this case are the FAQs.

  4. 7 minutes ago, ZAJC3W said:

    Could it be caused by VS2019 preview 2?

    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.

  5. 22 hours ago, ZAJC3W said:

    Firstly you need VS enterpise edition

    Good point, I'll update Setup.md to clarify how you can build with other editions of VS.


    then you have to install Windows SDK 10.0.18362 manually, VS installer won't include Windows debug tools

    I'll mention this requirement too.  Note that you can install the SDK from the Visual Studio Installer by selecting "Universal Windows Platform development" and selecting it in the list of components (for some reason the default is 10.0.17763.0).


    then you will find that included build scripts expect vesion 16.2.0 preview 1 of  VS( VS 2019 is in version 16.1.2  )

    As is documented in the Setup.md file.


    you load up principia.sln only to find that some source files are missing and you need references to unity dll.s that not come with KSP.

    These DLLs are/were necessary on Mac I think.  In Windows they just produce warnings, they should not get in the way of building.


    after some script modification(explicitly pointing to msbuild.exe and commenting out google dependencies) i'm stuck on 

    This is your problem right here: you need to download and build the Google dependencies.  As @drake127 pointed out, in your first post you were missing the proto compiler, and in the second the glog libraries.

    5 hours ago, ZAJC3W said:

    F.F.S just noticed, chromium source code uses unix path format ( '/' instead of '\') how on earth this supposed to ever compile in windows?

    Windows knows how to interpret / in paths in includes and other places.  Otherwise how could you hope to write C/C++ code that can reasonably be ported from Linux to Windows or vice-versa?


    even after repaiging google file paths i'm getting wall of errors, soem of fthem below.

    If you are "repairing" the source you are heading towards a world of pain.


    I'm close to throwing my keyboard trough the window.

    Following more closely the instructions in Setup.md would make you happier I think.

    Ah, and I forgot to mention: use the master branch, not the Fatou release, to build with VS 2019.  Fatou was still built with VS 2017.

  6. 7 hours ago, Einstein_Cross_X1 said:

    Are there any plans to add build support for Visual Studio 2019 now that VS2017 is no longer supported by Microsoft? 

    No longer supported?  Microsoft seems to differ, Visual Studio 2017 version 15.9, which we use, has a mainstream support end date of April 12, 2022.

    I have started looking into Visual Studio 2019, and the migration seems quite smooth, but in the past these things have ended up taking weeks: we need to update our tooling, check for performance regressions, report any bugs that we may find, etc.

    While it makes sense to use the latest greatest version from Microsoft, it's not like it's tremendously useful: we can hardly use C++17, not to mention C++20, because Mac has an antiquated version of Clang and libc++, and we need to be able to build on Mac.

  7. 2 hours ago, N9vaivie said:

    Hello! This is not a bug per se, rather something I've noticed recently with Flight Planning. When a maneuver is planned, IF your history length is very low, the time to ignition will continuously reset causing the actual maneuver node to move. So distant maneuvers cannot be planned unless the history length is long enough to reach the exact moment the maneuver was created. It'd be cool if long histories were not needed for this! Cheers

    It is actually a bug, it has been reported a few days ago (#2154) and will be fixed in the June release.

  8. On 5/6/2019 at 9:14 PM, Krzysztof z Bagien said:

    It would be nice to set that separately. I have KSP interface scaled up (120% I belive), but would like Principia windows to be smaller - they are already quite big, and now main window and flight plan with single maneuver take half of my 1920x1080 screen :(

    The two scales are multiplicative so setting the App Scale to 83% would cause the Principia window to go back to the normal size.  It seems that at least some mods do it that way.  Of course, it's hard to know if it's how Squad intended it...

  9. 5 minutes ago, Flibble said:

    I'd like to be able to read the flight planning data, e.g. time to next manoeuvre, direction, etc. This seems to be available via the interface already, but not exposed to C#. I was looking at just calling the dll exports directly, but adding them to the external interface seems a neater way to do it.

    The external interface is the only API where we will guarantee stability and compatibility.  The rest is entirely internal and should not be used by other mods.  Can you open an issue on GitHub to track this?

  10. 1 hour ago, Flibble said:

    Hello Principians,

    I'm looking to integrate Principia's flight planning into my kOS based flight computer. I noticed that the API isn't implemented yet according to: https://github.com/mockingbirdnest/Principia/wiki/Interface-for-other-KSP-mods

    Is there any WIP code for this? Or should I just crack on and write it myself? I'm happy to do that, but would rather not duplicate existing work if there is some.

    The comment on top of that page is outdated: I just removed it.  The API is available starting with Fano.  Note that as things stand it only gives you the parameters of the geopotential model.  If you have other needs we would like to hear from them to understand how to best address them.

  11. 6 hours ago, RocketSquid said:

    Okay, a few questions, since I know adding principia to an existing save will break it.

    1. Will removing principia from a save break it to the extent that adding it does, or will the issues be less severe?

    The issues should be more-or-less the same: the planets and vessels will be at semi-random locations.

    6 hours ago, RocketSquid said:

    2. Will deleting and reinstalling principia (in order to update it) without opening the save in between break the save?

    This will have no effect other than upgrading Principia.  The saves will remain compatible (we maintain compatibility for years).

  12. 1 minute ago, Delay said:

    I believe you're referring to multiple maneuver node editing here?

    I was referring to the fact that Maneuver Node Evolved apparently let you snap a manoeuvre to the apoapsis or to the closest approach, etc., which would remove quite a bit of annoying hand-tuning.

    1 minute ago, Delay said:

    The problem of "What controls the timewise placement of a maneuver?".
    Why not determine the time of a maneuver based on previous nodes? As in "Maneuver 2 is 4 hours after maneuver 1"?

    Yes, this is what we'll do in the next version, if only because editing the field that counts down was not going to work.  As for editing multiple manoeuvres, it's something that I'd like to do but it goes pretty deep.

  13. 1 hour ago, Krzysztof z Bagien said:

    This mod is great, but I have one big gripe with it: sliders. Would you consider adding something different than those sliders to adjust maneuver deltaV, time, etc.? Sliders look like a good idea at first, but I find them really cumbersome and it takes a lot of time to get what I want with them.

    The next version (May 4) will have text entry fields in addition to sliders for the Δv and time.

    1 hour ago, Krzysztof z Bagien said:

    Something like in Maneuver Node Evolved manual deltaV input window would be way easier and convenient to use.

    Not familiar with that mod, but it does look cool.  Snapping manoeuvre nodes to "interesting points" of the trajectory is something we have in mind, but it's far from trivial.

  14. @Einstein_Cross_X1: A possible way to make progress would be to clone the test we use to check the stabilization of the KSP stock system and adjust it for the system(s) you are interested in.  It would make it reasonably quick to experiment with various tweaks of the system.  The drawback of course is that you'd need to build Principia (instructions here) and then do some C++ programming.

  15. On 3/16/2019 at 1:14 PM, RealTimeShepherd said:

    Is there anyway to have the RPM (IVA) Navball change in the same way as the game navball?

    Ideally I would like to use exclusively IVA controls and the Principia navball changes currently do not seem to affect the navball that you bring up on internal MFDs

    We should definitely replace the navball in IVA.  I have created #2099 to track this.

    The interaction with RPM is another kettle of fish entirely.  I don't think that we want to start having dependencies on other mods.  I guess we could expose an API to read the orientation of the navball, and then other mods could use that orientation in their processing.

  16. 10 minutes ago, Xurkitree said:

    @eggrobin Could you please change the names of the zip files themselves? They cause errors on opening because of all the greek letters, because winRAR atleast doesn't recognise the zip as a valid zip file. Changing the name removes this problem.


    @Xurkitree: The year is 2019, please use tools that support Unicode.  FWIW we use 7-Zip to produce the archives.

  17. 16 hours ago, Delay said:

    @pleroy I don't think that what I'm describing here has changed over the past few releases, so I'll still post it.

    Hmm, this has been reported by @scimas a long time ago (#1868) but somehow it fell off our radar screen.  We have code to set the markers but apparently it stopped working with some KSP upgrade.  We should try to figure out what's happening.

  18. @Eriksonn:  It is completely feasible, but it requires some understanding of the way geopotential modeling works.  You don't directly use the altitude.  Instead you specify coefficients (conventionally named Cnm and Snm) for spherical harmonics of various degrees and orders.  This image gives an intuition of what the spherical harmonics look like (the poles are on the left and right, the equator is vertical on the image).  For instance, degree 2 order 0 makes it possible to put more mass at the poles and less at the equator or vice-versa; degree 2 order 2 makes it possible to put more mass at Greenwich and Fiji and less in the Appalachians and Himalayas, etc.  Unfortunately the Wikipedia article on Geopotential model is rather lame, so I recommend looking at section 6 of the IERS Conventions.

    In practice you'll need to write a custom principia_gravity_model configuration covering (at least) the body for which you want to specify the geopotential.  This configuration is described here.  Look in particular for geopotential_row and geopotential_column.

  19. @Agustin: You would notice differences if you were trying to replicate very accurately real-life missions: the old geopotential would exhibit drifts of hundreds of kilometers over a few months to a few years depending on the altitude.  Things will get more interesting though when we extend this to the Moon, where the geopotential is very weird and affects orbit stability, or to Mars, where the position of Phobos and Deimos is currently bogus.  More to come in future versions: stay tuned.

    @Someone2018: We started working on this in August.  Making it correct was the first challenge, and then making it fast was even more interesting.

  20. Thanks for the nice videos @AloE, and thanks for reporting the problem with 1b.

    I believe that I understand what is happening: there is a stupid mistake whereby the configuration of the integrator used in the game differs from the one we used to do the transit-time variation optimization.  For the transit at JD2457721.38747, the former produces an effective transit at 20:34:47 (pretty much what you observe), the latter an effective transit at 21:18:08 (pretty much the correct value).

    Note that this probably tells us that the integrator is not converged for 1b, presumably because the step size we used is too large.  Darn, we'll need to rerun the optimization...

    Created #1999 to track this.  Follow the music there.

  • Create New...