Lisias

Read the Warning. It's saying that, at that time I had compiled the binary, it was not known if TweakScale will work with KSP 1.11 . This doesn't means that it will not work, it means that was not known if it will work. Well, today I determined that yes, it works fine on 1.11 . So you can hit Cancel to dismiss the Dialog (as hitting OK will close KSP to avoiding damage if the worst case scenario happens). Current TweakScale is working with KSP 1.11. So the ETA is 0, all you have to do is click Cancel and let KSP run. The next release will be taught that it works fine on 1.11, and so don't need to panic on it. --- Post Edit --h And you need to install Module Manager! I think that nowadays you wil want this file.

It's always a management problem. However, leadership != management. What's also a management problem. What I think it happened is that someone, facing some serious financial constraints due the current affairs in the World, decided to force the pre sale of the product in order to have some cash and avoid having to take harsh decisions - and by doing it, trowed the hot potato to someone else's hands. The idiot intended to earn the benefits from the stunt while letting someone else getting the heat for the problems/consequences. However, now and then the weak side of the equation is not able to save the day, and so.... 1 Bi USD evaporates form the stockholder's pockets. This is a problem extremely hard to dismiss and let someone else handle it. It' not different from how Software is developed nowadays - with everybody taking the easiest path without regarding the consequences for everybody else - what's make sense, since usually managers are promoted from the working-force.

0. It's already there. The ETA is for a update que will eliminate the warning on running on KSP 1.11, and to publish some of the features I implemented in the past months. I think 2 or 3 days, but Murphy is around making a fool of me every time I publish a deadline so take it with a grain of (Himalayan) salt

METAR No misbehaviour was found on the scaling process, Squad implemented the new feature (see here) in a way that didn't affected TweakScale. The whole story is on #Issue 147 if you are curious. SO... I'm reducing the scope of the 2.4.4 release to allow it to be on the wild sooner (right now, I'm struggling to handle symmetry on scaled parts with variants that change Attachment Points, so I will get this out of the initial 2.4.4.0 release). 2.4.4.0 will get rid of the pesky Advise about TS 2.4.3 not being known to run fine on KSP 1.11 , will get Parts with Variants with mass and/or cost scaled correctly (eliminating some Warnings), but will not allow scaling parts with Variants that changes attachment points yet (so some Warnings will linger for some time yet). Cheers!

The anchoring needs to be applied to the torque vectors too!

METAR I found some time to test KSP Recall's Driftless on KSP 1.11. TL;DR: KSP-Recall Driftless is not needed on KSP 1.11, but it's still useful on borderline situations. I will not prevent it from installing itself on KSP 1.11. WITHOUT Driftless: WITH Driftless: On the other hand, since Drfitless can still be useful on KSP 1.11, I think it is a good idea to further investigate if there's a way to still act when the physics engine is overloaded. Moar screenshots (but not necessarily more info) on Issue #10.

CD Project RED is learning the hardest and painful way that trimming your product to look good for the 20% of the users that owns beefy machines is not exactly the best way to sell the product to the other 80%.

If by any chance I'm right about this, unless Squad had deactivated the sparks on the VAB/SPH, KSP 1.11.0 is still prone to this problem, as it still uses the bugged Unity version! Mono path[0] = '/.users/lisias/Workspaces/KSP/runtime/1.10.1/KSP.app/Contents/Resources/Data/Managed' Mono config path = '/.users/lisias/Workspaces/KSP/runtime/1.10.1/KSP.app/Contents/Frameworks/MonoBleedingEdge/etc' Initialize engine version: 2019.2.2f1 (ab112815d860) [XR] Discovering subsystems at path /.users/lisias/Workspaces/KSP/runtime/1.10.1/KSP.app/Contents/Resources/Data/UnitySubsystems GfxDevice: creating device client; threaded=1 Renderer: Intel HD Graphics 4000 OpenGL Engine Vendor: Intel Inc. Version: 4.1 INTEL-12.10.22 GLES: 0 GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arr ays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_sha ding_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_ texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_sRGB_decode GL_APPLE_client_st orage GL_APPLE_container_object_shareable GL_APPLE_fl ush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier OPENGL LOG: Creating OpenGL 4.1 graphics device ; Context level <OpenGL 4.1> ; Context handle 1066118144 Begin MonoManager ReloadAssembly - Completed reload, in 1.413 seconds WARNING: RGBA Compressed BC7 UNorm format is not supported, decompressing texture UnloadTime: 1.818800 ms Release Build Please advise if this still happens, as none of my rigs have a newer GPU that supports whatever is the Unity code that triggers this crash!

Yep!

METAR KSP 1.11.0 just arrived with some changes on how Kerbals handle their mass. Since the mass of the Kerbal is not included anymore on the crewed parts on the prefab, TweakScale will render such parts sensibly lighter now (as the part will be scaled with the "kerbaless mass", and not with "kerbalful mass" as it was being done before). Additionally, since the craft will lose mass as Kerbals go to EVA, and will earn mass as Kerbals come back (including materials collected too!), how it will cope with TweakScaled parts is still unknown. I hope the engine use the living part's mass data, and not the prefab's data (as it happened once), otherwise TweakScale will be seriously affected. In a way or another, it could be a good idea to postpone updating to KSP 1.11.0 until I finish downloading it in order to test these things. And, as always, please use S.A.V.E. (just in case).... -- POST EDIT -- SteamClient is downloading KSP for me at ~150KB/s... So I think this is going to take a while... =/ -- POST POST EDIT -- SteamClient just closed for updating on me, and I had to restart the download_depot command. (sigh). I will go to bed and check this on the morning! Scale Safe!

METAR KSP 1.11.0 arrived and the need for Driftless :NEEDS to be reevaluated. Currently, Driftless is installed on anything equal or bigger than 1.8.0, so it will be installed on 1.11.0 too, being needed or not. I don't thing this will cause any collateral effect, but just in case, please use S.A.V.E. (just in case). Resourceful will not affect 1.11, it only installs itself on KSP 1.9.x. Please report anything weird.

Hi! Welcome back! You didn't cleaned up older TweakScale files before installing the new one! [LOG 23:13:39.272] Config(@PART[KIS_Container1]) TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] [LOG 23:13:39.279] Config(@PART[KIS_Container1]) TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] Completely remove all TweakScale files from your installment, them reinstall the latest TweakScale. This will fix your issue for sure. Cheers!

Yes, and this happens automatically. From .21 and forward, the Warnings are only displayed when MM rebuilds the cache (to tell you the true, the Warnings go away when the current time is 1 hour later than the timestamp from the MM ConfigCache file). If the Warnings are not going away after one hour of the Cache rebuild, you have error(s) on some third party patch(es) that are preventing MM from building the cache at first place, and the only solution is to hunt and fix that errors so MM can build the cache - and then TweakScale will suppress the Warnings one hour after.

Use the one that works on KSP 1.8. That one works for KSP >= 1.8, i.e., it will work fine on 1.8.0, 1.8.1, 1.9.0, 1.9.1, 1.10.0 and 1.10.1 . Cheers!

You need to install Module Manager! If you are on KSP >= 1.8, download this one. If you are on KSP <= 1.7.3, download this other one. Algo, keep in mind that you need to install 999_Scale_Redist.dll on the GameData too, otherwise TweakScale will not work neither. Cheers!

Welcome. And use S.A.V.E. . Believe me, this is a SAS saver.

Stable. CKAN, SpaceDock and CurseForge only publish stable releases. You need to dig to find the TweakScale Beta releases, they are intentionally not easily found. About the modlets, download then, unzip them and move the files to the GameData. There's a INSTALL.md file on each zip file with hints about how to install them.

On TS Beta, yes. But TS Beta is still beta for a reason, you risk solving a problem and getting something new in exchange (right now, scaling parts mirrored is problematic, working on it). On current TS, scaling itself will be affected because All Tweak likes a linear, percentual scaling (0 to 100%) while most parts on TweakScale use "hard", discrete scaling (1.25m, 2.5m, etc). So, suddenly, something being scaled to 25% will be scaled as 0.25m. And vice versa.

It's the other way around. All Tweak was... "tweaked" ... to only patch parts without TweakScale support. What can happen is that once you install All Tweak, and then install one of the Companions, All Tweak will respect the current patching and will not change what's already patched, what's a really good thing. However... There's a gotcha. Since KSP since 1.5 more or less (I detected the behaviour on 1.6) tries to update savegames on loading to the current status quo, the following sequence of events can be problematic: You install All Tweak You fire up KSP and start a game Later you instal something (not only the Companions) that adds proper TweakScale support Now you fire up KSP again All Tweak notices that some parts that previously were patched by it are now already patched for TweakScale, and avoid overriding the current patch (this is the right thing to do) Once you open a SaveGame, KSP will notice that some living parts have different TweakScale rules from what's on the prefab now, and tries to "fix them". (not necessarily bad for everyone, but for TweakScale it was way less then desirable) Now you have some parts that were scaled using All Tweak being now scaled using different rules, and so parts will have different sizes, weight and capacities than you expect. And this is really bad. Current TweakScale (2.4.3.21) doesn't know how to cope with this mess. Current TweakScale Beta (2.5.0.29) knows a bit better, and tries to fix the size of the parts - but the weight, cost, etc, are out of its reach , your crafts will get unbalanced no matter what. Soo... If you use All Tweak, only install new add'ons with TweakScale support (not only the Companions) to start new savegames, unless you are willing to fix some things on your current ones.

Welcome back! CKAN is planned, but I delayed it due some conflicts one of the Companions suffered with third-parties. So most of them had to be reworked to be more resilient. All-tweak is a quick&dirty solution to blindly (and somehwhat bluntly) patch parts without a TweakScale patch using a generic patch, without too much thinking on balance or plausibility. It also doesn't adds Exponents to new modules, so some third-part parts scales improperly (as gaining cost, size and weight, but keeping the standard numbers for custom features). It's a nice hack to be used as last resort, though. The Companions, on the other hand, are carefully curated (what doesn't means they are flawless, mistakes can pass through now and then, being the reason most of them are still in Beta) to scale things properly using quadratic, cubic or even fractional exponents coping with the "kind" of the part being scaled (wings? engine? crewed parts? etc). They often relies on custom code to cope with some add'ons (as KIS , KAS, FS, etc), and so on. TL;DR: You really should use the respective Companion instead of relying only on All Tweak.

This is how we turn on an engine!

If all you want is the drift fix, remove the resourceful.cfg file from your installment. This will prevent Recall to handle the resources, and only the drifting will be fixed. If this was the problem with ARP (don't know yet, probably will try it tomorrow), it will allow you to use ARP with Recall. S.A.V.E. does beyound it. It does full backups before KSP loads and (at worst case) mangles it. By the time KAC saves something for you, the savegame is already doomed.

Just managed to get time to check this today. Well, sounds like an inconsistency on the savegame... Did you had any backups? (do you use S.A.V.E.?) What happens is that once you got an Exceptions on initialisation, the thread doing the job can be killed (not always, but sometimes)- and so a thing or another may ended up not properly initialised. And since KSP "updates" the savegame on loading to allow migration, the unfortunate colateral effect is that things not properly initialised ends up being "injected" on healthy savegames on loading. I can't tell you for sure this is your case, of course - but this had happened a lot of times on some users I gave support in the past, and until I finally understood how the UpgradePipeline worked, I was unable to diagnose the problem. Coming back to your problem, on the "NO ARP" log I found: [ERR 01:19:42.239] Exception handling event onPlanetariumTargetChange in class KnowledgeBase:System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.get_gameObject(UnityEngine.Component) at KSP.UI.Screens.KnowledgeBase.ActivateApps (KSP.UI.Screens.KnowledgeBase+KbTargetType targetType, MapObject target) [0x0010f] in <c1858a3f77504bd1aaa946fdccf 84670>:0 at KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (MapObject target) [0x000f4] in <c1858a3f77504bd1aaa946fdccf84670>:0 at EventData`1[T].Fire (T data) [0x000b0] in <c1858a3f77504bd1aaa946fdccf84670>:0 So in a wild guess, I think Distance Object Enhancement is the most probable suspect. What I think can do to salvage the savagame (assuming you don't have backups) is to duplicate your installment to create a test bed, create a new savegame with some vessels around. close KSP, backup that savegame install the add'ons you mentioned. open KSP, load that savehame and check for the problems close KSP, backup agian the savegame. send us both copies of the savegame for analysis. Using DIFF, we can try to find what changed on the two copies and so, detect what's really happening. About the Exception on the Alternate Resource Panel [EXC 00:56:13.753] NullReferenceException: Object reference not set to an instance of an object KSPAlternateResourcePanel.KSPAlternateResourcePanel.SetAppButtonToTrue () (at <937bb4d6d6f54a349df59076417a577d>:0) KSPAlternateResourcePanel.KSPAlternateResourcePanel.RepeatingWorker () (at <937bb4d6d6f54a349df59076417a577d>:0) KSPPluginFramework.MonoBehaviourExtended.RepeatingWorkerWrapper () (at <937bb4d6d6f54a349df59076417a577d>:0) This may be a conflict with KSP-Recall. In order to prevent KSP to reset resources on the parts, KSP-Recall uses an internal, parallel "mini game database" for resources, and when something mess up the parts resources, Recall restores it. If by some reason the Alternate Resource Panel makes copies from the direct references to the part's resources before Recall has the chance to restore it, ARP will have old orphaned references to old useless resource objects, and as GC works, these unused resources can lead to NREs. It's a wild guess at this time, I need to build a test bed to check this hypothesis. I will do it as time allows.

TL;DR: Don't worry. it's not an error and your game is safe. Next TweakScale release will finally get rid of it. Long History: These ones as "Warnings", i.e., they are things that can annoy you but they will not hurt (but it would, if I didn't withdrew TweakScale from that parts). These nine, in particular, are related to a thingy called Variant. It's a way to introduce... well.. variants... of a part without the need to create a new part, and so add more entries into a already near overpopulated Palette. When a Variant change Mass and/or Cost, TweakScale was failing to correctly scale the part, and sometimes the Cost ended up negative (and, so, creating a nasty exploit on the Career game), or negative (or, worst!, ZERO!) mass, and so leading the game to a crash (ruining the savegame). At that time, a huge lot of things were changing, and some of that changes were breaking third-parties add'ons, that by their time ended up blowing up TweakScale by side effect. And such avalanche of things to fix forced me to priorize - since only 9 parts were changing Cost and Mass, I gone to hunt everything else. Now, however, things changed, and these 9 parts are the final technical debits on TweakScale really affecting a Stock (and DLC) game. And these ones is what I'm working on right now, by the way. You can follow what I'm doing checking the Issue #42. TweakScale Beta, now, knows how to correctly handle Variants with Mass and Cost. This is past right now, the next TweakScale release will get rid of that 9 Warnings bothering you. However, right now I bashing my SAS figuring out how to handle Mirroring with scaled parts with Variants (yeah, this Variant thing is fighting fiercely...). I think this is the last job before releasing the new TweakScale. If you are curious, I'm talking about here. Yep. These are the ones (on a Stock+DLC installment): [LOG 23:24:47.878] [TweakScale] ERROR: Part EnginePlate1p5 (EP-18 Engine Plate) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.879] [TweakScale] ERROR: Part EnginePlate2 (EP-25 Engine Plate) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.879] [TweakScale] ERROR: Part EnginePlate3 (EP-37 Engine Plate) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.879] [TweakScale] ERROR: Part EnginePlate4 (EP-50 Engine Plate) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.886] [TweakScale] ERROR: Part Tube1 (T-12 Structural Tube) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.886] [TweakScale] ERROR: Part Tube1p5 (T-18 Structural Tube) didn't passed the sanity check due having a ModulePartVariants with Cost - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.886] [TweakScale] ERROR: Part Tube2 (T-25 Structural Tube) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.886] [TweakScale] ERROR: Part Tube3 (T-37 Structural Tube) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 [LOG 23:24:47.886] [TweakScale] ERROR: Part Tube4 (T-50 Structural Tube) didn't passed the sanity check due having a ModulePartVariants with Mass - see issue [#13]( https://github.com/net-lisias-ksp/TweakScale/issues/13 ). at error:0 Of course, some third party add'ons can inflate these list a bit. But, in a way or another, these ones will vanish for sure on the next TweakScale release. Uh... Too late. I'm curious. I don't know exactly what is the problem you detected on your 1.8.1 installment, but inspecting the other log I think you have wrong versions for Scatterer and K3P installed. These two add'ons are terribly tied to some internals that are changing heavily lately (been there, debugged that). However... You installed, indeed, the right version: [LOG 18:12:49.820] [Scatterer][Info] Version:0.055 So perhaps you have found a bug or incompatibility with something else. The exception is happening right on startup and, knowing how KSP works internally, this exception can be aborting something important. Talk with the Scatterer guys to check if this can be ignored. [EXC 18:12:49.841] NullReferenceException: Object reference not set to an instance of an object scatterer.ScattererCelestialBodiesManager.findCelestialBodies () (at <a822e9740b51404b897e7cf406e4df3f>:0) scatterer.ScattererCelestialBodiesManager.Init () (at <a822e9740b51404b897e7cf406e4df3f>:0) scatterer.Scatterer.Awake () (at <a822e9740b51404b897e7cf406e4df3f>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__89:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__70:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() Also found this on scatterer: [LOG 18:14:30.180] [Scatterer][Error] Effects couldn't be loaded for Earth because of exception: System.Exception: No correct main menu object found for Earth at scatterer.Utils.GetMainMenuObject (System.String name) [0x0005f] in <a822e9740b51404b897e7cf406e4df3f>:0 at scatterer.ProlandManager.Init (scatterer.ScattererCelestialBody scattererBody) [0x00090] in <a822e9740b51404b897e7cf406e4df3f>:0 at scatterer.ScattererCelestialBodiesManager.UpdateProlandManagers () [0x001d8] in <a822e9740b51404b897e7cf406e4df3f>:0 KS3P, however, is not exactly compatible with 1.8.1, it's borking while initialisation - and more than one time; [EXC 18:13:15.605] ArgumentException: Requested value 'fxaa' was not found. System.Enum+EnumResult.SetFailure (System.Enum+ParseFailureKind failure, System.String failureMessageID, System.Object failureMessageFormatArgument) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) System.Enum.TryParseEnum (System.Type enumType, System.String value, System.Boolean ignoreCase, System.Enum+EnumResult& parseResult) (at <ad04dee02e7e4a8 5a1299c7ee81c79f6>:0) System.Enum.Parse (System.Type enumType, System.String value, System.Boolean ignoreCase) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) System.Enum.Parse (System.Type enumType, System.String value) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) KSP_PostProcessing.Parsers.Parser`1[T].TryParseEnum[E] (System.String enumString, E& parsed) (at <23a20b94782a4ba5a37d2f4fd9ad5f4a>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) KSP_PostProcessing.KS3P:Exception(String, Exception) KSP_PostProcessing.Parsers.Parser`1:Exception(String, Exception) KSP_PostProcessing.Parsers.Parser`1:TryParseEnum(String, Method&) KSP_PostProcessing.Parsers.AntiAliasingParser:Parse(ValueList) KSP_PostProcessing.Parsers.Parser`1:Parse(ConfigNode) KSP_PostProcessing.Profile:.ctor(ConfigNode) KSP_PostProcessing.Profile:op_Implicit(ConfigNode) KSP_PostProcessing.<LoadProfilesAndTextures>d__84:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) Spacedock tells me that KSP 1.7.2 is the latest officially supported release (1.7.3 will probably work fine). KSP 1.8.0 changed the Unity Engine version, and this was a pretty huge change. Again, due some internal characteristics of KSP, these exceptions potentially can interrupt the initialisation process for some thingies, and it's impossible to foresee the consequences. If you have some weird misbehaviour on your game, it may be related to something that should had been initialised but it was not because some unhandled Exception broke its caller, that so aborted the initialisation thread that would do the job. I also found something related to Reality Overhaul: [WRN 18:14:19.045] [ROCManager]: Invalid CelestialBody Name Eeloo on ROC Definition EelooBerg. Removed entry. [ERR 18:14:19.047] Exception handling event OnPSystemReady in class ROCManager:System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index at System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) [0x00029] in <ad04dee02e7e4a8 5a1299c7ee81c79f6>:0 at System.ThrowHelper.ThrowArgumentOutOfRangeException () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at ROCManager.ValidateCBBiomeCombos () [0x00314] in <9d71e4043e394d78a6cf9193ad011698>:0 at ROCManager.GetROCControlFromCB () [0x00000] in <9d71e4043e394d78a6cf9193ad011698>:0 at EventVoid.Fire () [0x00127] in <9d71e4043e394d78a6cf9193ad011698>:0 Eelo is not being loaded apparently due some typo on a config file, perhaps? In a way or another, other than losing Eelo on the game, apparently this was handled propperly by Koppernicus. In a way or another, Exceptions are, usually, bad news. When not propperly handled, they kill the thread that is running the faulty code - and then anything that would be done after that code are just ignored - and badly initialised code tends to inject collateral effects later on the game. So perhaps you would want to get rid of KS3P and Scatterer and redo the testings to see if you get the same results before applying for a bug report. -- -- -- -- Related to TweakScale, I found 3 fatalities on your KSP.log. There're errors happens when more than one patch indiscriminately patches the same part, and so TweakScale risks screwing up things due conflicting rules: [LOG 19:35:31.039] [TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Portable Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 19:35:31.039] [TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 19:35:31.039] [TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Well, this one happened because you forgot to remove all the old files before installing a new TweakScale version! [LOG 19:34:09.054] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] [LOG 19:34:09.419] Applying update TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] It's really a good idea to completely remove all the old files from an Add'On (except when you are told otherwise), since as new releases are issued, some files are moved or deleted and then this oldies play havoc on the game are these did to you. The good news is that, since these double patching is happening due old lefties lingering around and I know exactly what these oldies had inside, I can ensure you that nothing bad is happening - TweakScale is not exactly the smartest person in the World (no code is), so it can't tell when a double patching is going to hurt you or not, so it yells on every double patching. Just remove all TweakScale files, install a fresh copy immediately, this this will vanish from your installment. EDIT: My answer complements (and not substitutes) what @Krazy1 answered to you. You should also fix the problems pinpointed by him! -- -- -- -- -- No! I'm stubborn!! Incredibly stubborn!! Cheers for everyone!

I will issue a new release on the WeekEnd. Again, thank you. I will revise the numbers before publishing it. Cheers, everyone!