Gotmachine

@Rodger Thanks for the logs, I still can't reproduce (that's a rather heavily modded install, a combination of part-plugin is triggering this), but I think I know what is happening. I'm doing something very likely to fail in corner-case situations and I probably need to find a more robust way of doing it, but in the meantime I may be able to prevent this issue with a little more error checking. Could you try replacing the GameData\UpgradesUIExtensions\UpgradesUIExtensions.dll with this updated one, see if the toolbar icons show up and send me back the log (even if it they show up, there might still is a silent error that may cause trouble) ? Thanks a lot.

@Rodger I can't reproduce the issue, tried with a few plugins that add a toolbar icon in the VAB : RCSBuildAid, SmartStage, TransferWindowPlanner and LightsOut, they all show up with or without blizzy Toolbar installed. Could you please put your KSP.log file on pastebin after a launch the game > go to the vab > quit the game session ?

Just released version 1.2 with a fix for the problem that was causing NRE with Kerbalism : v1.2 for KSP 1.2.2 - 24/03/2017 The "custom prefabs" parts now try to call OnLoad() on their modules, with the HighLogic.LoadedScene set to LOADING, in an effort to better replicate what happens with the real part prefabs. This fix the issue with Kerbalism custom modules, and may prevent the same kind of error from surfacing in other plugins. Thanks @ShotgunNinja for guidance on what was happening. Added some error-checking so if things go wrong, the plugin should fail a bit more gracefully. Hopefully things should go smoother with this one.

I can't investigate right now, but this is most likely an issue on my side (I'm doing shady things in this one). This said, the NRE are probably harmless beside messing up the tootip module text. Will fix that as soon as possible, thanks for the report.

Upgrades GUI This plugin is a collections of interface tweaks aimed at making the part/module upgrades feature introduced in 1.2 more user-friendly. Note that the plugin doesn't add any upgrades. If you want to have them in your game you need to download other mods that implement the upgrade feature. VAB/SPH part tooltips show upgraded stats The part stats are now updated according to unlocked upgrades. The part cost is now updated according to unlocked upgrades. All module widgets now show the updated stats according to unlocked upgrades. The part upgrade module widget show the detail of part stats/cost modifiers. If "showUpgradesInModuleInfo" (stock field) is set to true the upgrade config, the module widget now show the details of every upgrade currently unlocked for this module Some QOL tweaks to the tooltip stats : dry mass, mention of multi-mode engines, better formatting of engines thrust/ISP (bonus feature) Non-stock modules using cost/mass modifiers should have their modifiers taken into account too. Upgrades selection This allow to customize which upgrades are applied to placed parts in all modes (Career, Science and Sandbox) Parts with upgrades now have a clickable "upgrade widget" in the tooltip widget list Clicking on the widget show a list of upgrade widgets that can be toggled to enable/disable upgrades for this part Upgrades exclusivity/overrides rules and R&D unlock status can't be bypassed Vessels with customized upgrades will work perfectly if the plugin is removed, all this is done within the stock upgrade implementation. R&D tech tree feature In the nodes part list, upgrades have a pale green background to better differentiate them from parts. Download & source Soon to be available on CKAN ! LATEST RELEASE and source from github. Disclaimer I'm far from a skilled programmer, so the code for this may be ugly. As far as I know, it does the job and doesn't break the game. However, keep in mind that I don't really know what I'm doing. If anybody has the time to review and comment my code, I'm open to suggestions and pull requests KSP-AVC disclaimer This mod doesn't include mini-AVC, but it has a version file that allow version checking trough the KSP-AVC Plugin. Licensing This masterful work of art is released under the unlicense. So public domain, feel free to do anything, especially updating this plugin if I'm not around. Changelog and bugs Known bugs and glitches None at the moment v1.5 for KSP 1.2.2 - 19/04/2017 (Issue #5 fix) : NRE when PartStats{} node is absent from PartStatsUpgradeModule bug (Issue #4 fix) : ModuleDataTransmitter (and others) doesn't revert to base stats bug (Issue #3 fix) : Incorrect state of upgrades at init bug v1.4 for KSP 1.2.2 - 18/04/2017 New feature : upgrade selection system Refactored a lot of things Re-fixed nullref on creating the upgraded parts prefab (thanks @Oort for the perfect bug report) Removed mini-AVC dll, KSP-AVC is still supported Changed plugin name to "UpgradesGUI" v1.3 for KSP 1.2.2 - 28/03/2017 Fixed an issue causing an exception within the GameDatabase, this resolve the issue with toolbar icons disappearance (Thanks @Rodger) The module widget list in the part tooltip is now sorted alphabetically (this reproduce the stock behaviour) v1.2 for KSP 1.2.2 - 24/03/2017 The "custom prefabs" parts now try to call OnLoad() on their modules, with the HighLogic.LoadedScene set to LOADING, in an effort to better replicate what happens with the real part prefabs. This fix the issue with Kerbalism custom modules, and may prevent the same kind of error from surfacing in other plugins. Thanks @ShotgunNinja for guidance on what was happening. Added some error-checking so if things go wrong, the plugin should fail a bit more gracefully. v1.1 for KSP 1.2.2 - 23/03/2017 Added KSP-AVC support for version checking v1.0 for KSP 1.2.2 - 22/03/2017 Initial release

No Like you said, high-gain can only talk to Kerbin.

@blakemw I've tried the save you provided, and I confirm the issue. It also happen at 10000x speed if you disable all the 4k batteries (so there is only 300 EC of storage in the mk1-2 pod) and all but one of the solar panels.

@sp1989 The default Kerbalism profile is aimed at realism and self -sustainability is hard to achieve, so there is no other way to produce nitrogen. It is the same thing for the other resources (you can produce them, but not everywhere), so you must plan to have enough in stock and do resupply missions. I think that to be self-sustainable, you need Water, CarbonDioxide and Nitrogen, so the only places where you can do a totally self-sustaining base are Laythe and Duna. Here is the list of where you can find which resource :

@sp1989 You could look at the kerbalism wiki for such answers. Nitrogen can be harvested using the atmospheric harvester part on planets/moons that have an atmosphere : Kerbin, Eve and Laythe.

About the MOLE issues, a dual-tracking solar panel is perfectly doable with stock modules, seems to me that the custom module from @Angel-125 is a bit overkill. The only drawback of using stock modules is that the first module (the one controlling roll around the ship axis) is always active, so it is constantly moving to track the sun even when the solar panel is retracted. Here is a MM patch for the MOLE "Solar Battery Module" part : // Use stock modules instead of WBIDualAxisSolarArray for dual-axis sun tracking @PART[WBI_SolarBatteryModule] { -MODULE[WBIDualAxisSolarArray] {} -MODULE[ModuleDeployableSolarPanel] {} //Y-axis of SARJ is the pivot //Z-axis of suncatcher2 points to the sun. MODULE { name = ModuleDeployablePart pivotName = SARJ secondaryTransformName = suncatcher2 // same as raycastTransformName in a ModuleDeployableSolarPanel trackingSpeed = 0.25 isBreakable = false showStatus = false } //Y-axis of SolarArrayPivot is the pivot //Z-axis of suncatcher points to the sun. MODULE { name = ModuleDeployableSolarPanel animationName = Deploy pivotName = SolarArrayPivot raycastTransformName = suncatcher windResistance = 5 trackingSpeed = 0.25 isBreakable = true retractable = true resourceName = ElectricCharge chargeRate = 24.0 } } As for the "SPF-6 Solar Array", it use a WBIModuleMirroredSolarPanel whose function is to allow the player to reverse the direction the panel is facing, not really a critical feature (tbh, this feel a bit strange). I had to use a little trick with ModuleJettison to prevent the mirrored model to show up but everything seems to work fine, so here is a MM patch : @PART[WBI_SkylabSolarPanel] { -MODULE[WBIModuleMirroredSolarPanel] {} // Hacky way to hide the unused "SolarPanelMirror" model so there isn't any ugly clipping node_stack_disabled = 0.0, -1000.0, 0.0, 0.0, -1.0, 0.0, 0 MODULE { name = ModuleJettison jettisonName = SolarPanelMirror bottomNodeName = disabled allowShroudToggle = false } MODULE { name = ModuleDeployableSolarPanel isTracking = false raycastTransformName = suncatcher pivotName = suncatcher animationName = Deploy retractable = false isBreakable = true impactResistance = 8 resourceName = ElectricCharge chargeRate = 6.0 } }

I think we all agree the stock maneuver node widget is rather annoying to use and lacks several key features. In the meantime, I recommend Maneuver Node Evolved by Dmagic which address most issues and limitations of the stock widget in a nice and clean way. Unlike other plugins like Precise Node or Precise Maneuver, its UI integrate seamlessly within the current widget system and has a very "stock" feeling.

The issue you describe has been fixed a long time ago (see the discussion following this post) : There are parts in MOLE ("SPF-6 Solar Array" and "Solar Battery Module") that use non-stock custom modules (WBIModuleMirroredSolarPanel and WBIDualAxisSolarArray), I don't think those are supported by Kerbalism and they may indeed have issues. You can raise an issue on github or ask for support here, for now either avoid using these or edit their config to replace the custom modules with stock ones. I'm not 100 % sure about this one, but I think that possible occlusion from the vessel itself isn't accounted for. The algorithm only check total occlusion from bodies and output efficiency related to panel orientation and if applicable, atmosphere density. But if you continue timewarping (without switching to the vessel, so it stays unloaded), is the sunlight/shadow icon updated when it should or is it stuck forever ?

@John Nowak I don't think that the issue is related to the algorithm calculating solar panel input, but more likely this is a corner-case bug in the background processing system. When I had the issue, other features like signal and converters were also acting strange, this is why I asked you to check for the shadow icon : if its not updated anymore, this mean that the background processing has stopped working correctly (possibly along other features like temperature evaluation and signal occlusion).

@John Nowak Do you have the latest Kerbalism version ? I had such issues a few versions ago but it hasn't happened to me since some time. Also, if this happen again, could you check if you still see the in shadow/in sunlight icon in the kerbalism panel being updated when it should ? If you have a reproducible case, it would be nice to send your save to @ShotgunNinja. Note that the issue is referenced here on github.

You can't disable the background processing as a whole (it's the core feature of the mod) but if you think EC consumption is too high, you can edit several rules in your profile ("Profiles\Default.cfg", assuming you are using the default profile) : You can edit the "rate" line to a lower value in the climatization rule (or if you don't want the climatization rule, you can delete the whole Rule{} section) : You can edit the input rate for EC in the various process (decrease the decimal value in "input = [email protected]" lines), I think the main consumers are scrubber and pressure control :

@Daniel Prates Yup, radiations kill your kerbals, but unless you have a lot of them, the RTG effect is very small compared to the ambiant radiation in space. You can check for that in the VAB/SPH planner.

I have gone trough a lot of careers, but I never collected any KSC biomes science beside from the launching pad.

@Daniel Prates There is a known KSP bug that is triggered on some occasions when the vessel is loaded. If you look at the logs in the alt-F12 panel, you will see a line indicating a strangely high temperature being applied to the vessel on load. It is more frequent when you have thermal-related parts (RTG, ISRU, Drills...) but can happen with any type of vessel. But it only happens when you switch to an unloaded vessel or by getting out of timewarp, if that's not your case then it should be something else. This said, It seems to me that this very rare bug gets triggered a lot more when using Kerbalism, and I think it may be related to the malfunction/reliability system. I had a Minmus base that kept exploding from an all-parts overheating at the exact same time I received a malfunction message from one of its parts, and it happened while I was on another vessel : the base overheated while I wasn't there, which I believe isn't possible in stock.

@canisin Thanks for the support ! Regarding your observations : when you are in SAS "Stability Assist", the SAS try to use all the available torque (from control surfaces and reaction wheels) to maintain the current orientation. With the plugin, when you are in this mode, reaction wheels have their stock powerful torque as long as you don't input anything. As soon as you try to move (on control input), their torque drop to "realistic values". Those values are so low that in aerodynamic situations, reaction wheels have no effect at all, but when you release the input, the RW torque get back to the stock powerful values all of sudden. The SAS isn't really designed to handle that and usually this result in a small overcorrection. This said, the only time I'm actually seeing this effect is in space with a non-stability assist SAS mode and a large vessel. As far as I know, the SAS has only a limited ability to counteract external aero forces so in stability assist mode, when you change your orientation and then release the input, there is always a counteraction due to aero forces. The plugin probably has a small effect on top of that but I fail to see it. At some point I tried messing a bit with the SAS parameters but it did more harm than good, so for now it will stay as it is About the part pack, I unfortunately don't have much time to work on it, but if you want you can download the tiny RCS set and the RV-105 set from this link

@paulprogart This is interesting, and confirms that nothing in the main game logic is multithreaded, only some functions in the underlying engine are. I'm not an expert, but basically what is happening in KSP/Unity is that all game logic is done in a single-thread loop : at each new step (or "game frame"), the state of everything is re-computed on thing after another. Because the engine isn't designed to be thread-safe, you simply can't calculate multiple things at the same time. To (over-)simplify and take an example, in a non-thread safe environment, if the function "where is this vessel ?" is called simultaneously with the main game loop, it may return the wrong position because the main game loop may have changed the coordinate reference between the beginning and the end of the function call. Making a thread-safe API is hard : you have to make sure things are properly isolated from on another, and that things are done in the right order, which lead to performance issues because some calculations may have to wait for others to be processed. The not so great but still fair amount of things done in other threads are most likely due to the PhysX API that is used by Unity to do physics calculations. What is happening is that when KSP is asking for example "what is the state of this part ?", this is calling some functions in the PhysX API that involve doing the same calculation for a lot of things of the same kind (example : for each face in this 3d model, does it collide with any other face of another 3d model in the vicinity ?). Since those functions don't depend on the state of many other things (they can be isolated easily), it is easier to turn them into thread-safe functions that can take advantage of multithreading. There may also be a few things happening in a secondary threads, perhaps on the rendering/visual/UI side. This is why there is always activity on secondary cores no matter the situation and amount of ships. Put simply, more parts equal more calculations in the main thread/game loop, equal more calls to low-level functions that use the secondary threads to do their calculations. This mean the main thread on the main core is the performance bottleneck as long as you have a few other cores available to do physics calculations. Those cores lighten the main core load a bit, but performance still scales linearly with the amount of parts and the single thread performance of the main core and not with the number of cores of the CPU. A quick test done on my old i5 760 @ 2.8Ghz (4 cores / 4 threads) with a GTX460 in the "Jool Aerobrake" scenario (~200 part vessel), each test is an average over ~30 seconds after reloading a quicksave. I added/removed cores affected to the KSP process in the windows task manager ("affinity" option in task manager right-click menu) : 1920x1080, AA2x, max video settings, V-sync off active cores in space aerobraking (in atmo) average fps cores load (%) average fps cores load (%) 1 19 100 6 100 2 54 100/98 13 99/96 3 73 89/78/73 20 96/94/94 4 74 78/69/51/54 20 91/84/83/83 1920x1080, min video settings, V-sync off active cores in space aerobraking (in atmo) average fps cores load (%) average fps cores load (%) 1 29 100 22 100 2 96 96/88 75 100/97 3 103 74/69/61 86 81/69/65 4 104 78/49/47/43 85 79/59/57/54 This confirms that a limited percentage of the computations can be offloaded on secondary threads, and that as long as you have enough computational speed on those cores, having more of them doesn't change anything. At most, less loaded secondary cores may give a performance boost for the main one thanks to the CPU turbo system (but this can be wrong in some cases). In all cases, you can see that there is one core that is more loaded than the others, this one is the bottleneck. Also did a quick test with a 800 parts vessel in LKO, then in kerbin upper atmosphere at min video settings and 1024x768 (to eliminate any GPU impact) : active cores fps in space fps in atmo 1 9 6 2 16 9 3 16 9 4 17 9 This is interesting : when there is a heavy physics load but almost no graphics load, only one extra core seems to matter. So this would mean that even with a good GPU, lowering graphics options may improve performance on 2-cores CPUs, and that some of the CPU load involved for graphics processing is multithreaded. Overall, the performance hit on 2 cores seem to vary from 0 % to 35 %, depending on the intensity of the physics and graphics load, so a 2 core CPU that is 25 % faster than a 4 core CPU on single threaded performances may get similar overall fps in most cases. Likely, a 100 € 2 cores 3.6 Ghz Pentium G4520 would get better FPS than my 5 years old 4 core i5-760 that is rated (on CPUBenchmark) equal on global perfs but twice slower on single-thread perfs. So to conclude : KSP won't take advantage of more than 3 cores, so as long as you have a 4 cores or 2 cores / 4 threads CPU, what matter is single-thread performance. And you better have a cheap modern 2 core CPU than a five years old mid-range quad core.

Do you have a source on this ? From my limited plugin coding experience, I'm pretty confident that this is plain wrong. Everything in KSP and Unity is running in a single threaded loop and there are zero thread-safe functions in the Unity/KSP API. Maybe there is a bit of parallelism in a few low-level Unity/Physics functions but the performance improvement should be very small. People need to understand that parallelized algorithms are many orders of magnitude more complex and time consuming to implement than single-thread ones, this is especially true with real-time applications like physics. This is why only triple-A million dollars budget games are multithreaded and why games like KSP or Minecraft that were initially developed with few resources and saw an incremental development would need to be rewritten from scratch to take advantage of multi-core processors.

Just checked : OnSave (and OnLoad) is called every time the menu is opened, but also on all scene changes. So you're right, that won't work for our purpose... But maybe there is another workaround : set a boolean to true in the overrided "Enabled" function (it control UI options visibility, so should be called every time the menu is opened). Then check for this boolean in the onGameUnpause event, do your thing and reset it to false. There is a catch : if the player open the menu on a new game (in the main menu), the boolean will be set to true and your code called the first time the player do a pause/unpause. Depending of what you what to do, this could be a problem. Maybe there is some event or a way to reset the boolean when a game is first created, but I didn't found how...

In my case, I ignored the problem and reloaded my settings in the onLevelWasLoaded event (was actually better since settings changes while in-flight caused issues in my specific case). This said, I think the best and most reliable way to track every time the settings menu is closed is to do it in the OnSave function of your CustomParameterNode.

You can add the resource to the planner and the in-flight monitor but there won't be any production/consumption info, just the amount of resource you currently have. Add this to the "GameData/Kerbalism/Profiles/Default.cfg" file : Supply { resource = StoredCharge low_message = $VESSEL capacitors are almost empty@<i>We are squeezing the last bit of juice</i> }

Just released v1.2 : a few thing changed, some additions, some polishing here and there. Changelog : (feature) Ingame settings menu with compatibility checks for SSRW and PR plugins. They can now be used alongside the plugin, incompatible features are auto-disabled. (feature) Torque output on pilot/SAS input is now very low instead of disabled. (feature) Torque output on pilot/SAS input is still disabled for all reaction wheels in manned parts. This can be overridden/customized trough a "isControllable" parameter available in the module config (see the default patch CFG for more about that). (improvement) In SAS target mode, reaction wheels provide torque only if they have closely reached the target first (less "magnet effect") (improvement) Refactored several things in ModuleTorqueController, now a bit less dirty. (improvement) SAS target hold in body-relative modes (pro/retrograde, radial, normal) is now disabled when the vessel SOI change. The part pack is coming along slowly, I redid the small thrusters set for a simpler, more unified design. They now have their own super tiny monopropellant exhaust effect. Also mostly finished the RV-105 variations, now working on the large (4 kN) set, but I'm having a hard time finding a nice design for those. Meanwhile, some quick screenshots of what is done: Redone tiny thrusters (RV-105 for scale) : With tiny exhausts effects : RV-105 variations (reusing stock RV-105 texture) :