RKunze

Because Pluto (as in the roman god of the underworld) as opposed to Hades (the greek god of the underworld) fits in with the existing theme of naming the planets (and big asteroids) after roman and not greek gods (they goofed up with Uranus though and used the greek name, that one should have been named Caelus to fit the theme).

It does "work" (kind of¹) and looks very good even on my laptop, which only has an integrated Intel GPU. ¹ "Work" does not mean "playable" here, as frame rate in that kind of setup is measured in seconds per frame instead of frames per second...

You need to switch off the version check: Principia Goldbach seems to work with 1.11.2 (read: I have duplicated my 1.11.1 main game with a 1.11.2 based install yesterday, fired it up, and none of the craft im my save exploded spontaneously).

I first noticed the problem while using the Principia flight planner: Worked great for a couple of minutes, then crashed (my typical use case was planning a free return trajectory around the Mun, crash was typically while fine-tuning the munar periapsis about 5 minutes into the planning session). But later on, I had the same crash in a kOS script that made heavy use of triggers (yes, I know, that's not the best idea anyway). Increasing vm.max_map_count solved (OK, worked around - but a real solution would need Unity and/or KSP to finally stop using the deprecated Boehm GC) both cases.

I'm in the same situation (running KSP with Principia on Arch Linux), but for me, the 1.11 libc++ from Arch Linux works without problems. The ready-made Principia build links against /usr/lib/libc++.so.1 and /usr/lib/libc++abi.so.1, and the 1.11 version has a symlink under that name, so no linker problems. And the actual API and ABI seems to be compatible as well. By the way, if you're playing with Principia in Arch Linux (probably other Linux distros as well), you might want to increase the vm.max_map_count sysconfig parameter (I set it to 5000000) to avoid this problem in mono.

Issue with Modular Launch Pads and CryoTanks (with solution) I have both Modular Launch Pads (version 2.1.1) and CryoTanks (version 1.5.5) installed, and get spammed with NullReferenceExceptions in the log file whenever I select the "Static Test Stand - Engine Type" in the VAB (and the VAB editor slows down to be nearly unusable). Investigating the problem showed that CryoTanks/Patches/CryoTanksFuelTankSwitcher.cfg from CryoTanks added duplicate ModuleCryoTank nodes (for cryo tank boiloff properties) to the config which seemed to cause the error. In case anyone else stumbles on this problem, here is a small ModuleManager patch with the fix/workaround: // CryoTanksFuelTankSwitcher.cfg adds two duplicate ModuleCryoTank nodes with BOILOFFCONFIG // data to AM_MLP_TestStandEngine, which causes NullRefExcpetions. // Fix it by simply dropping the complete ModuleCryoTank nodes, since boiloff does not really // matter for a static test stand with unlimited fuel supply. @PART[AM_MLP_TestStandEngine]:AFTER[zzz_CryoTanks] { -MODULE[ModuleCryoTank],* {} }

Just had the same happen to my install trying to update from UBEE_1101_56. What fixed it for me was deinstalling ModularFlightIntegrator (which comes bundled with recent Kopernicus-BE versions, and is marked as conflicting in the CKAN metadata), then installing Kopernicus-BE UBEE_1101_58 , and finally reinstalling everything else that depended on ModularFlightIntegrator (FAR and B9 procedural wings in my case). @R-T-B: Did you change ModularFlightIntegrator handling recently? I'm not sure, but I think MFI was not bundled in earlier version of Kopernicus-BE but a dependency of Kopernicus-BE on CKAN. Never mind, should have looked in the appropriate thread for Kopernicus-BE.

The BE version is on CKAN as well, you just have to enable the "Kopernicus_BE" repository: Go to "Settings/CKAN Settings", select "New" in the "Metadata Repositories" section, then pick the "Kopernicus_BE" repo from the list of officially supported metadata repos.

Looks like the beta fixes the problem - no dying kerbals yet after 20 EVA/boarding cycles on my modded game. Thank you very much!

Bug: Civilian Population sometimes kills kerbals on boarding vessels from EVA. I have been playing a career game in 1.10.1 (quite heavily modded, and running on Linux) and had my kerbals simply disappear when boarding a vessel from EVA. The kerbals show up as "Killed in Action" in the astronaut complex. I could reproduce the issue with Civilian Population alone (version 3.0.1, installed through CKAN), but not every time when boarding from EVA (as with my heavily modded game). For my demonstration session (logfile), I had to go on EVA and board again 16 times until the bug hit. Steps to reproduce: install Civilian Population in a clean stock 1.10.1 install start a new sandbox game launch a stock "Aeris 3A" on the runway repeat the following steps until the poor kerbal disappears: go on EVA (just leaving the plane and hanging on the ladder will do) board again My (somewhat educated) guess as to the cause for this bug is a race condition somewhere in Civilian Population, because the bug only happens on some attempts, the frequency of triggering the bug varies with the number and type of installed modules (and thus with timing) from "happens every time" on my heavily modded game to "one in 16" in my reproduction session with only Civilian Population installed, and because of the "InvalidOperationException: Collection was modified; enumeration operation may not execute." entry in the logs.

Simply extract the "eveshaders.bundle" from the 1.10.1-1 zip archive and copy it to GameData/EnvironmentalVisualEnhancements/eveshaders.bundle ... Edit: Ah, I see now - there is only source for 1.10.1-1 on Github, and no distribution file. If you're using CKAN,: You'll probably still have the older version around in cache (path can be set in CKAN, default is $HOME/Downlads/CKAN), and if not, you can download older versions from CKAN.

I just did an experiment @BIOZ proposed: Ran the 1.10.1-2 DLLs with the eveshaders.bundle from 1.10.1-1, and vice versa. Result: Shaders from 1.10.1-1 are OK even with the 1.10.1-2 DLLs, and 1.10.1-2 shaders are broken with the 1.10.1-1 DLLs as well. Looks like it is indeed a problem with the shaders.

There seems to be a regression with 1.10.1-2 on Linux (or at least on my installation): Bodies with atmosphere are rendered as pink blobs (see image). This happens pretty much everywhere: In the map view, in the tracking station, and even in the flight view if you zoom out far enough. KSP.log for the session where I did the screenshot is at https://gist.github.com/rkunze/a21ee512e555e9cb5c2cb30433845703. Version 1.10.1-1 is fine.

@OhioBob: Ovoks orbit already gets changed out of all recognition by shifting it from just outside Sarnus' rings to out beyond Tekto In original OPM, Ovoks semimajor axis is just 12169413 (notice the missing zero at the end). What I did was keeping its Orbit as close as possible to the one from "Planet Patches for Principa" (or, to be honest, just fiddling around with the values until I happened on an orbit for Ovok which should stay stable for long enough to be playable - I didn't bother to actually calculate the orbit). PS: If you shift Ovok out to a semimajor axis of 121694130, but keep it going prograde at the original inclination of 1.5, there will be no apocalypse, but resonances with Tekto will eject Ovok from the Sarnus system some years into the game...

"Planet Patches for Principa" didn't work for my setup (KSP 1.8.1 with Principia Fuchs and OPM 2.2.6). The Jool system was unstable (with an apocalypse at Laythe a couple of days in), and the Sarnus system was unstable as well (apocalypse at Ovok some 30-40 years in). What did work for me was this hack based on the OPM patch from "Planet Patches for Principa" and this Jool system stability patch by @eggrobin: @Kopernicus:AFTER[Principia]:NEEDS[OPM] { @Body[Ovok] { @Orbit { @inclination = 181.5 @semiMajorAxis = 121694130 } } @Body[Vall] { @Orbit { semiMajorAxis = 49700595.866835564 } } @Body[Tylo] { @Orbit { semiMajorAxis = 90867761.53320013 } } @Body[Bop] { @Orbit { inclination = 165 semiMajorAxis = 141820511.8491002 } } } This puts Ovok in nearly the same high retrograde orbit as the OPM patch from "Planet Patches for Principa" (the only change I made was the eccentricity - instead of 0.3 as in the OPM patch, I leave it at its default 0.01), and applies the same patch to the Jool system as Principia does automatically for the unmodified stock planets. I did test this to up until ca. 1300 years in by starting a new save, going straight to the tracking station, setting time warp to maximum and watching the planets dance for a while. Hope someone else can use this as well.