Lisias

ANNOUNCE Release 1.9.0.9 is on the wild, featuring: Adds pt-br Localization Prevents pumping resources not meant to be transferrable Closes issues: #28 GPOSP is trying to pump non pumpeable resources! #25 Brazilian Portuguese (Português Brasil) <pt-br.cfg> See OP for the links — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right now. The reasoning is that I'm wasted, and I prefer to avoid the risk of making yet more mistakes while publishing the thing - and I could use the time to have some feedback from early-adopters. — — POST EDIT — — A mysterious time anomaly happened, wiping out 1.9.0.8 from existence! Please download 1.9.0.9!

Hey, very interesting info! I'm unsure I should use it on the flares problem because I would have to mangle with the game camera (assuming, of course, I could cook something for my problem with this info), and it will risk screwing up things with people using Camera add'ons. On the other hand, this will solve for sure another problem on another add'on of mine! Life saver! Thanks!

This one gave me a hell of a run for my money on DOE! I have a visual glitch where bodies' flares were being visible trough atmospheres, what's not a surprise as they are being drawn on a layer above the Planets (forgot exactly which one now), and the Atmosphere layer is way "down there". "No big deal", I talked to myself. "I will shove the flares on Layer 6 and call it a day". And so I did, and it solved the problem - the flares weren't being visible behind atmospheres anymore. But were being drawn behind their bodies now… I left as an exercise to the reader to imagine what I yelled to myself about software development - depicting them here would infringe the Forum's Rule 2.2 itens A, C, D, E and above all, G. I tried to solve the problem by using raycasts: calculating the vector of the camera to the flare, and then casting a ray from the body to infinity using that same vector, and if it hits a Atmosphere, the flare is hidden. Not sure if I messed up the code or if Atmospheres are not hittable by raycasts - but in a way or another I concluded that casting rays all the time would not be exactly the most efficient way out of the mess, so I ditched the idea. My next time window for this task (pending Real Life™ agreement) will be to look for some function or property that would tell me if a body is visible by the current camera (I had noted that celestial bodies - as the Mün - are not drawn over the Atmosphere) and then replicate the status on the flare! Cheers!

Send me the new KSP.log. We may be facing two problems at the same time - pretty common when we must interface with many 3rd parties at once! POST EDIT Never mind. Found the problem, a typo! Uploading a new release in 30 minutes - I will be able to properly test it now. POST POST EDIT Fixed. It was a typo indeed, but not on GPOSP. I made a mistake early this year while creating a support library and completely missed the mishap on the Assembly name until now. Please download it again from https://github.com/net-lisias-ksp/GPOSpeedPump/issues/28 You need to have some new PAW entries like this: Note: I just detected a missing use case on GPOSP: it's trying to handle umpumpeable (and/or invisible) Resources, as the one KSP-Recall needs to counter-screw a major blunder on KSP on recovering funds. I will fix it ASAP (pending Real Life™ agreement), but in the mean time please don't pump or balance any "weird" resources, as this will probably screw up 3rd parties that need such stunts (KSP-Recall is not the only one!).

Hi! I found a very annoying mishap (something that never happens on development time, and ended up passing trough as everybody that tested that thing were developing it in a way or another). And by analysing your log, I concluded you were bitten by it. I have the fix published here : https://github.com/net-lisias-ksp/GPOSpeedPump/releases/tag/RELEASE%2F1.9.0.6 But since I will not have time to test the thing until late night today, I will keep it in Pre Release to avoid spreading.. hummm.. "rectangular pieces of white paper" on the wild in the case I didn't cut it. Please download the 1.9.0.6 and install it manually to see if the problem goes away. Please advise if it works (or not - and then I can try a new diagnose are time allows!) GPOSP doesn't cares exactly about Fuel or Tanks, only about resources. So, in theory, you can patch it on anything that have RESOURCES. But since Fuel Switches (and others) also directly handle resources, we avoid blindly patching it everywhere to avoid stomping on their toes. So we choose to patch only what we know will work. After testing, we found GPOSP works with B9PS, so it will be patched on parts with it. If by any reason the CryoTanks are not patched, ping us here and we will analyse the thing. Or... You can rename the file GameData/GPOSpeedPump/Patches/everything.cfg.disabled.txt to everything.cfg . This will enable GPOSP's "berzerk" mode and will patch it on anything having resources - but be aware that unpredicted side effects can happen by doing this!

Two in a row! Hey, @orangewarning, are you back to Kerbin or still at loose somewhere on the Kerbol System?

Well, well, well… That one is a new. Really, really new! [LOG 16:54:58.285] Calling KSP-Recall.ModuleManagerSupport.ModuleManagerAddToModList() [EXC 16:54:58.287] Exception while calling KSP-Recall.ModuleManagerSupport.ModuleManagerAddToModList(): System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ExecutionEngineException: String conversion error: Illegal byte sequence encounted in the input. at (wrapper managed-to-native) System.Reflection.Assembly.get_code_base(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetCodeBase (System.Boolean escaped) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.Assembly.get_CodeBase () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.AssemblyName.Create (System.Reflection.Assembly assembly, System.Boolean fillCodebase) [0x00010] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.RuntimeAssembly.GetName (System.Boolean copiedName) [0x0000e] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.Assembly.GetName () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at KSPe.Util.SystemTools+Assembly+Finder.ExistsByName (System.String qn) [0x00031] in <db68626e2fd64c5fa45e9c0df657f9e4>:0 at KSP_Recall.ModuleManagerSupport.checkForProceduralPartsAttachmentNodes () [0x00000] in <6241eeb3c72b4f7ab3036f34ee51b728>:0 at KSP_Recall.ModuleManagerSupport.ModuleManagerAddToModList () [0x00072] in <6241eeb3c72b4f7ab3036f34ee51b728>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <9577ac7a62ef43179789031239ba8798>:0 And KSP-Recall was caught on the cross fire. However, I'm reasonably sure Recall is a innocent bystander because this happened too in your previous log, but further on the timeline: [LOG 01:43:25.702] [AddonLoader]: Instantiating addon '_BuildManager' from assembly '_BuildManager' [EXC 01:43:25.707] ExecutionEngineException: String conversion error: Illegal byte sequence encounted in the input. System.Reflection.Assembly.get_Location () (at <9577ac7a62ef43179789031239ba8798>:0) _BuildManager._BuildManager+<>c__DisplayClass2_0.<logVersion>b__1 (System.Reflection.Assembly x) (at <b7753086ed104f0cb27def0fb5040bc9>:0) System.Linq.Utilities+<>c__DisplayClass1_0`1[TSource].<CombinePredicates>b__0 (TSource x) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable+WhereSelectArrayIterator`2[TSource,TResult].ToList () (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) _BuildManager._BuildManager.logVersion () (at <b7753086ed104f0cb27def0fb5040bc9>:0) _BuildManager._BuildManager.Awake () (at <b7753086ed104f0cb27def0fb5040bc9>: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__90:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() So we have a suspect - someone is injecting illegal bytes sequences on the Stack instead of sane UTF-8 strings. And we found a weakness (not exactly a bug) on Harmony (or perhaps on Burst?), as it is being caught with its pants down by the problem while trying to handling the problem. Reach the maintainers with that log and ask for a slightly more robust exception handling so next time something like this happens, it's easier to diagnose. Now, back to the smelly under our noses: the good news about being caught in the cross fire on KSP-Recall is that I know that code very well (I'm the crazy SAS that wrote the stunt, after all!! ). And I know that the code checks the running KSP environment version and looks for two Assemblies to check if they are installed - and this code is the smoking gun that proves you have an Assembly DLL with a corrupted String on the name or some other metadata! (other occurrences also suggests such problem, but since I don't have easy access to that source code, I used mine to get such proof). Now the problem is… HOW BY KRAKEN'S SAKE we will find the kraken damned DLL with a corrupted string on the metadata if we can't print it's name without triggering again the problem (it was what caught Harmony or Burst with its pants down in the last log). I will need a bit of time in order to cook something, we are going to need some instrumenting in your rig to get the answers we need. In the mean time, put back that two add'ons. There're some things that depend on them and are borking on their load, triggering that nasty KSP's Assembly Loader/Resolver bug, that by itself creates a whole different set of problems that will surely get in the way on the diagnosing. In the hopes to reduce the scope of potential troublemakers, what were the latest add'ons you installed before getting this error?

I felt a disturbance in the force, as hundreds of Exceptions suddenly were printed in the KSP.log… @zer0Kerbal is around?

Ugh… Now things got really messy, found something new on your log! [ERR 01:43:25.661] Couldn't extract exception string from exception of type TargetInvocationException (another exception of class 'ExecutionEngineException' was thrown while proc essing the stack trace) [EXC 01:43:25.661] <.....> [LOG 01:43:25.702] [AddonLoader]: Instantiating addon '_BuildManager' from assembly '_BuildManager' [EXC 01:43:25.707] ExecutionEngineException: String conversion error: Illegal byte sequence encounted in the input. System.Reflection.Assembly.get_Location () (at <9577ac7a62ef43179789031239ba8798>:0) _BuildManager._BuildManager+<>c__DisplayClass2_0.<logVersion>b__1 (System.Reflection.Assembly x) (at <b7753086ed104f0cb27def0fb5040bc9>:0) System.Linq.Utilities+<>c__DisplayClass1_0`1[TSource].<CombinePredicates>b__0 (TSource x) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable+WhereSelectArrayIterator`2[TSource,TResult].ToList () (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) _BuildManager._BuildManager.logVersion () (at <b7753086ed104f0cb27def0fb5040bc9>:0) _BuildManager._BuildManager.Awake () (at <b7753086ed104f0cb27def0fb5040bc9>: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__90:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() Later, I found many, many exceptions about Kopernicus but, frankly, knowing KSP as we know, I can't rule out Kopernicus being screwed by this first problem. Well, weird new things usually demands weird new procedures. Let's eliminate some variables from this equation, being them 000_Harmony 000_KSPBurst Remove these two folders and rerun KSP and send me the new KSP.log to see what we get. I think the real problem will happen again, but this time without someone in the middle borking while handling the bork and, so, we will get the problem being properly logged and can do something about. Once we fix the problem, you can install them back.

Your KSP.log is truncated. Please send me a new one - be sure to quit KSP before copying KSP.log to prevent it from being truncated. Cheers! NAH… I got enough log to diagnose it (by luck). [ERR 23:09:58.284] ADDON BINDER: Cannot resolve assembly: ContractConfigurator, Culture=neutral, PublicKeyToken=null [ERR 23:09:58.285] AssemblyLoader: Exception loading 'ScrapYard_ContractConfigurator': System.Reflection.ReflectionTypeLoadException: Exception of type 'Syste m.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' ScrapYard is complaining that it needs Contract Configurator. The Add'On thread says Contract Configurator is only needed on KSP 1.12,x - don't have a clue about the reason CKAN din't installed it! I think you need to talk to CKAN guys to sort it out to preventing getting hit by this problem next time you reinstall things! Cheers² — — POST EDIT — — In time, this happens due a bug on a thingy from KSP called Assembly Loader/Resolver yada yada yada . When something borks while trying to load a DLL (and it can be anyone by any reason), something on that thingy gets broken and from that point anyone else trying to load DLLs will bork equally no matter its DLL being fine or not. Since TweakScale makes heavy use of DLLs, and it's somewhat popular, it ends up that TweakScale is the most visible victim of the problem. And it's visible because TweakScale complains about anything that can damage your savegame, and being half-loaded definitively will corrupt any savegame that uses TweakScale for good. No salvage possible.

Ah, got it! You have rerooted the craft to make the last part you attached (inverted) as the new root!! I reproduced the problem here! Interesting enough, I could load the first parcel on Editor without triggering the misplacement of the part (this is what I though it was problem), so I was wrong about the problem you are experiencing. You found a new one! And this is not related to TweakScale, because I didn't scaled the parts - since I was the one that coded TweakScale, I know that the PartModule deactivate itself when the part is not scaled (it's just not run at all), so it's impossible that TweakScale would be the culprit of this one. So this is something on KSP-Recall, or you found a new bug on KSP Editor itself. So I removed TweakScale and KSP-Recall from the testbed and tried to reproduce the problem. No success, so I conclude we have a missing use case on KSP-Recall itself! As a proof of concept, I rebuild the same parcel but starting with the Docking Port Jr; attaching the SAS (inverted) and then attaching the Probe Core (also inverted). When I tried to merge this thing on other craft, it worked as expected. So the problem is for sure related to rerooting the craft. I will tackle down this one here: https://github.com/net-lisias-ksp/KSP-Recall/issues/56 (I'm still recovering from a very nasty flu, so I can make any promises about when) Cheers!

I'm unsure I understood you. On that vídeo you sent, this root part modification was done, right? I will rewatch it with more attention.

Whoops… You may had found a missing use case on KSP-Recall... Thanks for the feedback, I will investigate this issue ASAP. https://github.com/net-lisias-ksp/KSP-Recall/issues/56 In time: can you check what happens if the parent craft have a Variant, and when it does not?

And this is the very reason I'm found of this thread as one of the best I ever posted. In life. I can't tell you how many different (and new) styles I got in contact by reading this. I have an HD full of MP3 and OGG files to indulge myself with things I already know about - this is where I find new (curated) ones! Cheers!

Known issue. It's related to merging a craft created without KSP-Recall on a rig with KSP-Recall installed: I never got a firm grasp on the "Upgrade Pipeline" thingy that is what (I think at least) would do it automatically for you what I'm going to explain how to to it by "brute force": In order to have KSP-Recall properly active on your crafts for merge, you need to load and save every parcel craft first to make sure everyone has the PartModules installed, configured and active. Once everything has KSP-Recall's PartModules working, your merges will succeed. You need to do it only one time, by the way. Thanks Kraken. This is also needed with SubAssemblies. Craft Manager is on the rescue here, it allows you to load an Assembly as it was a ordinary craft and once the thing is loaded, KSP-Recall is injected on it and you can save the SubAssemblies back to the filename. Danger, Will Robinson, Danger!! Technical Gobbledygook below!

Hi! You got a nasty occurrence of a duplicated patch: [LOG 19:32:19.935] [TweakScale] ERROR: **FATAL** Part pp.vvmach (Plume Party Vapor Vent Mach) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 We will need to find who is double patching the pp.vvmach e fix it. Problem: I found the same patch happening 3 times on your log! [LOG 19:09:24.429] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 19:09:24.430] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 19:09:24.431] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] And I don't have the slighest idea about the reason. KSP Recall modules are also being applied 3 times! And the reason appears to be you having more than one copy of ModuleManager running on the rig! [LOG 19:23:02.404] AssemblyLoader: Loading assembly at D:\Games\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.2.2.dll [LOG 19:23:02.405] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 19:23:02.554] AssemblyLoader: Loading assembly at D:\Games\steamapps\common\Kerbal Space Program\GameData\Benjee10_Orion_v1.1.0\GameData\ModuleManager.4.2.2.dll [LOG 19:23:02.568] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 Interesting… It was my understanding that on KSP 1.12.3 duplicated DLLs would be resolved by promoting only the newest one to run, but apparently I was wrong. Completely remove the directory GameData\Benjee10_Orion_v1.1.0 and see if the problem goes away - I expect it does. After confirming the diagnosis, you will need to install Benjee10_Orion correctly: you need to unzip the package into a temporary directory, and then move the package's GameData contents into your KSP's GameData, instead of unzipping the thing on the KSP's Root and hoping for the best. Additionally, pay special attention to avoid having more than one ModuleManager installed on your rig - apparently this is not safe as I was thinking.

Right now, is this one. Requiem in D Minor, Amadeus.

Exactly! And the problems with "dirty hacks" is that once you do it more than once on the same code, you gets into a serious risk of having them screwing up with each other - and, by consequence, the code at a whole. It's essentially what happened on KSP Editor - my first attempt to fix the problem ended up being a dirty hack (as I didn't understood the root problem at that time). Then, on KSP 1.9.x when KSP Editor struck again, the workaround I implemented ended up screwing up 3rd parties due the first "fix"; both "fixes" when piled made everything harder to diagnose. Let me tell you the whole history, as I known it by now (and I still may be wrong! ): On KSP 1.4.3 (but probably the problem really started on 1.4.2, but since this release lasted only a few days…), TweakScale started to have the stack attachment nodes reset on KSP. I Didn't understood it was an Editor only problem, so I brute forced my way into the problem and it was applied all the time. The (now understood) collateral effect is that any other add'on that also changes de stack attachment nodes gets royally screwed at flight by TweakScale! On KSP 1.9.0, Editor started to reset also the radial attachment nodes! And this time, I managed to correctly diagnose the problem, and got it worked around on the right place only (Editor) But I let pass trough the Stack Nodes, as TS was brute forcing it all the time since some time and I wasn't seeing this as a problem anymore. And yet, it was not the best way possible to solve the problem. Some time later, I realized the consequences of brute forcing my way about radial nodes and incepted KSP-Recall. KSP-Recall would be in charge of "unscrew" the radial attachments being screwed by Editor the soon as possible - so TweakScale was removed from the problem at all. Any mishap on the solution would be tackled down on KSP-Recall, where I was in way better position (the start of the OnLoad chain) to fix the problem before anyone else would try to change something. But the stack attachment nodes were left behind, again. Early this year I finally was enlightened by some divinal entity, and understood the full problem - but, funny enough, I didn't cogitated the hypothesis that the problem was happening since 1.4.x!! So the proper fix I applied were not being applied on KSP < 1.9, and once I removed the gambiarras, I broke things for them And yeah, at least me still plays on them Once I correctly diagnose the source of problem, I found a bug on TweakScale's code responsible to move parts to match the new Attachment Nodes positions: due something I missed while coding it, parts being attached "inverted" (i.e., the bottom node being used to attach it to the bottom node of the parent part), the thing was getting screwed at OnLoad. Further analyzing this code, I realized that it is, also, rooted on my initial misdiagnosing - I ended up rewriting a good fraction of TweakScale without being needed at all, as the unique problem on the original TS code is not being able to look for nodes on the Variants (as that code knows squat about it at first place) So, now, instead of fixing the redundant code, I removed it and I'm reusing original TweakScale code - but adapted to fetch the Attachment Nodes from the Variant when available. Interesting enough, I'm fighting a glitch on the thing where the parts are being placed slightly ahead of the ideal position - this is what I'm working at the moment (as time allows). Gambiarras are not a bad thing by definition - they may be the best technical solution given a specific problem (are you aware that adhesive tapes now and then are used even on airplane's engines, right?) The problems are: Misunderstanding them as a proper, robust fix. Forgetting about them and building code over it, relying on the side effects (something, most of the time undesirable) And this explains the whole drama - as well a lot of problems on KSP, by the way. Early this year, once I proper diagnosed the problem, I found what appears to be the root cause: when the craft you are building starts with a part without variant as root, and it is followed by another part without variant, the ModulePartVariant fails to initialize itself and the whole craft is royally screwed. By starting the craft with a Variant, or having the second part as a Variant, the problem is not triggered and everything works as expected. Or something like this, I forgot the gory details, I think I have it documented on a issue somewhere on the tracking (perhaps on KSP-Recall one). So I'm guessing that whoever was in charge on fixing this problem never really diagnosed it as I eventually did, and so shoved a hell of a gambiarra on the Editor to work around the problem instead of fixing it. Then this stunt screwed TweakScale (and a lot of add'ons more - it only happened that I was the one stubborn enough to try to tackle the problem down), but I ended up doing another gambiarra over the initial Stock one. On KSP 1.9.x the third piled up gambiarra started to cause me problems (but, to make things absolutely clear, I'm pretty sure my first gambiarra, the second on the chain, screwed someone in the mean time). And now we are where we are.

Humm…. Do you know what? If you reinstalled the very same add'ons you had before, I can think on two possibilities: Some patch on your rig was compromised You was bitten by an interesting and evasive Module Manager (potential) weakness on calculating and using the SHA of the files on your rig. You would not be the first one to get bitten by (2), by the way. The technical explanation is somewhat… "technical" but TL;DR: digests (and SHA is a digest) are intended to check integrity, not identity. But MM use a digest (SHA) to do exactly the later, what now and then gives you a false positive and so MM don't recalculate the patches when it should. Next time you get something weird like this, try to delete the ModuleManager.ConfigCache and restart KSP to see if the problems goes away, and only after it failing go for a full reinstall. Most of the time it will not fix the issue (collisions due the digest being used as identity are not that common after all), mas since it's a pretty cheap measure, it worths a try in the hope of avoiding a full reinstall. Cheers!

ANNOUNCE Release 2.1.1.10 EXPERIMENTAL is available for downloading, with the following changes: Fixes the Sky dimming for the Sun Implements some parameters to customise the dimming for planets. Work issues: #23 Parameterise the FoV of the celestial body inducing the SkyBox to dim #23 While working on issue #23, I realised that the real problem was the Sun not being properly handled - the code was handling Kerbol as it was a Planet, what obviously would not fly (pun not intended™). So I handled Kerbol properly. @orangewarning, this is what you asked for. At this time, the parameterising of the DarkenSky features became less necessary (if at all), but since I already had implemented it, I pushed it too. Perhaps it can be useful on custom SkyBoxes and custom Planetary systems with dozen of celestial bodies (some parameters aims to reduce the CPU tax a bit). The Kerbol handling appears to be solid, but since I didn't did any kind of testings with custom Planetary Systems I choose to be cautious and released the stunt as EXPERIMENTAL. Any help on checking this using custom planets, custom Solar Systems and with visuals like Scatterer and PlanetShine will be more than welcome! No screenshots this time, I'm in hurry. Again™… See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be published SpaceDock. Will not be published Being an experimental release, distribution will be restricted.

Occam's Razor: It is generally understood in the sense that with competing theories or explanations, the simpler one, for example a model with fewer parameters, is to be preferred. If we have a misbehaviour happening only a part while TweakScale (and the Companion) works in everything else, it's more reasonable to assume there's a problem on the part itself and not on TweakScale (or the Companion). I need more evidence in order to pursue the problem from the TweakScale Companion side - until there, I will pursue the hypothesis of being something wrong with the Panther or with the patch applied to Panther. I will do further tests as time allow, but since the misbehaviour couldn't be reproduced (yet) on a Stock part, I'm considering this as an "unrelated" bug. At least on the short term while new evidences aren't revealed. — — POST EDIT — — It's definitively unrelated. On the same testbed used before, the Panther 's plume is scaling allright! From now on is, definitivelly, something else on your rig. I can try to help, please send me the full KSP.log (and it must be the KSP.log), the Log/ModuleManager logs (all of them) and also the ModuleManager.ConfigCache from your GameData. You can zip the whole shebang and publish it on DropBox or something - or, if you have a github account, you can paste de zip on a comment on this issue: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/issues/5#issuecomment-1238652108

Going Full Kerbal on RealLife(tm): take out a v12 from a Lamborghini and build a motorcycle around it!

So your problem is lack proper support for some parts. Waterfall recognises patches for SmokeScreen AFAIK, so perhaps you should install SmokeScreen and the SmokeScreen support for the Panther? I think this will solve your issue - and SmokeScreen is a serious improvement over the Stock plumes - so it worths to have it installed to have some visuals for parts that doesn't have Waterfall support yet. (and the thing works fine with TweakScale!)

Hi! Right now, there's no way to accomplish what you want. The code that calculates how much the skybox should be dimmed takes into account the distance and the size of the brighting bodies (as well the camera's FOV), and the "sensibility" is not parametrizable. But I found some constants that once mangled will accomplish what you want, the trick will be extracting meaning from these constants to allow understandable parameters. In a way or another, that piece of code appears to be optimisable, so I will give it a try. I will come back to you at the end of the day. Cheers!

Can you be more specific? I built a quick testbed and found no obvious misbehaviours: I used: KSP 1.12.3 + DLCs ModuleManager (my fork, but it really doesn't matter - it mimics the Forum one even on the bugs) Latest TweakScale (2.4.6.16 at this moment) Latest TweakScale Companion for Frameworks (0.3.0.0 beta at this moment) Latest Waterfall (0.9.0 at this moment) Latest Stock Waterfall Effects (0.7.0 at this moment) (links on this post) Even that pesky bug that resets the plume's scaling on Revert to Launch is still there (really need time to tackled down this one, it will be one of that bugs that you take days to diagnose and 15 minutes to fix…). One thing that I noticed is that I left the 0.3.0.0 flagged as Pre-Release, so there's a chance that you may be installed 0.2.0.0 instead. If this is the case installing TSC-F 0.3.0.0 will fix your problem. Otherwise, please send a craft file and a KSP.log where the problem happens - it may be some Kraken Food (bad interactions between PartModules). Cheers!