[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[eggrobin]

3 hours ago, Damien212 said:

Hi,

I'm having an odd issue with Principia that I can't seem to nail down.

While playing RSS/RO with Principia (latest releases as of today), during a mission similar to Explorer I (rocket booster stage, coast to apo, chained SRB to orbital velocity) the SRB stage was suffering from what looked like misaligned thrust, pulling the craft from orbital prograde, towards radial-out with reference to Earth. While trying to diagnose the problem I tried the following:

• Delete/Fresh install of KSP, with RSS, RO & dependancies as per CKAN latest. Also FASA for test craft. Principia as per latest on github. - no change
• Spin stablization of SRB stage - no effect. craft nose still pulled towards radial-out causing spin.
• Disabling/reenabling of RCS/SAS - no effect (not installed on craft anyway)
• SRB stage activated while pointing retrograde - no effect, nose still pulled towards radial-out causing spin.
• SRB stage activated while pointing radial-out - no alteration of vessel orientation, remains pointing radial-out
• Craft (FASA Juno/Explorer I craft file sergeant SRB stages as per github) replaced with alternate model to rule out FASA part issue - no effect, procedural parts SRB with a MK1 crew capsule on top exhibits same issues
• Noticed Moon was directly above launch site, timewarped Moon to other side of Earth before launch to rule out weird gravity effects from Moon - no effect.
• Force stopped Principia before stage ignition - issue eliminated, works as expected
• Force started Principia again before stage ignition - issue returns.

The only constant I can find regarding this issue is that it only occurs when thrust is applied out of atmo. At 139,999m everything works as normal, at 140,000m+ the problem appears. If you start a burn in atmo, and the burn continues across the boundary, the issue takes effect only from the moment the craft passes the boundary.

The craft I was testing has 3x SRB stages to push Explorer I into orbit. During the first burn towards orbital prograde, the craft noses upwards, towards radial-out and then towards orbital retrograde, putting it into an anticlockwise spin if viewed from south to north. If this was asymmetric thrust or a simple spin, you'd expect the spin to continue in the same direction if you ignited the second stage when pointing retrograde. This doesn't happen. Instead you can start the spin anticlockwise with stage 1 ignition when facing prograde, ignite stage 2 during the spin when at retrograde, which changes the direction of the spin to clockwise towards radial-out and prograde, then ignite stage 3 at prograde again to reverse direction. In all cases the craft spins towards radial-out during thrust.

 

I recorded several attempts at performing the maneuver as per the above list. The video is here: https://www.twitch.tv/videos/148710758

My KSP.log is here: https://www.dropbox.com/s/0tvzdx4spaw0lm7/KSP.log?dl=0

Any ideas? 

 

 

Very interesting; this seems to be a manifestation of 1307; the fact that it occurs without physical timewarp in RSS might be a helpful clue; can you add your report to that issue so everything is in one place?

[Damien212]

39 minutes ago, eggrobin said:

Very interesting; this seems to be a manifestation of 1307; the fact that it occurs without physical timewarp in RSS might be a helpful clue; can you add your report to that issue so everything is in one place?

No problem. I've copied it over. Are there any workarounds in the meantime?

[pleroy]

On 5/30/2017 at 9:57 PM, GrahamsNumber said:

Okay, so, quick question: How long will you guys support 1.2.2? Given that 1.3 (again) wiped out most of the mods (many of them crashing right now, see link below), I am hoping that 1.2.2 gets supported for a while longer, so we can enjoy the many mods that are available for it (including, finally, FAR!)

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.

[msnbcorp]

Hum, according to my own list that include most of the main common mods, there is currently more than half of commons mods that have moved to 1.3. It seems that migration in this case just took recompilation and checking in most case. Maybe it could take very little time to your team ^^ . It remain to be seen though...

 

edit : beside : RSS works with KSP 1.3 now :

 

Edited June 2, 2017 by msnbcorp

[Damien212]

On 6/1/2017 at 8:33 PM, eggrobin said:

Very interesting; this seems to be a manifestation of 1307; the fact that it occurs without physical timewarp in RSS might be a helpful clue; can you add your report to that issue so everything is in one place?

Hi again, I've just noticed this bug is now fixed

Is there a way for me to build the mod from the latest, fixed version? Or is there a binary copy I could download?

Thanks!

[pleroy]

8 hours ago, Damien212 said:

Is there a way for me to build the mod from the latest, fixed version?

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.

[Damien212]

20 hours ago, pleroy said:

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.

Those instructions look massively tl;dr

I'll wait for Cauchy.

[Rory Yammomoto]

What would it take to recompile this mod for 1.3, if it is possible, on Linux? I'm assuming it's not just a case of 'recompile against the latest versions of KSP's dlls', given how much this mod changes.

EDIT: I was going to try and answer my own question here, but I cannot; Linux cannot run VS, MonoDevelop refuses to use Principia's .sln file (Opting instead to crash), and I cannot do as the instructions say, for I have no Powershell, and therefore cannot run .ps1 files. Adding to that the fact that I'm probably going to be building a 'useless' Windows version,  I'm just going to say 'NO.' here, and run away as fast as I can from the hot mess I made.

TL;DR: DO NOT BUILD THIS ON LINUX WITH THE WINDOWS INSTRUCTIONS.

Edited June 6, 2017 by Rory Yammomoto

[pleroy]

1 hour ago, Rory Yammomoto said:

TL;DR: DO NOT BUILD THIS ON LINUX WITH THE WINDOWS INSTRUCTIONS.

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.

[HebaruSan]

39 minutes ago, pleroy said:

how hard it would be for someone who doesn't know where all the traps are.

Possibly somewhat challenging:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/wily64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'ubuntu/wily64'
    default: URL: https://atlas.hashicorp.com/ubuntu/wily64
==> default: Adding box 'ubuntu/wily64' (v20160715.0.0) for provider: virtualbox
    default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/wily64/versions/20160715.0.0/providers/virtualbox.box
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

The requested URL returned error: 404 Not Found

Not having any more luck with the Makefile natively.

[Rory Yammomoto]

2 hours ago, HebaruSan said:

Possibly somewhat challenging:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/wily64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'ubuntu/wily64'
    default: URL: https://atlas.hashicorp.com/ubuntu/wily64
==> default: Adding box 'ubuntu/wily64' (v20160715.0.0) for provider: virtualbox
    default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/wily64/versions/20160715.0.0/providers/virtualbox.box
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

The requested URL returned error: 404 Not Found

Not having any more luck with the Makefile natively.

I think I am?
I've been running through the Dockerfile, actually - just running the commands in a normal shell instead of letting Docker f uck up. I can get to the part where I make, but then.... I get a bunch of things telling me that they want things that are in a 'build' folder that doesn't exist. Changing 'BUILD_DIRECTORY :=' from 'build/' to './' gives a whole bunch of different things it claims doesn't exist, seemingly the same files that are actually there, but ending with '.d'. I'm starting to think that we don't have enough of the things for it to work properly.

Edited June 6, 2017 by Rory Yammomoto

[eggrobin]

@maccollo posted a trajectory optimization challenge that may be of interest to the readers of this thread; my attempt is 959 m/s, it should be possible to do much better than that.

 

[snigavik]

On 06.06.2017 at 10:57 PM, HebaruSan said:

Possibly somewhat challenging:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'ubuntu/wily64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'ubuntu/wily64'
    default: URL: https://atlas.hashicorp.com/ubuntu/wily64
==> default: Adding box 'ubuntu/wily64' (v20160715.0.0) for provider: virtualbox
    default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/wily64/versions/20160715.0.0/providers/virtualbox.box
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

The requested URL returned error: 404 Not Found

Not having any more luck with the Makefile natively.

Try editing Vagrantfile config.vm.box to use any actual working wily64 box, sgallen/wily64 worked well for me. Not sure if it been built successfully (some console logs here https://pastebin.com/CvRhWWh8) though.

Edited June 11, 2017 by snigavik

[bEAstmode]

Is it possible for one to change the orbits of the stock planets using hyperedit's orbit editor and use principia to simulate? Ive tried this but they seem to be stuck to their positions.

[pleroy]

On 6/13/2017 at 3:02 AM, bEAstmode said:

Is it possible for one to change the orbits of the stock planets using hyperedit's orbit editor and use principia to simulate? Ive tried this but they seem to be stuck to their positions.

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.

[Rory Yammomoto]

On 6/11/2017 at 5:37 AM, snigavik said:

Try editing Vagrantfile config.vm.box to use any actual working wily64 box, sgallen/wily64 worked well for me. Not sure if it been built successfully (some console logs here https://pastebin.com/CvRhWWh8) though.

It doesn't work. it keeps angrily saying that the .d directories do not exist.

[bEAstmode]

4 hours ago, pleroy said:

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.

So if i wanted to simulate I would have to change the orbits of the celestial bodies directly not using hyperedit?

[Rareden]

having an issue with the flight plan prediction line only drawing a very short area ahead of the craft.

[snigavik]

14 hours ago, Rory Yammomoto said:

It doesn't work. it keeps angrily saying that the .d directories do not exist.

Logs might help (but i'm not sure if it's ok to pile Vagrant issues in this thread).

With "KSP Assemblies" put according to windows compilation instructions i've managed to successfully build from Github and run this mod on Linux, "make" exited with 0 and Principia looks functioning in game.

[scimas]

6 hours ago, Rareden said:

having an issue with the flight plan prediction line only drawing a very short area ahead of the craft.

Assuming you're new to the mod. There is a slider at the top of the flight plan window for the plan length. Increase it to get longer predictions.

[Rareden]

7 hours ago, scimas said:

Assuming you're new to the mod. There is a slider at the top of the flight plan window for the plan length. Increase it to get longer predictions.

aaah ok, thanks, was just going off the tutorial

[scimas]

I've been noticing a bug recently, but haven't been able to reproduce it on demand and so haven't opened an issue on github. I will detail it here, perhaps you can figure it out.

Sometimes, when I return to kerbin from space (the point where the calculation of the trajectory goes from principia to ksp), if I'm time warping, the orbit gets set to ~265000 m x ~63000 m. So I've just burned retrograde, the plotting frame set to kerbin surface fixed, the apoapsis and periapsis reported by both principia and kerbal engineer are around 80000m and 10000m, respectively. I start timewarping. The 70000m atmosphere encounter stops the time warp and suddenly my orbit is set to that weird one.

I tried to reproduce it multiple times with the same craft, but haven't been able to do it reliably. It happens randomly as far as I can tell.

[scimas]

I also found another possible bug. I'm sending an orbital station to minmus, so it has a lot of parts. There are 3 crew capacity parts, the hitchiker storage, mobile processing lab and an mk1 lander module. If I EVA out of the mk1 lander module and then try to board the ship again, ksp is crashing. The principia logs are showing this:
 

Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
E0618 00:15:58.811094  6052 interface.cpp:631] The timewarp limit for Jool vanishes
E0618 00:16:01.511929  6052 interface.cpp:631] The timewarp limit for Jool vanishes
E0618 00:16:05.507689  6052 interface.cpp:631] The timewarp limit for Jool vanishes
    @   00007FFF68CF0ABD      principia__GetPlottingFrame [0x00007FFF68CF0ABC+230944]
    @   00007FFF68C68D0B      principia__SetBufferedLogging [0x00007FFF68C68D0A+569402]
    @   00007FFF68CB3E0C      principia__LogFatal [0x00007FFF68CB3E0B+111]
    @   000000002F06B7B3      (No symbol) [0x000000002F06B7B2]
F0618 00:47:19.120632  6052 interface.cpp:637] System.NullReferenceException:

  at (wrapper managed-to-native) UnityEngine.Component:get_gameObject ()

  at principia.ksp_plugin_adapter.PrincipiaPluginAdapter+<AdvanceAndNudgeVesselsAfterPhysicsSimulation>d__93.MoveNext () [0x00000] in <filename unknown>:0

I could give you the save file, but I don't know how to attach those here.

[Spaceception]

Wow... I mostly screw around in KSP, and I'm not the type of person who goes for realism in the game, but this would be amazing to have for a mod I'm working on, so would this mod make mine more possible? How well does it work with mods like Kopernicus, KittopaTech, and Sigma binary/dimensions?

 

[pleroy]

On 6/16/2017 at 3:25 PM, snigavik said:

Logs might help (but i'm not sure if it's ok to pile Vagrant issues in this thread).

Good point.  We are creating a new thread (below) to help people who want to build Principia themselves.  @Rory Yammomoto@HebaruSan