Lisias

On this specific issue, that DLLs are borking right on the spot, so it's not related to MM for sure. Only wen you find a thingy called "Exception" inside Module Manager's guts, trying MM3 first can (but not always) help. AT-Utils is a Add'On from Allista: https://forum.kerbalspaceprogram.com/index.php?/profile/99885-allista/ I can't help on it for now, as I never dug on that code and so, I don't know what can be happening. Currently, I'm not using anything that uses AT-Utils neither, otherwise I could try something on my KSP to see what's happening. If you need AT-Utils, some Add'On you installed depends on it (there more than one), perhaps someone on that Add'On thread can help you too. If you use CKAN, you can try asking some directions there - that guys know better than anyone who depends on who around here.

Yep. Language barrier on the rocks! Nope. MM4 main feature is the ability to patch things at the same time the textures and meshes are being loaded. This saves some time, but bow and then something breaks. They are nailing down these glitches (if any is left), so it's still a good idea double check this before reporting problems. Other than that, MM3 should behave identically to MM4. TweakScale mangles some really critical parts of KSP. So, when something else confuses TweakScale, we risk letting things half done, or done wrongly. And when this happens, a lot of nasty things happens in consequence. Crafts that make KSC parts to explode at launch, parts that "anchors" the whole vessel on the spot and then by applying thrusts that part explodes due stress, and even living crafts on the savegame suddenly having the scaling reset. About At Utils, if you have them installed and yet they are borking, you need to ask support on their thread. I can't help as I don't know that code. Sorry.

There's a tutorial on the Wiki: https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Installing_Addons About the Add'Ons you need for sure: Multianimators and AnisotropicPartResizer are part of the AT-Utils https://github.com/allista/AT_Utils/releases You may also choose to rollback to Module Manager 3. MM 4 new way of doing things faster sometimes make something else to gasp - it's very rare, but usually when you see MM throwing an Exception, you should try MM3 first. If MM3 works and MM4 don't, then you file a report on MM thread - otherwise, it's almost sure that the problem is some rogue Add'On. The following are things that I also detected on your KSP.log, that wasn't related to your issue, but you probably want them fixed too: DynamicBatteryStorage is a [optional] dependecy for Kopernicus, and you need [may want] to install it to fully enjoy Kopernicus: https://github.com/ChrisAdderley/DynamicBatteryStorage/releases About TweakScale, initially I was thinking that you was using a older version but then I realized that I borked the DLL compilation. So the problem I found in your Log about TS is a new one, and it's serious. For now, just check if your engines (rescaled or not) have negative mass and avoid using them as the plague. After updating your KSP, please publish everything again (obviously, with new data! hehe) on TweakScale thread, as this is now TweakScale issue and we don't want to pollute KJR's one with unrelated data, as describe in the following threads: The Module Manager's cache is on the KSP/GameData/* and the files have ModuleManager on the name. Just shove everything but the DLL on a zip and publish it, I will find my way on it later.

I understood. I'm not feeling singed out, as myself suggested that move some time ago. Maintainability. From a Software Development point of view, mixing user data, application data and application code is just plain wrong. If you do a check on the vanilla KSP, you will see that Squad never did that - the savegames have their own place, the settings have their own file, etc, outside the GameData. Mixing everything is a receipt for disaster (who used MS-DOS and Windows 3.x knows that). You just can't update your Add'On without risking losing your custom configuration data. And by carefully updating only the files that are not user configuration, you risk missing some new options implemented on the newest version. It's a plain nightmare. I don't have this problem. An update for me is always a delete from GameData, followed by a clean unzip on it. All my configuration is safe outside. This makes backups insanely easy too: just backup the PluginData, and you are done. ------------ oh, yes. KSP API Extensions... KSPe is a subcomponent of mine, where API Extensions is the whole shebang. I'm playing with some really old Add'Ons, and it was easier to update it than to update everything else. I found no reason to create yet another Add'On for the same task, so I decided to develop the new Extensions I mentioned above on it.

While I disagree that unzipping two files into KSP root is convoluted, it's nice to have something what copes better with corrupted instalments - the only situation where KSPe + KJR/L is known to Bork. Keep in mind that I support only my fork. ;-) What's make me consider moving my fork from the current file system position to be inside a "vendor directory" (KSP_ROOT/net.lisias.ksp/KJR), otherwise I risk having this other fork stomping on my feet (and vice versa) , as they are adding changes on the config XML file. Any thoughts?

Learnt something new today. Space is not limited by speed of light. Only matter and energy are. How gravity would be affected by this? https://www.forbes.com/sites/startswithabang/2019/04/20/ask-ethan-how-can-a-black-holes-singularity-spin/amp/

Well, I want to register this somewhere, but I don't know where. So, since I was working on TweakScale, why not here? Someone, somewhere, is adding a "rogue" config into Squad's folder. I found what follows on my 1.6.1 test bed: macmini:GameData lisias$ find . -name "*.cfg" -exec grep -l "name = adapterLargeSmallQuad" {} \; ./Squad/Parts/Structural/adapterLargeSmallQuad/adapterLargeSmallQuad.cfg ./Squad/Parts/Structural/stackAdapters/adapterLargeSmallQuad.cfg ./Squad/zDeprecated/Parts/Structural/adapterLargeSmallQuad_v1/adapterLargeSmallQuad.cfg Well… "Gato escaldado…" So I deleted my test bed and took a fresh one from my local repository and redid the tesst: macmini:GameData lisias$ find . -name "*.cfg" -exec grep -l "name = adapterLargeSmallQuad" {} \; ./Squad/Parts/Structural/stackAdapters/adapterLargeSmallQuad.cfg ./Squad/zDeprecated/Parts/Structural/adapterLargeSmallQuad_v1/adapterLargeSmallQuad.cfg Usually, I would pinpoint myself as the culprit on a unattended drag and drop, but this would move the file, not copy it. And the file contents on the "stackAdapters" were vastly different from the other two ones. So if I did it, I did from another completely unrelated place - unlikely, but not impossible. Since it's my test bed for 1.6.1, until recently the KSP mainstream, this poor installment had some really bad times on Add'Ons testing. So I'm placing my bets on a rogue Add'On mangling Squad's territory. Some more research work is scheduled for this week. This need to be solved, such rogue config is messing up the default parts. I will, of course, check first if it's something I did by accident, and then I will pursue whatever did this and report a change request to the maintainer (assuming it wasn't me. )

It's the same from my side. We will have to agree on disagree on this matter. Respectfully, I have the impression you doesn't fully understand some Software Development concepts. Not meant to be rude, just trying to express an opinion. LGG is an important Maintainer on this community, but it's not wise to behave as he would be the only one. Things we do affect other people's lives. Saving a minute of mine at expense of many minutes of many other maintainers is not exactly team work on my book.

People will use what serves them best. On Open Source you just can't force them to something they don't want, as they will just fork the thing and you will see your users going away. Yes, they are paying nothing to you - we usually rely on donations and patronage. However, if people fork your project and start to use the fork because it serves them better, you will see that the same people will have less reasons to keep supporting you. You also forget that we, Add'On Authors and Maintainers, are players too. We do play KSP too. Non authoring players are not the only one being beneficed by the works. And we, too, want to expend less time fixing things that are not broken without a good, compelling reason - as this would hinder our free time to expend it on the really pressuring issues - as showstoppers bugs and new features. Or plain playing KSP. Some fixes are worst than the problems they aim to fix. This is probably one of these for the majority of the cases (but not all, as I had tested and proved on my Experimental forks).

I jumped from the bed , this error is a serious showstopper! So apparently you managed to find a new way to get this error. I will check the log with care. I just checked your log, and you are not using the latest . The latest, 2.4.1, fixes some more issues, and I think yours can be one of them (the hint being some non scaled parts also triggering the Anger of the Kraken). Please update and check again the same crafts. Publish the new KSP.log and Module Manager caches too, if you find the error again.[You are using the latest, I borked on the DLL version info!!!] Assuming I detect a new problem with your current KSP.log and MM caches, and/or you report he same happening on 2.4.1, 2.5 will be put on hold and I will issue a new 2.4.1.1 just for this fix the fastest I can. Thanks, dude. I really appreciated. I can't always respond as fast as I wish due pressuring issues on Real Life (tm), but we (not just me) do whatever we can to keep you flying safe. (or as safest as it would be fun to fly!! )

Simple answer: serving a good service, without promoting unnecessary breakage. It's already harsh when you promote a needed breakage - you do it just because, and you start to loose users. There's no need for a Maintainer for Add'Ons that no one wants to use.

Jesus Christ! Something like this issue? https://github.com/pellinor0/TweakScale/issues/83 Yes, this is somewhat serious, as this error propagates into the launched vehicles and "contaminates" your savegames. I urge to stop playing this savegame now, and send me your KSP.log as soon as you can, as well the Module Manager caches. All of them (just in case). Are you using the latests TweakScale? (2.4.1.0) If not, please update as soon as you can. See the OP for details, read all the read notices and links. Backup everything, as the code isn't aways able to correcly fix the issues it find, and manual intervention ends up being necessary to salvage your savegame. Load and save every craft before using them again with the latest version. Crafts with this problem will sooner of later induces the near statics to blow up, due the propagating of NaNs related to a badly instrumented Part with variants with mass. There's no other safe measure than to update to the newest and take the hit of such parts having their TweakScale support withdrawn (savegames with parts using these "contaminated" parts will have the parts reset to default, so backup your savegames). This is unhappy, but it's the only safe option until the release of TweakScale 2.5, currently being cooked.

KJR/L is dependent of KSPe, and KSPe is known to bork due a serious bug on Mono's runtime, when a DLL is loaded as dependency of other, and it fails by some reason (usually, by not be installed). And this is 99% of the reasons people ask for support on KJR/L and, well, there's some of there problems on your KSP.log: [LOG 18:52:32.184] AssemblyLoader: Loading assembly at C:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\[x] Science!\[x] Science!.dll [LOG 18:52:32.208] AssemblyLoader: Loading assemblies [ERR 18:52:32.249] ADDON BINDER: Cannot resolve assembly: 001_AnisotropicPartResizer, Culture=neutral, PublicKeyToken=null [ERR 18:52:32.249] ADDON BINDER: Cannot resolve assembly: 001_AnisotropicPartResizer, Culture=neutral, PublicKeyToken=null [ERR 18:52:32.251] AssemblyLoader: Exception loading 'MultiAnimators': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly '001_AnisotropicPartResizer, Version=1.2.0.4, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: '001_AnisotropicPartResizer, Version=1.2.0.4, Culture=neutral, PublicKeyToken=null' and: [ERR 18:54:35.625] [ModuleManager] Post run call threw an exception in loading 002_MultiAnimators, Version=1.1.0.2, Culture=neutral, PublicKeyToken=null [EXC 18:54:35.626] ReflectionTypeLoadException: The classes in the module cannot be loaded. System.Reflection.Assembly.GetTypes () ModuleManager.PostPatchLoader+<Run>d__16.MoveNext () UnityEngine.Logger:LogException(Exception) ModuleManager.Logging.UnityLogger:Exception(String, Exception) ModuleManager.Logging.ModLogger:Exception(String, Exception) ModuleManager.<Run>d__16:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) The previous problems appears to be the root cause (until the moment, only exceptions that follows a "[ERR hh:mm:ss.mmm] ADDON BINDER" style are confirmed to break things). Install the Add'Ons that provides that DLLs and you should be good. The following ones (until the moment) are not confirmed to be problems (usually, fixing the above ones solves for good). But you probably would want to fix them, as you installed the Add'Ons for a reason : [EXC 18:52:33.029] TypeLoadException: Could not load type 'System.Runtime.Versioning.TargetFrameworkAttribute' from assembly 'DynamicBatteryStorage'. System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) System.Reflection.Assembly.GetCustomAttributes (System.Type attributeType, Boolean inherit) Kopernicus.LogAggregatorWorker.Awake () UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>c__Iterator1:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>c__Iterator0:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>c__Iterator0:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) In time, apparently ModuleManager is taking some hits from the same problem. I suggest you confirm this with the MM guys; [LOG 18:54:35.539] [ModuleManager] #### BEGIN MODULEMANAGER LOG #### [EXC 2019-04-21 18:52:39.949] System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at ModuleManager.ModListGenerator.GetAdditionalModsFromStaticMethods (IBasicLogger logger) [0x00000] in <filename unknown>:0 [LOG 2019-04-21 18:52:40.001] Checking Cache I also found some more on the Log, and these ones are "safe". I'm posting them here to document them - you can ignore them unless you decide yo want that features. [ERR 18:54:35.763] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [ERR 18:54:35.763] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [ERR 18:58:31.700] ADDON BINDER: Cannot resolve assembly: RecoveryController, Culture=neutral, PublicKeyToken=null [ERR 18:58:31.700] ADDON BINDER: Cannot resolve assembly: RecoveryController, Culture=neutral, PublicKeyToken=null Finally… (sigh) I found a Exception on the prefab phase of TweakScale (and this one I support directly). I noticed that you are still using TW 2.4.0. I recommend you to use the 2.4.1, that added a few small features and fix a nasty problem. If after updating this exception persists, please kick me on the TweakScale thread. [EXC 18:58:04.469] NullReferenceException: Object reference not set to an instance of an object PartModuleList.Contains (Int32 classID) PartModuleList.Contains (System.String className) TweakScale.PrefabDryCostWriter.checkForSanity (.Part p) TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) This exception, by its nature and location, it's a clear example of Kraken Food (see my signature ), but chances are that the changes I did on 2.4.1 would be beneficial to you. (Faith programming, dude! ) — — — POST EDIT — — — — I just came my attention that I borked beautifully on the DLL versioning. (sigh). You are using the latest, my apologies. Please be in touch on TweakScale Thread about this specific issue. There's a new bug in town, TS 2.4.1.1 will be issued soon.

No, sir. You are wrong. The probe was merely permanently unassembled on landing, and are currently waiting new mission plans to cope with the current configuration.

Recording audio while screen recording on a Mac is still a challenge here. Apple sometimes does things that you just can't understand. Next time I will record the audio using JACK and Audacity separately and mix the data on ShotCut. Yep. Totally your fault!

Publish your KSP.log, as explained here:

I finally decided it's time to embarras myself using a video, and not only on screenshots. So I made this long, boring showdown of KSP Demo: Try not to die of boredom while watching this tragedy… Inspired by this post:

The fallout would endure for years. Look to the entire KSP 1.4 series for example. Lots of needed changes, and lots of breakage and cursing in the meantime. for critical things, where not doing it would be fatally worse than the fallout, OK. If you are going to "die" do it on the less painful way possible. but for non critical issues, it's almost suicidal in my book!

Because it would add an extra step on the porting efforts. And you would be surprised about how easy (however still worksome) is to fix them to.be usable on 1.7 The UUID idea is not bad, but I think it's unnecessary. A compromise between the current statusquo and the proposed one would accomplish the same with fewer breakcage. Using symlinks perhaps. There shouldn't never be two Firespitters installed anyway, so "Firespitter" is already a de facto Universal Identifier.

The master.zip is just a convenient way to download the source code for people not willing to use GIT. It was not intended to you. End users should stick with the release zips, the first one on this link: https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

Not too much critical, as anything wrong would cause the exception you detected. DLL have this name for a good reason: they are Dynamic Linking Libraries, i.e., the code is linked in runtime, not on compile time (or even loading time). Jumping over versions can be a problem when the interface is preserved (ie, the function has the same parameters and return type), but not the contract (the function does something different than expected). But this is not a problem while compiling, but while running - and Microsoft is not (too much) dumb, they preserve the function's contracts between major versions. On this specific case, it's the compiler the source of the trouble - since it was told to target the 4.x version, the compiler generated code that relies on new classes and methods that are not available on the 3.x version. About the sloppiness… It's more a unattended mistake on what is called "configuration management" than a bad practice on programming. Microsoft Visual Studio automates everything it can to make the programmer's life easier, but now and then the defaults changes to newer versions of the libraries, and the programmer is not notified and the guy just realizes the problem on deploy.

Yep. It's because the release in on the release page on github. https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

Welcome aboard, @St4rdust! Sit tight and fasten your seatbelt. It's going to be a wild ride! Keep Jebediah out of the cockpit, just in case.

I'm already overwhelmed by what I got in hands. TweakScale is a lot of work for now, and I will not manage to give it the care it needs. Look for the date of the latest release, and you will se what I mean. I probably will adopt it for good in the (not so) near future, but now I just can't. Yes, it's going apart from current "mainstream" behaviour. Parts are saved somewhere else, configurations are kept in the ROOT\PluginData directory. These are non mainstream behaviours for now. I have a component called KSPe, currently embedded into KSP API Extensions, that would allow me to give a option to the user: "my way" or "standard way", what's different from the current implementation : "my way or the highway". But yet, I need more time than I have available nowadays to overcome or fix some nasty (and stupid) bugs on Unity's Mono fork - until there, releasing KSPe (and everything that depends on it) on the mainstream is looking for trouble.

These binaries are known to work from 1.2.2 to 1.7, no recompiling needed.