Lisias

I think we got a pretty weird misunderstanding, handled on PVT. TL;DR: by some crossed-wiring on the communication, it was my understanding that I should wait for his agreement on a release before releasing the thing on MIT (Expat), and apparently it was his understanding that I would first release something working on KSP 1.12. So we ended up in a dead-lock - it's probably my fault. I'm cherry-picking the commits from the private repository into the public, double checking everything (again - something always is left behind, no exception this time) and by this Saturday an Experimental release will be published.

Insane. Absolutely insane!

Ah, but this is something I can explain! I'm a big fan of the anime, watched both versions (the original and the remake), as well the live-action (not bad, to tell you the true). Earth was being devastated by an alien force, people managed to stay alive by hiding underground and the seas were vanishing exposing the seabed where Yamato was laying. So the Earth forces, desperate for a new long range spaceship to fulfil a interstellar mission that could save the day, choose to use Yamato as it was accessible, it was a solid block of metal already available and the aliens would never believe someone would build a spaceship from a God-knowns-how-many-centuries-old wreckage. And it could also sail as ship on Earth and Alien oceans, what rendered some very nice naval battles on the series. Oukey, lame God in the Machine plot - but it worked for the anime!

Hi, @ttr! I finally had time to gave this another look. Since the exception had happened between two KSP-Recall modules, I wondered if it could be involved somehow and opened this issue for it: https://github.com/net-lisias-ksp/KSP-Recall/issues/40 TL;DR, it's something on Deep Freeze for sure. But it's not exactly DF's fault, because I tested it on KSP 1.9.1 (while probing it on KSP-Recall), and it worked perfectly fine. So something changed on KSP 1.12.3 specifically (as on its thread is state it works on 1.12.x, so the change must be recent), and this change caught DF with its pants down. The good news is that I pinpointed exactly where the problem is. As soon as I have time, I will try a fix myself and then do a pull request to the maintainer - but the problem is so easily fixable that if the maintainer is informed about it, he can release a new version with it fixed in half an hour - so perhaps you would want to report this to him ? You are the original reporter! Cheers!

I have a fully operational MIT compliant release, waiting for authorisation to go ahead (as I need the authorisation to relicense the thing to MIT). It's essentially the assets from the last MIT licensed package, but with the newer code. It still has a dependency on World Stabiliser, though.

Ah, Yamato!! Great anime! But I would like to recommend you to reading about the original one too! Did you know that they had planes and cranes to launch and recover them from the sea? Think on Infernal Robotics and KAX!!! And the thing was huge! A great source of inspiration for anyone using BDArmory, Large Boat Parts Pack and TweakScale!!! Sources: https://weaponsandwarfare.com/2020/01/14/yamato-1941-part-i/ https://weaponsandwarfare.com/2020/01/14/yamato-1941-part-ii/ https://weaponsandwarfare.com/2020/01/14/yamato-1941-part-iii/

It's a you tube video, it should had rendered for you. Are you on mobile?

NOTAM Recently, an issue was reported on KSP-Recall about a misbehaviour when interacting with Procedural Parts (issue #41). At that time, I didn't managed to reproduce the issue. My tests were biased on changing the Procedural Parts, when the problem was with DEFAULT Procedural parts - once you change the shape of the part, things worked fine. Unfortunately, it took me 20 days to realise the root cause of the problem, what I would probably take yet another 20 days without the help of DRVeyl, as well the help of StonesmileGit. Thank you very much, guys! But eventually I nailed it. I applied a pull request with the fix to procedural parts. In the mean time, I also detected some opportunities for improvements on KSP-Recall itself, in which I had worked in the mean time and now it's currently under testing. Both change sets (on Procedural Parts, and on KSP-Recall) will fix the problem individually, but the Procedural Parts one will fix the root cause at once, preventing that something could be triggered again later by another add'on that needs the correct nodes's definition being on the Part's Config when OnLoad is called. In the mean time, users affected by the problem (i.e,, having installed KSP-Recall and Procedural Parts) can copy this patch into your GameData. This is exactly the same patch I used on a pull request into the upstream: On the not so bright side, unfortunately I took too much time to diagnose and fix the problem, and this ended up prompting the Procedural Parts guys to ask CKAN to declared KSP-Recall in conflict to Procedural Parts, preventing CKAN users from installing KSP-Recall (and, so, TweakScale that depends on it on KSP 1.9.1 and newer) when Procedural Parts is present. And vice-versa. As a compromise to prevent this measure what would harm users of TweakScale and Procedural Parts, I had agreed on testing Procedural Parts for problems on each new KSP-Recall release. So, in order to fulfil my part of the bargain, I will need some more days of testing before publishing the next release. In the mean time, I kindly ask Procedural Parts users to use (even than temporarily) the patch I published above. Cheers! — — POST EDIT — — Pinging @Galland1998, as you were the first to report this. Sorry taking so long!

Ahh!! So this is the reason that huge and terribly heavy wheels ended up floating!!!!

Hi! Lately I'm more tired than busy - one consequence of workloads that endures for months is that a lot of things on Real Life ends up getting sidetracked, and once the workload ends (by a reason or another), you have all that backlog to handle. There's a file called PartDatabase.cfg on your KSP's root. It's where all the parts' information are consolidated for easy access. After loading the Textures and Models, KSP starts to read and "compile" the parts from the config files. When a new part not present on that database file is fount, this message is printed on the log. Delete the PartDatabase.cfg and then fire up KSP - you will see this message for every part found. Then quit KSP and fire it up again, and you will note that no issue of that log will be found. About the drag cubes, it's the same. KSP doesn't measures drag precisely, it uses on inaccurate approximation that it's good enough for the game purposes. This approximation is the drag-cube, literally a cube used to measure how much drag a part will cause - I do not really know how it is calculated, I just take this for granted, but if you go check that PartDatabase.cfg file you will get a long list of things like: PART { url = AirplanePlus/Parts/Aero/bigwing/part/bigwing DRAG_CUBE { cube = Default, 1.247,0.9107,1.43, 1.247,0.1293,11.17, 3.729,0.5781,0.8552, 3.729,0.3346,1.992, 21.76,0.9629,0.4668, 21.76,0.9634,0.4668, -5.467,-0.182,-2.858E-07, 11.2,2.366,0.7374 } } And there it's your drag cubes. Some parts specify it's own drag cubes "manually", see the ./Squad/Parts/Aero/miniIntake/SmallIntake.cfg (took from KSP 1.4.3 as I using it to do some research now): PART { name = miniIntake module = Part author = Porkjet <yada yada yada> tags = #autoLOC_500198 //#autoLOC_500198 = aero (air aircraft breathe fligh inlet jet oxygen plane subsonic suck DRAG_CUBE { cube = Default, 0.1813352,0.6919296,0.4108824, 0.1813352,0.6919321,0.4108824, 0.3032565,0.4,0.3950377, 0.3032565,0.942507,0.1303004, 0.1813352,0.6928801,0.4108824, 0.1813352,0.6909673,0.4108824, 0,0.1324531,-2.368446E-08, 0.625,0.3274064,0.6250001 } See? You can specify yourself the drag cube (if you know how to do it ), or you can trust KSP to calculate it for you. When KSP does it, it prints that message about drag cubes on the KSP.log. Cheers!

ANNOUNCE Release 2.1.1.7 is available for downloading, with the following changes: A major screwup on Mono's libraries was detected and worked around by KSPe.Light. Whole history available here. Formalizes support for KSP 1.3.1. #HURRAY!! I'm not 100% certain, but all the tests I made suggests I found a File Handler leakage on a Mono's low level library used by KSPe.Light. This Release merely update KSPe.Light to a version where the problem was (apparently) successfully worked around. On the bright side, I spent a lot of time playing KSP 1.3.1 lately (just because I could), and DOE /L behave perfectly. So I'm formalising the KSP 1.3.1 support on this Release. 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. Right Now. SpaceDock. Right Now. The rationale is to gradually deploy the thing in order to cope with eventual mishaps before it reaches too much people.

AFAIK, Kerbalism removes should TweakScale from all the parts it needs to be installed, as Kerbalism does some processing when the craft is packed (i.e., removed from the Physics and shoved in the "Rails" stunt) and so TweakScale it not active to scale up things. Let me check it again on Kerbalism's repo... <hack, hack, slice and hack again> Humm.. Nope. I found an Issue where it was mentioned that removing TweakScale from the parts with Kerbalism modules would be only practical solution, but as far as I could check on Kerbalism's repository, there're no such patch yet. On a rule of thumb, everything that Kerbalism touches must have TweakScale removed . Since I don't know Kerbalism, I can't tell you what modules should trigger a TweakScale removal. You will need to reach Kerbalism's maintainers for such. Once someone lists these modules, writing a patch for removing TS from affected parts is a breeze.

Looks like something is changing the binary signature of some files in your installment. Not a good thing, if you ask me... Do you use CKAN or CurseInstaller? If yes, you may want to check with them to see if they help. If not, I would consider updating the antivirus. Virii are usually the ones that changes DLLs in an attempt to spread themselves (what would change the binary signature and then triggering Steam to redownload the files) - but this is a wild guessing...

Whopsy, sorry taking that much! (New users need to get moderation approvement for initial posts to prevent spam, and so it took some time until I could see yours). Anyway, getting to the point: you got bitten by a nasty bug on a KSP internal thingy called Assembly Resolver (yada yada yada ) that screws up everybody once some poor add'on steps on the land mine. So we need to find this unlucky add'on, fix it and then everybody else (including TweakScale) will be able to work fine again. USUALLY the mine stomper stand-up guy is the first Reflection or Loading Exception on the log, but it happens that in your case, it's exactly TweakScale, so I initially thought that I had screwed up the Distribution file (again… - hear it on the voice of shadowzone…). So I downloaded them to check. It's everything fine (and the thingy that could be missed was found on the Log anyway, so I panicked too early!!! (once bitten, twice shy ). So, back to digging, I realised that almost immediately the TweakScale borking, there was a footprint from a known troublemaker, MiniAVC: [ERR 19:23:06.605] ADDON BINDER: Cannot resolve assembly: MiniAVC.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 19:23:06.605] ADDON BINDER: Cannot resolve assembly: MiniAVC.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 19:23:06.605] ADDON BINDER: Cannot resolve assembly: MiniAVC.XmlSerializers [LOG 19:23:06.658] Load(Audio): AirplanePlus/Sounds/109_startup [LOG 19:23:06.785] MiniAVC -> System.Net.WebException: The request timed out at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00049] in <ef151b6abb5d474cb2c1cb8906a8b5a4>:0 at System.Net.HttpWebRequest.GetResponse () [0x0000e] in <ef151b6abb5d474cb2c1cb8906a8b5a4>:0 at MiniAVC.Addon.FetchRemoteInfo () [0x0002e] in <946c68c810554a77bc35cab54adcb678>:0 at MiniAVC.Addon.ProcessRemoteInfo (System.Object state) [0x00045] in <946c68c810554a77bc35cab54adcb678>:0 So this explains things, thankfully! Install ZeroMiniAVC and it will keep your system clean from it, avoiding this problem. Once every MiniAVC is removed from your rig, things should run fine again. [Not yet, I found something else, see below.] On a final note, I found three Module Managers on your rig. This is really bad, because since KSP 1.8.0 we have yet another bug that induces the OLDER Module Manager to be used, and so you are still subject to older MM bugs besides having the newest one installed: ModuleManager.4.1.3.dll ModuleManager.4.1.4.dll ModuleManager.4.2.1.dll Remove the 4.1.3 and 4.1.4 files, leaving only 4.2.1 on your GameData. You have ModuleManagerWatchDog installed, it should had barked on you about. I need to check this tool The size of the log is not a problem, I have some tools that make my life easier this problem is an old "friend" since 1.8.0 - so most of the time I know exactly what to look and how, it takes me less than a minute. Most of the time, as this issue of yours was different! Cheers! — — POST EDIT — — I kept digging, because MiniAVC besides being a trouble maker, didn't borked in a known way the triggers that bug on the Assembly Resolver. I'm glad I did it, because I found this: [ERR 19:23:35.941] MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading TweakableDeployablePanels, Version=0.2.1.0, Culture=neutral, PublicKeyToken=null: Sy at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at MuMech.MechJebCore.LoadComputerModules () [0x0002d] in <07394c03495949be9205a3c7a0b33845>:0 The TweakableDeployablePanels are throwing exceptions everywhere on the KSP.log, by the way. A bit later, I found this: [EXC 19:23:36.987] FileNotFoundException: Could not load file or assembly 'ToadicusTools, Version=0.22.4.4, Culture=neutral, PublicKeyToken=null' or one of its dependencies. PartModule.Awake () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) Part:AddModule(String, Boolean) Part:AddModule(ConfigNode, Boolean) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [EXC 19:23:36.994] FileNotFoundException: Could not load file or assembly 'ToadicusTools, Version=0.22.4.4, Culture=neutral, PublicKeyToken=null' or one of its dependencies. PartModule.Awake () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Object:Instantiate(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) AND THIS is a trigger for the Assembly Resolver bug!! You need to install ToadicusTools whatever it is (I have some remembrance about this DLL, but I can't remember from where, sorry!). Since TweakableDeployablePanels is also borking a lot on your KSP.log, perhaps the TweakableEverything maintainer can help you o this?

There are more people using Windows XP than Windows 11!!!! Source: https://www.pcmag.com/news/windows-11-adoption-is-lower-than-windows-xp-survey-claims

Whoops, I fell asleep! Back to action, there's a problem with ELHelper - I think this is from Extraplanetary Launchpads. [ERR 16:19:11.001] AssemblyLoader: Exception loading 'ELHelper': System.Reflection.ReflectionTypeLoadException: Exception of type 'Sys 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 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' File name: 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' You will probably need to reach the Extraplanetary Launchpads maintainer to get help about who to fix this, but on a wild guess, your EL installation is half-backed, it's missing some DLL on it. Perhaps by reinstalling this Add'On from scratch would help! Cheers!

Kraken knows. It could even make things worse... Wait a bit, I'm looking into the KSP.log now as soon as you grant me access.

Yes, I need the full KSP.log. TL;DR: you was bitten by a nasty KSP bug on a thingy called Assembly Resolver (yada yada yada ). Once it happens, everything and the kitchen's sink borks too due the splash damage. We need to find who is stepping on that land mine. We solve that dude's problem, everybody else will be fixed by collateral effect.

(sigh) So it's that crap from KSP 1.9.0 that still haunts us until nowadays. The latest KSP-Recall is this one: 0.2.2.3 - https://github.com/net-lisias-ksp/KSP-Recall/releases The latest TweakScale was just published: 2.4.6.11 - https://github.com/net-lisias-ksp/TweakScale/releases (but it fixes an unrelated problem - you should be find even by using 2.4.6.8. or 2.4.6.10 — do not use .9, I screwed up this one). BACKUP EVERYTHING (just in case), then update these two above, and try again. If the problem it's still there, I will need to eye ball your craft file looking for the problem (I'm becoming pretty good on this… Some more time, and I will be able to play KSP using pen and paper!!! ). Being the case, remember to send me also the full KSP.log. About the new KSP 1.11 lights… It's my understanding I had already created patches for them... I will double check this now. — — POST EDIT — — Yep, the patches are there. Everything works as "expected", including the symmetry error on the directional lights!

Be sure to have installed the latest KSP-Recall and the latest TweakScale. If by updating everything, you still have the problem, publish your full KSP.log, the craft-file suffering from the problem and I will inspect it for the cause. It's a long history, but TL;DR in KSP 1.9 a less than ideal workaround was shoved on Editor by Squad, and this workaround screwed up a lot of add'ons (it only happens TS is very used, so its more exposed…). I'm fighting this crap for years already, but only really understood it recently. It's possible that some other PartModule could be fighting TS or Recall over the workaround for the Editor's problem. — — POST EDIT — — As evidence it's a problem on KSP Editor, you can launch your truck directly into the RunWay. Of the truck starts OK, we know for sure it's the Editor problem screwing with you.

ANNOUNCE Release 2.4.6.11 is available for downloading, with the following changes: Fixes a subtle and insidious problem reported by BTAxis. Thanks, dude! Closes Issues: #244 Reactivating TweakScale is disabling the sc See OP for the links. Disclaimer By last, but not the least... — — — — — 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. (All your Distribution Channels are belong to us! - Updating everything at once this time)

This is highly undesirable! (And I already found the problem: https://github.com/net-lisias-ksp/TweakScale/issues/244 ) In the mean time, you don't need necessarily to delete the part and add a new one. You can re-activate TweakScale on the parts in need, then save the craft and then reload it. This will allow you to TweakScale the parts again - until the next TweakScale release, when this is going to be fixed. Cheers!

NOTAM For people willing to use alternate channels for getting Support, I'm opening a Discussions on TweakScale's github repository to properly handle them. Please understand that using GitHub issues are not the recommended way of reaching me for Support anymore (it was becoming messy…). Please note that you **need** to tag me there using "@Lisias" on the the text, or I will not be able to respond in a reasonable time! (sorry to anyone that got lost on this less than ideal GItHub's notification system) Cheers.

Take a biplane with huge wings, shove on it the biggest engine you could find. Use a suit that looks like somethings from Julio Verne's 20.000 Leagues Under the Sea. Take off in 5 seconds, so overpowered is the whole setup. Climb to 56.000 feet, near the verge of the space. Using. A. Biplane. This is so marvelously Kerbal that I had to do something about!

Asking on the right thread helps a lot! This is almost surely something borking on loading a dependency, that so triggers a nasty bug on KSP's Assembly Resolver yada yada yada and then screws up TweakScale because it does heavy use of the things the KSP's bug screws up. Send me your FULL KSP.log on dropbox or something on the TweakScale thread (or even in PVT if you prefer) and I will inspect it and diagnose your problem! Cheers!