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.

I'm getting tons of log spam, this message 2-4 times per second: [EXC 19:08:03.962] NullReferenceException: Object reference not set to an instance of an object PhotonSail.VesselData.UpdateMass (Vessel vessel) (at <407e8546feca4b02a483579f7a7a6b19>:0) PhotonSail.PhotonBackgroundProcessing.BackgroundSolarSail (ProtoPartSnapshot protoPartSnapshot, Vessel vessel, PhotonSail.VesselData vesselData) (at <407e8546feca4b02a483579f7a7a6b19>:0) PhotonSail.PhotonBackgroundProcessing.FixedUpdate () (at <407e8546feca4b02a483579f7a7a6b19>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) The log spam is frequent enough it's causing lag and frame rate drops, and probably background processing is also not working. I believe I have only two vessels with sails. My whole log file is here (all 260MB of it, but fortunately it's so repetitive it compresses well with 7zip). Complete mod list here.

I've been running Kopernicus for many months now; this would be a change between one of the earlier 1.9.1 builds and the most recent one on CKAN. A bunch of the star flux calculation code touches solar panels, so I wondered if something there shifted enough to reset all panels... It turns out the solar panels being retracted is a red herring; even when I extend them again, my Kerbals die of air toxicity due to running out of electricity. I suspect an incompatibility with TACLS's BackgroundResources code and the new changes here regarding the solar panel hacks. Digging through my log, I see a bunch of this: [EXC 17:57:46.558] NullReferenceException: Object reference not set to an instance of an object BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 17:57:46.581] NullReferenceException: Object reference not set to an instance of an object BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 17:57:46.607] NullReferenceException: Object reference not set to an instance of an object BackgroundResources.SolarPanel.ProcessHandler () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) BackgroundResources.UnloadedResources.ProcessInterestedModules (BackgroundResources.InterestedVessel vessel) (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) BackgroundResources.UnloadedResources.FixedUpdate () (at <5091cf6c7dfe48e7ad95ce0493f04787>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [LOG 17:57:46.609] -INFO- Tac.LifeSupportController[FFDFE940][2220.50]: Mun Triple - Electricity is running out!

Did a recent change cause solar panels to be retracted on all unloaded ships? I'm trying to track down why TAC Life Support is suddenly deciding all of my vessels are running out of EC; when I switch to said vessels, their panels are all retracted.

[ERR 00:36:35.226] Input is null for field 'agent' in config node 'CONTRACT_FINISHED' at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at ConfigNode.AddValue (System.String name, System.String value) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at Contracts.Contract.Save (ConfigNode node) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at Contracts.ContractSystem.OnSave (ConfigNode gameNode) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioModule.Save (ConfigNode node) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at ProtoScenarioModule..ctor (ScenarioModule module) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.UpdateModules () [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at Game.Updated (GameScenes startSceneOverride) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode, GameScenes startScene) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at FlightAutoSave+<PersistentSave>d__6.MoveNext () [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <5aeafee3fea24f37abd1315553f2cfa6>:0 I get this for every UberDyne Astronautics contract every time I change scenes. I manually edited my save and UDAAgency.cfg to add 'agency' to the former and 'title' to the latter to clear the error up.

As I wrote, "turn the reactor back on and then start the engine". So unless the "Start Reactor" button does something different than bringing up the reactor control window, I'm sure I activated the reactor.

This basically works with 1.8.x and above, but Agents.cfg is ancient and lacks sections like 'title', generating tons of exceptions in KSP.log.

I'm saying the latest build is not compatible with 1.8.1 and shouldn't be marked as such in CKAN. Log file: https://gist.github.com/georgedorn/e2af5fb6960c9acbaffb765fd4251fd8

Using the latest on 1.8.1 yields: [EXC 20:18:48.017] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. System.Reflection.Assembly.GetTypes () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) AssemblyLoader+LoadedAssembly.TypeOperation (System.Action`1[T] action) (at <9d71e4043e394d78a6cf9193ad011698>:0) AssemblyLoader+LoadedAssembyList.TypeOperation (System.Action`1[T] action) (at <9d71e4043e394d78a6cf9193ad011698>:0) KerbalRoster.GenerateExperienceTraitTypes () (at <9d71e4043e394d78a6cf9193ad011698>:0) KerbalRoster.GenerateExperienceTypes () (at <9d71e4043e394d78a6cf9193ad011698>:0) KerbalRoster..ctor (ConfigNode node, Game+Modes mode) (at <9d71e4043e394d78a6cf9193ad011698>:0) Game..ctor (ConfigNode root) (at <9d71e4043e394d78a6cf9193ad011698>:0) GamePersistence.LoadGameCfg (ConfigNode node, System.String saveName, System.Boolean nullIfIncompatible, System.Boolean suppressIncompatibleMessage) (at <9d71e4043e394d78a6cf9193ad011698>:0) GamePersistence.LoadGame (System.String filename, System.String saveFolder, System.Boolean nullIfIncompatible, System.Boolean suppressIncompatibleMessage) (at <9d71e4043e394d78a6cf9193ad011698>:0) QuickStart.QMainMenu+<QStart>c__Iterator0.MoveNext () (at <e535aa63b982443a814cf99fecd47ce6>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <5aeafee3fea24f37abd1315553f2cfa6>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [LOG 20:18:48.017] [ModuleManager] Intercepted a ReflectionTypeLoadException. List of broken DLLs: KerbalEngineer 1.1.7.2 GameData\KerbalEngineer\KerbalEngineer.dll This also breaks the main menu; the "Start Game" button (and every other button) does nothing.

I'm having this issue with the Liquid Core Reactor Engine. It starts activated on the launchpad, so I have to shut it off to activate the first stage, and then when I get to space it emits a puff and then nothing. I've tested it by cheating it into orbit around the sun, so it's not the restriction about using it in atmosphere or pointed at Kerbin (I do get that warning when I am in atmosphere or pointed at Kerbin). I also tested whether it was a cooling problem; my first craft had insufficient radiators, so I added quite a few more (until the VAB KSPIE window showed all green) and still no luck. It puffs when I shutdown the engine, shutdown the reactor, turn the reactor back on and then start the engine. It also puffs _sometimes_ if I warp for a while (I'm uncertain why it does sometimes and not others). The reactor state is never at any state other than Nominal or Shutdown. Log File Craft File Mod List I'm on KSP 1.8.1 because Kopernicus.

It might be a good idea to mark this as a beta release until you're confident that the bugs have been worked out. It's one thing to recompile the existing codebase under 1.9.1, since a lot of work has already happened to make that compatible. When 1.10 comes out, it's going to be a whole other thing to get it working again. The most useful artifact that could come out of this forking effort is heavy documentation on the process of updating this code (maybe enlist @Thomas P. to advise for one last update) so that other new developers don't have quite the same learning curve when this round of developers burns out on it. The more people that understand it and can contribute, the more reliably it'll be updated after each release.