Lisias

Just a small addendum: when I published the Announce, I was a bit in a hurry because I had some RL duties to cope - and I ended up not writing it correctly. The bug on Editor is only noticeable when using Add'Ons that change the part's position (as TweakScale), since Editor by some reason I can only speculate is shoving back default values on the craft once you load it on the Editor, bluntly ignoring whatever is the value on the craft file at this moment. (launching the craft directly on Runway or Launch Pad works fine, it's an Editor only problem - and it happens only at loading the craft to memory, saving it is OK). However, since AttachedOnEditor is now overruling whatever is happening on Editor since KSP 1.9, some collateral effects are happening: SOME parts (not all, just some - I'm trying to figure out a pattern on this mess), when used as root of a SubAssembly (being it loaded from the SubAssembly Menu, or loaded from a craft file using Merge, or even by Alt+Click on a subtree) is misplacing badly the part attached to it when this part has Variants. It's not known at this time if this is an unexpected side effect of AttachedOnEditor (possible, but I'm scratching my head for weeks trying to find a reason for this), or if something broke on Editor when something was added on KSP 1.9 and the blunt overwrite was the way they found to mask the problem (somewhat more likely, as it appears to be a flaw on initialising SubAssemblies once they are loaded - but I bashing my SAS trying to figure out a way to prove that). The way I originally wrote the Announce was implying that the problem could be noticed on a pure Stock installation - to tell you the true, I just didn't tried to do so on a vanilla installment. Well… Back to the workbench. I have promises to keep and miles to go before I sleep!

Send me the SubAssembly with the problem, please! Click on New, select the borking SubAssembly and save the craft as "Borking SubAssembly" or something. The SubAssembly will be alright, as doing this way doesn't triggers the problem - the problem happens when some parts are the root of the SubAssembly, these parts are alright when they are the root of a craft. Apparently, selecting a SubAssembly on a empty workspace loads it as it was a craft! Cheers (and thanks!)

Hi! You was bitten by a nasty bug on KSP's Assembly Loader/Resolver, yada yada yada . Usually, the first Reflection exception pinpoints the culprit. In your case: [ERR 01:55:10.438] AssemblyLoader: Exception loading 'ELHelper': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.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 <cd473063d3a2482f8d93d388d0c95035>: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' or one of its dependencies. File name: 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' The Launchpad Assembly was not found to be loaded. but ELHelper needs it. Your options are to remove GameData/WildBlueIndustries/Sandcastle/ or to install the Add'On that provides LaunchPad - you need to reach Sandcastle's maintainer for further help. Cheers!

ANNOUNCE KSP Recall 0.2.1.4 is on the Wild, featuring: Implements a missing use case, handled on #34 Works the issues: #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor A bug on KSP was discovered, affecting the Editor since KSP 1.9, where some parts trigger a weird misbehaviour when set as the root of a SubAssembly. This misbehaviour happens when loading a Craft for Merge, when loading a SubAssembly from the SubAssembly palette, and when copying subtrees of a craft using Alt+Click. EDIT: When Add'Ons that change the parts position are installed! The current workaround is to avoid the situation where these parts end up being the root of the SubAssembly. See the KNOWN ISSUES file for details, or the following links: Got a bug with a subassembly here on Forum Issue #34 on GitHub About the Future Recent events on KSP-Recall's issue tracker suggests that it may be a good idea to retake KSP-Recall development - at least, for the most serious bugs on KSP. At the very least, KSP-Recall will serve as Diagnosing tool and Fix/Workaround test bench - even by not being able (due legal reasons) to implement the fixes on a more transparent way, KSP-Recall appears to be the place where the way for better fixes can be paved. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Right now. SpaceDock (and CKAN users) Right now I updated everything at once as this is a minor update on an already proven workaround.

For urban commuting, I think this one would be a better option:

I surely made some of these on KSP! Engesa Mercedes Benz LG-1519 6x6 Mamute

TweakScale is being victim of a nasty KSP bug - when a DLL fails to load a dependency, the Assembly Loader/Resolver (the guy responsible for loading DLLs on KSP) goes nuts and from that point, nobody manages to load a dependency manually or to safely use the C#'s Reflection library. And TweakScale makes use of both these things. Looking into your KSP.log, I found this: [LOG 17:37:24.911] [AddonLoader]: Instantiating addon 'SnackApp' from assembly 'SnacksUtils' [EXC 17:37:24.943] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. System.Reflection.Assembly.GetTypes () (at <9577ac7a62ef43179789031239ba8798>:0) AssemblyLoader+LoadedAssembyList.GetPathByType (System.Type type) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) AssemblyLoader.GetPathByType (System.Type type) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.IO.IOUtils.GetFilePathFor (System.Type T, System.String file, Vessel flight) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) Snacks.Window`1[T]..ctor (System.String windowTitle, System.Single defaultWidth, System.Single defaultHeight) (at <999cf261d9714e52a7ec471e93448b7c>:0) Snacks.SnackAppView..ctor () (at <999cf261d9714e52a7ec471e93448b7c>:0) Snacks.SnackApp.Awake () (at <999cf261d9714e52a7ec471e93448b7c>: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() [LOG 17:37:24.945] [ModuleManager] Intercepted a ReflectionTypeLoadException. List of broken DLLs: VesselViewRPM 0.8.8.5 GameData\VesselView\Plugins\VesselViewRPM.dll What suggests that VesselViewRPM.dll may be broken. HOWEVER… I also found this one earlier: [LOG 17:37:21.578] AssemblyLoader: Loading assemblies [WRN 17:37:21.579] AssemblyLoader: Assembly 'CC_RemoteTech' has not met dependency 'RemoteTech' V1.7.0 [WRN 17:37:21.579] AssemblyLoader: Assembly 'CC_RemoteTech' is missing 1 dependencies And this also screws up the Reflection thingy, so perhaps the real problem is the CC_RemoteTech, or perhaps you have two problems on your rig. A quick way to diagnose the real problem is to remove ContractConfigurator from GameData and see if the problem goes away. If yes, you will need to contact ContractConfigurator's maintainer and ask him how to fix it on your rig. If the problem persists, try removing VesselView and try again. Same thing, if the problem goes away reach VesselView's maintainer and ask for help. Additionally… I found two copies of ModuleManager's DLL on your rig: [LOG 17:37:21.172] Load(Assembly): /ModuleManager.4.1.4 [LOG 17:37:21.172] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.4.dll [LOG 17:37:21.177] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 17:37:21.177] Load(Assembly): /ModuleManager.4.2.1 [LOG 17:37:21.177] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.2.1.dll [LOG 17:37:21.179] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 This is bad, because KSP has yet another bug where when you load two Assemblies with the same name, only the first one loaded is activated, and the second is "short circuited" to emulate the first. We can verify this problem by inspecting the KSP.log a bit later: Interstellar_Redist v1.4.0.0 ModuleManager v4.1.4.0 ModuleManager v4.1.4.0 000_AT_Utils v1.9.6.0 Do you see? You have the newest Module Manager installed, but are effectively using the older one. I strongly advise you to delete the file C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.4.dll . This will allow KSP to use the newest Module Manager - what's highly desirable, as the newest Module Manager has fixes that, obviously, are not present on the older one. Cheers!

THIS is what's driving me crazy! This test: Was made using THE VERY SAME CRAFT, using only Stock parts. Than I Alt+Click the parts one by one to see who would misbehave and who wouldn't. From this set, only the Stack Separator misbehave - even when it was not scaled at all! The Decoupler working fine was a hell of a surprise for me - both the Separator and the Decoupler shares a lot of characteristics (including the Module they use for the work, ModuleDecoupler), and yet, the Decoupler works fine but the Separator borks. The Decoupler has variants, and so was patched with AttachedOnEditor. The Separator does not have variants, so it was not patched with it. So the AttachedOnEditor is not part of the problem. When a part works as root, you can TweakScale it or not - they will behave as well. When a part misbehave, it misbehave no matter it's TweakScaled or not. And since I did that extra mile to disable TweakScale when the part is not scaled (and so saving a bit of CPU juice), it's obvious that TweakScale is also not directly involved on the mess - since I know the code, I know that what's happening is that TweakScale is reading bogus data about the current position of the borking part, and then when it calculates the correct position for the scaled part attached to the borked one, the parts ends up going to Kraken knows where. The AttachedOnEditor stunt was made exactly to counter act this misbehaviour - it saves the correct position of the part on it's node on Editing time, and reapply it when you are loading the craft on Editor to counter act the mess Editor is doing nowadays. My current working theory is that there's yet a new point where things are screwed, and this screwing point is triggered when some parts are the root of the subassembly. I have evidence of such two screwing points because I managed to find a stock part, the NCS Adapter: The NCS Adapter works fine on the Alt+Click, but borks when you load it from a SubAssembly! (Remember, the crafts are saved fine - the problem happens only at Loading inside the Editor). This is not random, once I detect a borking part, this part always misbehave when used as root no matter what. So it's deterministic. The hard work, now, is to determine what makes the NCS Adaptor and the Separators (and also some other parts as shown above) different from the majority of parts that plays well. These two are completely different parts, with different modules, with different roles - and yet, both misbehave the same once they are root on a craft loading from a SubAssembly. This is a hell of a puzzle…. Yep, you was bitten by the problem. Since you just arrived here, let me resume the mess for you: On KSP 1.9, something inside Editor started to shove back prefab values on parts positioning, disregarding whatever is on the craft file The problem only happens when you load the craft file on Editor. If you launch it directly on LaunchPad or RunWay, the crafts launches fine. The problem only affects parts that have Variants. Since TweakScale reposition the scaled parts (for obvious reasons), TweakScale was victim of the problem. Initially I had brute forced by way on TweakScale, but that was starting to cause me problems - I was never sure when something wrong was happening due a bug on TweakScale core business, or from something else that was being screwed up by the TweakScale's "gambiarra" When the SubAssembly, Load on Merge and Alt+Click problems started to happen, trying to handle them on TweakScale started to cause problems on TweakScale itself on my test beds - so I created AttachedOnEditor to fix the problem on the right place and remove TweakScale from the crossfire. By doing that, I also created a way to fix the problem for any other Add'On that would need it - instead of forcing people to use TweakScale to have the problem handled. What you are seeing on this thread is the disclosure of my findings while trying to nail this Kraken damned Editor misbehaviour. To tell you the true, this should affect somehow every add'on that by some reason changes the part's position - TweakScale ends up being one of the most used add'ons that do that, so it ends up having a bigger exposition to the problem. And, just to be clear, the problem only happens when you load the craft inside the Editor. When you launch the craft directly into the LaunchPad or Runway, the problem doesn't manifests. Now, about this problem specifically: It looks like this other one that I reproduced and fixed today: (See https://github.com/net-lisias-ksp/KSP-Recall/issues/34 for the gory details!) This one was my fault: I forgot to update the parts' position when saving the craft on AttachedOnEditor. So, as you edit the part, the AttachedOnEditor insists on restoring to the last known position - and since this last known position was never being updated after you created the part, AttachedOnEditor was moving the part to the wrong place. Well, I'm finalizing a minor release for KSP-Recall today, by the morning at least this problem should be fixed for you once you update KSP-Recall. So, just be sure, on the borking situations, the root part was the DS "Thunder" Kerbstein Rocket Nose, I'm right? From what Add'On is this part, it's KSP Interstellar Extended?

News from the Front V Well… I did, indeed, forgot to do something on AttachedOnEditor , but this early morning I realised I may had found a yet new weirdness on KSP's Editor! First, where I had err: I forgot to update the part's current position when saving the craft - so, as you edit the craft, dully changing the part position, once the craft is loaded the AttachedOnEditor would try to fix it using unduly, old values. (sigh). The following images will depict the problem and the fix: However, this doesn't explains why I was getting screwed up on SubAssemblies, Load for Merge or Alt+Click Duplicates! I found a light at the end of the tunnel (let's hope it doesn't "Pewee" on me!) when I tried the following test: From the same craft, 3 out of 4 Alt+Click duplicates worked fine. It was found that the Stack Separator, when used as root of the duplicate, is the trigger for the misbehaviour. Yet more weird, the Decoupler, another part with nearly the same characteristics as the Stack Separator, is working fine. The difference between the Decoupler and the Separator is that the Decoupler has Variants (and, so, was patched with AttachedOnEditor) . I tried another test using a non-variant as root, and it worked. As it appears, I may had found another KSP bug, or perhaps I had triggered a problem on a less than ideal workaround ("gambiarra") from Squad trying to "fix" something else. Since AttachedOnEditor is working fine on all the other parts (I currently trying to figure out what parts, besides the Stack Separators, are triggering the problem in order to find a pattern), it's definitively not a bug on it. Had I made a major mistake on it, it would be screwing up everything, not only this weird, marginal use case - I'm not even patching the Stack Separators with it. By night I will do some regressions tests with previous TweakScale releases to rule out any TweakScale interference on the process, and then I will issue a new KSP-Recall release with the (minor) fix I have at hands now. It will not fix the Stack Separator weirdness, but it still fix something. At least we have a viable workaround until I understand what's happening and do a proper fix.

Hi @Billy. Can you send me the SubAssembly misbehaving? I'm trying to zero-in on the parts that triggers the problem when used as root part on a SubAssembly (until now, the Stock Separators are some of them), so I can try to find a pattern and understand what's happening. To do so, please do as follows: Clear the Editor, clicking on the "New" button Open the SubAssembly Menu Click the SubAssembly that is borking on you. This will initialise a Craft with it on Editor, and the craft will be ok. The problem is happening only when creating a Duplicate or doing SubAssembly or Merge Save the craft as "SubAssembly with Problems" or something, then send it to me using dropbox, google drive or something. Or KerbalX... This will help me on the diagnosing process. Thanks!

Nope. It's happening at loading from file. Saving is ok. The reason is KSP (since 1.9) screwing up data from the loaded crafts on Editor using prefab data, bluntly overwriting whatever is on the craft file - for some reason that I can only speculate about : I think they tried to brute-force a workaround for a problem they didn't managed to diagnose, disregarding the consequences on everybody else. But… It's a guess. What I know for sure is that the fix for a problem happening on OnLoad implemented on KSP-Recall, besides fixing the problem at hands, created another one while using SubAssemblies, Loading for Merge and (I just reproduced it!) using Alt-Copy when some of the affected parts uses ModulePartVariant - exactly the parts being affected by the problem on OnLoad that KSP-Recall "fixed". I'm working on the thing right now. Until this moment, this is the current status quo: The problem on the Alt+Copy is fixed, and will be released on TweakScale 2.4.6.10 Gave up trying to do the right thing, I will brute-force my way on the problem and then I will try to cope with the collateral effects later Exactly as it was done on KSP 1.9, by the way The current fix implemented on KSP-Recall was short-cut, and now the work around is applied by TweakScale. The problem on SubAssembly were minimised, but not 100% fixed There's still a borderline situation (scaled variant surfaced attached to another scaled variant attached to a part) that was fixed by Recall, but on TweakScale I still struggling to fix. But it's enough for a new release, it's way less worse than what we have now. I don't like fixing widespread problems on TweakScale, but I don't have enough time to keep doing the needed research to understand exactly how and where KSP 1.9 is screwing up things - I only managed to pinpoint when. [belay all of that! I found a mishap of mine, I forgot to update the saved positions as the craft is edited. At least one misbehaviour was fixed by that, so I may had jumped into conclusions on all what I said above!] — — — POST EDIT — — — Managed to understand this one just now. You probably had something like this one: I thought this was my fault due a mishap on the AttachedOnEditor Recall workaround - but then I found this - note that only one duplicate is misbehaving, the other ones are not. On a more thorough test, I detected that the problem is only happening when the root part of the duplicate is a Separator. I double check using another part without variant as root, and the thingy worked fine: Again, only when the root part is a Stack Separator I managed to reproduce this misbehaviour. Other parts may misbehave the same, but until this moment, only a Separator triggered the problem. Even a Decoupler (that is pretty similar to the Separator, including using the same Module) behave fine… I think I revealed another problem on KSP with my code being the trigger - otherwise, my thingy would be misbehaving with any part as root, not only a few ones (I patched everything having ModulePartVariant, and some of these patched parts are working fine when root!). Anyone has more examples of misbehaving duplicates, SubAssemblies and Merge? Until this moment, once the problem is triggered, it is triggered consistently on these 3 situations. Moar info on this github issue.

Essentially… Yes!! Let's hope nobody inverts any gyro or sensor or anything like that, having a monster like this one exploding near the ground will not be pretty!!! hummm… belay that. I want to see this happening again - what could be more kerbal than exploding rockets? (but the crater is on the right place!!!)

Humm... I wasn't aware of that one... Well... let's dig on the problem. On KSP 1.9, something on Editor started to screw up crafts using mods that change the position of a part. It's not TweakScale (neither anyone else's) fault, it was a change on Editor. Apparently Editor is brute forcing the parts back to prefab's by some reason AFTER the craft is loaded, screwing up everybody. When TweakScale scales a part, it needs to reposition everything attached to that part. And so, TS is the most visible victim of this problem. Since cargo bays are intended to have things attached inside, they are the mostest visible between the most visible victims of the problem. I don't remember making testing with cargo bays, I will fire up a KSP 1.8 and then a KSP 1.9 (when the problem started to happen) to see what I get - as time allows. Time is currently my worst problem- all these tests and checks takes time, and this is limiting my response time to KSP problems and bugs as they are discovered... — — POST EDIT — — Found some time for a quick test. It's sure that only parts with Variants are being misplaced on SubAssemblies and Merge, Cargo Bays are not being affected, neither his cargo if the part does not have variants, or the part is attached to a attachment point! For more information: https://github.com/net-lisias-ksp/KSP-Recall/issues/34

Hi! TweakScale maintainer here. It's not a TweakScale problem. It's something on KSP-Recall. When I fixed a problem loading crafts that started to happen on KSP 1.9, the code somehow started to screw up the SubAssemblies and the Merge. If you remove KSP-Recall, then these problems will start to happen on loading crafts instead- we are between a rock and a hard place here. The problem is affecting "only" parts that have variants- I have no report (neither managed to create a craft with the problem) where this happen with a part WITHOUT ModulePartVariant. I'm working on the problem, but until I fix this, the only workaround is to to not use TweakScale on parts with Variants on SubAssemblies (or crafts intended to be merged). Removing KSP-Recall will lead to further problems on TweakScale because you will lose the fixes Recall implements.

ReStock is replacing some Stock Modules by customised ones, and so I need to "teach" DOE how to cope with these customised modules! DOE was working fine until the introduction of these modules, as documented on the respective issue! It's not a big of an issue, but RL is bitting harsh in the last 4 months so I didn't had the time to tackle this one yet.

Well... still scratching my head on why the OnLoad handling is different when the craft is loaded from file and when it's loaded from a subassembly or using Merge. I'm trying to avoid brute forcing my way on the problem (ie reading prefab data and applying the values myself) because this will surely stomp the toes of 3rd parties that also changes positions but, hell, it's tempting...

Yep!!! Thats the deal: these messages are yet another "bug" (more like a misfeature) from the Assembly Loader/Resolver. We can probe the Loader/Resolver for an Assembly - this should not be a problem, we are essentially asking "Hey, Dude, there're someone called AtmosphereAutopilot.UI on the pool right now?" The Assembly Loader/Resolver returns Yes or No, and that's it. The problem only happens when you try to load the thing and it doesn't exists - probing it is safe (no matter the outcome). However, the Assembly Loader/Resolver don't tell a probe from a load - and so it prints this pesky message every time you probe for something, adding noise to the diagnosing. The funny thing about it is that you can easily tell when someone is "doing the right thing": first probing and then trying to load it only when it's present - you will find TWO consecutive ADDON BINDER "errors" on the KSP.log - one for the probing, and another for loading it. IMHO it should be an Info message (not even a Warning). Well, you was bitten by a nasty bug on that Assembly Loader/Resolver thingy. As said by Aussie, there's a bug on that damned thing that if by any reason someone tries to load a DLL that it's absent (or corrupt, or incompatible, or whatever), not only the code trying to load it will bork, but from this point on, everything trying to load something will bork as the dependency wasn't there! The magic is to inspect the KSP.log looking for the first occurrence of a borking dependency loading, everybody later is victim of the triggered bug from the Loader. On your case, we have a new occurence! This is the first time I got this kind of problem: [LOG 15:12:42.539] [AddonLoader]: Instantiating addon 'PQSModCreator' from assembly 'KopernicusExpansion.RegionalPQSMods' [EXC 15:12:43.763] ArgumentException: Duplicate type name within an assembly. System.Reflection.Emit.ModuleBuilder.DefineType (System.String name, System.Reflection.TypeAttributes attr, System.Type parent, System.Type[] interfaces, System.Reflection.Emit.PackingSize packingSize, System.Int32 typesize) (at <9577ac7a62ef43179789031239ba8798>:0) System.Reflection.Emit.ModuleBuilder.DefineType (System.String name, System.Reflection.TypeAttributes attr, System.Type parent, System.Type[] interfaces) (at <9577ac7a62ef43179789031239ba8798>:0) TriAxis.RunSharp.TypeGen..ctor (TriAxis.RunSharp.AssemblyGen owner, System.String name, System.Reflection.TypeAttributes attrs, System.TypebaseType, System.Type[] interfaces, TriAxis.RunSharp.ITypeMapper typeMapper) (at <fd18e0ef899946d5b101c3255bfcbde8>:0) TriAxis.RunSharp.AssemblyGen.Class (System.String name, System.Type baseType, System.Type[] interfaces) (at <fd18e0ef899946d5b101c3255bfcbde8>:0) TriAxis.RunSharp.AssemblyGen.Class (System.String name, System.Type baseType) (at <fd18e0ef899946d5b101c3255bfcbde8>:0) KopernicusExpansion.RegionalPQSMods.PQSModCreator.Awake () (at <f5e1172978524a599c9056aa1686da11>: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() Some how, the Kopernicus' PQSModCreator have two thingies with the same name, and so the dynamic linker (an internal thingy inside the Assembly stunt) gets confused because it doesn't know what the one is to be used, and then blow everything up. I don't have the slightest idea about how to fix this one (i didn't even knew this would be possible! ), you will need to reach Kopernicus guys and ask for help. Let me know if I can further help on this one - this is interesting!

News from the Front IV Well, I ended up wasting time and efforts (and some mood on useless altercations) on an unrelated KSP bug (that I wrongly suspected could be related somehow) and ended up forgetting that KSP is not the only source for bugs around here. When I fixed the KSP's Editor bug on attachments while loading crafts with tweakscaled parts (with variants), I didn't realised something very important: the life cycle of a part is slightly different on initialisation when loaded from a file than when loaded from a subassembly (or by a merge). I focused on fixing things for the Craft Loading, but didn't took any measure on checking if the thing would work the same on subassemblies. Well… Apparently I should have. When I fixed the problem for Loading Craft, I ended up screwing up the SubAssembly and the Merge. As we use to say around here, "O que é remédio para o pato pode matar o marreco envenenado". The reason I was unable to pinpoint the problem until now was bias. I spent too much time handling people blaming TweakScale for the problem, but I also was biased blaming KSP for a problem that Recall was already fixed, without being aware that the fix could be injecting collateral effects when called outside the Editor's Craft loading cycle. Not exactly a surprise, as I was rushing to fix a nasty problem on a very critical feature of KSP - and called it a day when I accomplished it. Still, it's a bit embarrassing to tell you the true. I have hard evidence about the module causing this problem - but removing the module would bring back the Craft Load problem, so I was caught between a rock and a hard place. But at least now I'm sure about the source of the misbehaviour, so all I need to do now is to understand the differences on the part's life cycle when loading a craft from when loading it from a subassembly (or for merge) so I can do whatever I need to do to prevent the SubAssembly and Merge from being screwed up by the Load fix. You can follow this on https://github.com/net-lisias-ksp/KSP-Recall/issues/34 .

I spent the whole day trying to figure out why you posted this as a "Kerbalism" - I was completely confused until I found this image from the thread that follows:

'Look Mummy! There's an airplane up in the sky!!

'Look. Mummy. There's an airplane up in the sky!!'

Pretty Kerbal! Prinoth Panther rotating tracked dumper Not a crane, but you may like it @Ben J. Kerman!

:hailprobe:

I usually don't like to scale jet and LFO engines, but sometimes scaling up a Juno is the best way to reproduce a historical aircraft due the engine's characteristics, i.e, ISP. Older engines have a lower ISP than modern engines, and TS allows me to try to reproduce such aircrafts including their drawbacks. What's exactly the opposite from what you said: I'm using a "worse" part in the place of a better one to keep the crafts properly handicapped, matching (more or less) the technology of the era I'm aiming. Another way TS can really save our sorry SASes sometimes is by scaling Wheels, Landing Gears and Landing Legs. No more need to use a three-rowed non steering landing gear on the nose on your really big crafts - scale up the biggest steering landing gear you have and voilá. And lifting and control surfaces - TweakScale really shines on these ones. It allows you to make pretty nice wings, second only to Procedural Wings (but sometimes, a TweakScale stock wing can be nicer) - and scaling landing gears also helps a lot on these. Welcome! TweakScale would be a useless blob of code without users! Cheers!

It's not TweakScale - TS (and probably some others add'ons) are borking due a nasty bug on a thingy called Assembly Loader/Resolver on KSP - when someone borks while trying to load a dependency, EVERYBODY ELSE also borks too while loading their dependencies no matter if the dependency is good to go or not. In your case, you need to install USITools. This will fix KolonyTools, and then everybody later should be fine too as the KSP's bug is not triggered anymore! [ERR 15:20:49.838] ADDON BINDER: Cannot resolve assembly: USITools, Culture=neutral, PublicKeyToken=null [ERR 15:20:49.843] AssemblyLoader: Exception loading 'KolonyTools': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflec at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <55ba45dc3a43403382024deac8dcd0be>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its d File name: 'USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' Cheers!