GDorn

I'm running linux on a system with 32GB of ram. The default 32g file didn't help much at all, so I set the heappadder defaults to a 1 in every row and a total of 16384. Not sure if that's the right way to go about it, but it only helps a little; before doing this, I'd end up with a 1s pause every 5s. With this padding I now have a 1s pause every 10-12s. So it helps a touch but it's still bad enough that I find I'm not interested in starting the game... Should I keep increasing the padding? Is there a more optimal way to go about this? Should I be running KSP in Proton, or boot to (*shudder*) Windows?

I'm running into this issue, too. I do have a line in my KSP.log, but it just says: [LOG 19:12:08.176] deleting part kspiHalberd Nothing above or below that seems related and I'm not sure the timestamp actually corresponds to when it happened.

It also only works for mods that are compiled using CTB; mods that don't use it can't be helped.

As yet another followup, I flew an engineer out there, which unlocked the ability to change drill modes. I changed it to ore, but the drills still refused to do anything. Perhaps the description should be updated to mention that they simply don't work for asteroids under any circumstances, even if the asteroid contains the resource you are mining for.

Shouldn't I at least be able to switch the drills to ore mode? The asteroid clearly has ore; a second vessel is extracting that already.

My pulse drills have no mechanism for starting them. I launched with them configured for MetallicOre, grappled an asteroid, and nada. There's also no button for changing their type (to switch back to Ore in case that was the problem) despite having the MaterialKits and SpecializedParts on-board to do so. Is this a mod conflict, a bug, or just normal behavior and I'm missing something? No amount of retracting/deploying or reloading saves fixes it. The vehicle has no Engineers on board, but I inferred from the description that that isn't needed for the `-A` variants.

I have no idea if this is within the purview of this mod, but giving planet pack authors a mechanism for adding custom anomalies would be great. I know Beyond Home has them as scatter, but because it's custom, they don't show up as anomalies either via KerbNet or ScanSat.

I, too, am curious about this. I'm playing Beyond Home on 1.12.3, with some educated guesses about things like asteroid/comet settings (UseKopernicusAsteroidSystem = Stock). I have applied the multi-sun patch which helped a lot in some rare edge cases, but everything else I'm just guessing at.

You need the MultiStarSolarPanels.cfg file from the Kopernicus repository. See https://github.com/Kopernicus/Kopernicus/releases/tag/release-74 (you should probably use the one for the release you're running, though that particular file rarely changes.) It mostly works; if you run the right version of Parallax, use the multi-star config and (on some systems) UNSUPPORTED_LEGACY_SHADER_TERRAIN, you get almost everything. What things are missing on planets? There's a really old bug (oversight?) where a biome on Lua is defined but never used. Comets and Breaking Ground points of interest also don't appear, but that makes sense because they came out after BH's last release. I'd love an update, but it seems playable to me as-is.

This seems to have caused a Kraken attack on an orbital station, though it's hard to say for sure. Does WS have a check to ensure it only runs on vessels on land (or in the water)? Is there a way to configure it to ignore entire classes of vehicles and, say, only run for things marked as Rovers or Bases? I mostly only need it to prevent BonVoyage-driven rovers from loading below ground and exploding.

Right. "Top of navball" is typically your heading on the launchpad, when all you can see on the navball is blue. Bottom is directly opposite. This was in orbit of "kerbin" (actually Rhode, but irrelevant) and the behavior is consistent across control points - that is, it always orients the current control point to the top of the navball, so the code to get the current control point is right.

For prograde/retrograde, it works great. I tested on a vessel with randomly-facing probe cores, and it orients correct depend on which is active. For normal/anti-normal, it does nothing now, which I gather is intended. For radial out, it points at the top of the nav ball, not current radial out. And radial in goes to the bottom. I doubled-checked that I wasn't accidentally referencing the wrong body, but that doesn't seem to be the case. I can't remember if it used to hold target; it's tricky to test on this craft, but it doesn't seem like it does.

This bug has made the mod essentially unusable for me. I'm at a section of my playthrough where I'll have multiple ships docked to the same massive (say, G-class) asteroid, trying to do precise maneuvers to arrange for very specific altitude aerobrakes, and it becomes impossible to time warp near re-entry without everything ending up pointed the wrong way. And being such a massive asteroid, rotating it takes ages. Ships composed of multiple, separately-launched parts with multiple probe cores are probably badly affected, too. It seems like the obvious fix is to use the orientation of the current control node, rather than the root node. Is that actually possible? It would seem to be closest to the user's intent, given SAS behaves that way already. Or, if that's not possible, a button that actually deactivates the plugin or at least the "hold heading" feature when I don't want it? @linuxgurugamer if you think it might be possible to switch to current control node but don't have the time to do it yourself, I could take a stab at it. I may anyway, but I assume you know the code (and the likelihood this change could work) better than I do.

I got it working on Ubuntu, using the LinuxPlayer (not Proton), and KSP 1.12.1.3142. Two things: Be sure to use Parallax 1.0.1; trying to use a more recent Parallax causes other issues. Edit settings.cfg, and set `UNSUPPORTED_LEGACY_SHADER_TERRAIN = True`. That fixed the missing and/or magenta textures for me. It almost works with the latest Parallax, but some of the lighting is a bit wonky. But the latest Parallax on Windows (or with Proton) is far more broken. On 1.12, the Lua base was already unlocked for me; I didn't pay to use it or anything. I suspect that's a bug.

Can EC monitoring be completely disabled? I'm running into an issue where mod conflicts (probably Kopernicus) are causing BackgroundResources to not be able to access solar panels (endless NREs in the log). So every time I warp, Kerbals are dying due to running out of electricity while sitting on top of an active nuclear reactor and between two gigantor solar panels. While it'd be nice if this problem could be fixed (see here for my post going into it) I'd also like to be able to play in the meantime and just track food, water and oxygen.