Lisias

But the crater is on the right place!!

Hit the VAB while parachuting. Kraken know how many Kerbals I accidentally killed trying to land them on the VAB's roof….

I think I nailed it! But there's a caveat: the fix only works on newly created SubAssemblies, as SubAssemblies created with previous versions of KSP-Recall (if any) don't have the data needed to reconstruct correctly the thing. I'm trying to figure out a way to salvage these SubAssemblies in the mean time. The PRE-RELEASE is available for early adopters willing to help me to test the fix on KSP-Recall's thread.

ANNOUNCE KSP Recall 0.2.2.0 Pre-Release is on the Wild, featuring: Implements a missing use case, handled on #34 Works the issues: #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor I finally nailed the problem! This is what happening (or, at least, it's the best explanation I have for the bug until this moment): On KSP 1.9.x, the positions of the Attachment Nodes of the part stopped from being read from the craft file by the vanilla part support (i.e., without the ModulePartVariant), and started to be correctly initialised only when ModulePartVariant is present on the part. If the initialisation is made by ModulePartVariant or by something else could not be determined until this moment. So the solution was, in essence, the same applied by the Radial Positioning (that perhaps should be suffering from the same problem?): just save the positions on a custom module on the craft file and reapply them when needed. What was done. However… The current workaround properly fixes the issue, but only on newly created SubAssemblies. I'm currently bashing my SAS out trying to figure a way to salvage SubAssemblies made with previous versions of KSP-Recall (or without it). I didn't found a way to salvage these SubAssemblies yet - I don't even know if this would be possible at this moment (but didn't tried too hard, to tell you true). See the KNOWN ISSUES file for details, or the following links: Got a bug with a subassembly here on Forum Issue #34 on GitHub — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Will NOT be published. SpaceDock (and CKAN users). Will NOT be published. This is a beta release intended to be used by early adopters willing to help me with the issue.

I usually get this when I abuse my GPU's VRAM (what's pretty easy, it's a punny Intel HD4000). Uninstall the add'ons with heavy textures (as ReStock) and see what you get. If confirmed, a way to mitigate the problem is to reduce the Quality of the Textures to One Quarter or even One Eighth on Settings/Graphics on the Main Menu. The gory reason for the problem is that once you overflow your GPU's native VRAM, the driver starts to borrow RAM from the CPU, but doing this will slow down everything because the PCIex bus is way slower than a direct memory access - not to mention that the CPU will be competing for that memory too and you will have Contention as both chips will want to access the memory all the time and someone will have to yield.

Launch, Orbit, Crash!!

A whole screen full of it!!!

You have a heat problem on your rig. Install some monitoring tools, as https://openhardwaremonitor.org/downloads/ and see how your computer is behaving - it's usually a bad thing having anything hotter than 90ºC (194ºF). I think you need to clean up your computer air intakes and fans - you should be doing it once a year anyway (my last disk crash on my MacMini was due exactly this - I plain forgot of cleaning it, and the thermals cooked up the hard disk)

New WORK AROUND found! And, so, probably a fix on KSP-Recall as soon as I'm confident that this is really the problem (and I will not create a worst one by applying it). Until this moment, all evidences suggest that the problem is triggered when the root part of a subassembly does not have variants, but the part attached to it does. In any other combination, the misbehaviour is not triggered. So, the following SubAssemblies are OK: root part starting with a Part with Variant root part starting with a Part without Variant and followed by another Part without variant. And the following SubAssembly is problematic: root part starting with a Part without Variant and followed by a Part with Variant. Don't ask me how Squad managed to create this one - I would be amused by it if this wasn't getting me so much of a headache... For the gory details: https://github.com/net-lisias-ksp/KSP-Recall/issues/34

News from the Front VI Ha! I think I nailed it!!! (famous last words… ) I (think) I finally nailed the Modus Operandi of the problem! It manifests when the root part of a subtree/subassmbly doesn't have variants, but the parts attached to it does. If the root part has variants, the problem doesn't happens no matter what. If the root part doesn't have variants, but the parts attached to it neither, so the problem doesn't manifest itself neither. Things get screwed up only when the root part of the subassembly does not have variants, but the parts attached to it does. Pretty odd, if you ask me... By analysing the source code from TweakScale being victim of this problem, I think that what's happening is that the attachment points are not being correctly initialised, and so when TweakScale tries to attachedPart.transform.Translate() them, things goes down trough the tubes. Apparently the solution will be to save also the part's attachment points on the AttachedOnEditor stunt, and apply it on all parts (not only parts with Variants, as it's being done now). For further information: https://github.com/net-lisias-ksp/KSP-Recall/issues/34

Joke?

I think you installed the wrong DLL, the new version only works on KSPe 2.4 and newer due some changes on the API. I redowloaded the ZIP from the github release pages, and it's really the latest one I uploaded this morning - and it works on KSPe 2.4.x.y... (next time, please publish the whole KSP.log so I can be sure) Anyway, if you manage to get it working, don't change anything and keep going. Other than small, non functional changes, nothing really changed.

The only work around I have by now is to avoid using some parts as root of a SubAssembly. Using TweakScale on the root part is irrelevant for the problem, it's the part itself the trigger for the problem. What implies editing your SubAssemblies somehow. While bashing my head on the wall about the problem, I came to this easy way to "edit" a SubAssembly: Click on the "New" button Click on the SubAssembly you need to fix This will load it as it was a craft, without the problem Alt+Click on the part imediatelly after the problem triggering part that while rectangle one on your shot Save the "transparent" duplicate as a new SubAssembly. From this point, you need to place that part manually on the target craft before applying the SubAssembly. Inconvenient, I know, but at least this keep you going while I'm trying to zero in the problem. Things as slightly worse when Loading a Craft for Merge. You will need to reposition the parts manually every time - unless you break the craft file in two on the borking part, similar as done by the SubAssembly. Way more inconvenient, as we usually maintain craft files in a launchable state. On the bright side, I think I determined what induces a part to bork : not having ModulePartVariants. It still doesn't explains why the NCS Adapter doesn't borks on Alt+Click but does on SubAssemblies, but apparently I found a pattern for the trigger part. A pretty obvious one - I don't know why it took so much time for me to think on it. Perhaps injecting a dummy ModulePartVariant config section would solve the problem? I will try this later (away from my personal computer right now).

Interstate '76. One of the best Soundtracks I ever heard on a game!

Sounds like this guy also have a problem on the SubAsseblies...

It will depends on the caliber of the machine gun and the amount of ammo you have!

Hi. I just fired up a test bed using the latest KSPe, MM/L and UbioWeldingContinuum after updating it to the latest version of KSPe, and apparently it's working fine. The latest KSPe has some fixes, better memory footprint and slightly better performance, so perhaps this would be the issue for you guys? Anyway, I did a quick update on the thing: Theoretically it still aims KSP 1.4.x, use it on newer KSP at your own risk - i.e., I didn't added any support for Parts with Variants, your mileage will vary. Handling configuration files are slightly more convenient now. Doesn't affects current installments, don't worry. I didn't bored to check if this stunt would work with canonical ModuleManager I remember doing some changes on the MM support once, but don't recollect what I did. You will need the latest KSPe version - this DLL will not work with older releases. It's still a interim, non-official fork intended to fill a gap while someone else doesn't takes it properly. Links: https://github.com/net-lisias-ksp/UbioWeldContinuum/releases https://github.com/net-lisias-ksp/KSPAPIExtensions/releases https://github.com/net-lisias-ksp/ModuleManager/release If even with this last release you have problems, please publish your KSP.log on dropbox, google drive or something and send it to me for inspection. Ping @Fwiffo - sorry being so late!

Well… If KSP would be working fine, I would had no need for such tests! (To tell you the true, it would be no need for KSP-Recall at all! )

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!