Lisias

A bit ashamed from what I did early morning (nah… not really!), I revisited the Velociteze concept. What if the Komet had not tragically failed as she did, and the Velociteze would be built by the British Aviation Industry of the 60s?

By googling for the DLLs that are missing. 0_00_AT_Utils_UI is from AT_Utils for sure. However, I gone one step ahead and… The damn 0_00_AT_Utils_U.dll is present on your installment, and was loaded. [LOG 00:55:35.494] Load(Assembly): 000_AT_Utils/Plugins/0_00_AT_Utils_UI [LOG 00:55:35.494] AssemblyLoader: Loading assembly at GamePath\Steam\steamapps\common\Kerbal Space Program\GameData\000_AT_Utils\Plugins\0_00_AT_Utils_UI.dll Well, since I borked on that one, I did yet another analysis on the thing. Every single DLL on that binder error was loaded fine - EXCEPT by one: [ERR 00:55:52.674] ADDON BINDER: Cannot resolve assembly: KSP-AVC.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 00:55:52.674] ADDON BINDER: Cannot resolve assembly: KSP-AVC.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 00:55:52.675] ADDON BINDER: Cannot resolve assembly: KSP-AVC.XmlSerializers [LOG 00:55:52.767] KSP-AVC -> System.IO.DirectoryNotFoundException: Could not find a part of the path "GamePath\Steam\steamapps\common\Kerbal Space Program\GameData\KSP-AVC\Plugins\Textures\OverlayBackground.png". at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 buffer Size, System.Boolean anonymous, System.IO.FileOptions options) [0x00164] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.IO.File.OpenRead (System.String path) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at KSP_AVC.Utils.GetTexture (System.String file, System.Int32 width, System.Int32 height) [0x00016] in <d05e532f012b47999887e5d33b07d5c6>:0 Delete KSP-AVC and try again. If things works this time, send the log to LGG pinpoint this post too. [Assuming, of course, that you didn't did what blowfish think you did - forgot a old version of KSP-AVC on the installment after Steam had updated it!]

Feel your pain, bro... I Feel your pain. I will see what I can do, as I manage to get things on rails on RL (assuming nobody did it by the time).

The very thing I didn't tried because it would not change the URL of the artifact, and I had already jumped into the CDN conclusion and closed my mind to alternatives. well, good to know. Thanks!

Velociteze MAX. Because, sometimes, I just can't help myself.

Hell of a report. On the bright (besides bitter) side, now we know what it is not. Out of curiosity, to kill a bit of time as it's near bedtime (and firing KSP would not be the wise move at the moment!!), I gave a peek on the code. if (File.Exists<MechJebCore>("mechjeb_settings_global.cfg")) { try { global = ConfigNode.Load(IOUtils.GetFilePathFor(this.GetType(), "mechjeb_settings_global.cfg")); } catch (Exception e) { Debug.LogError("MechJebCore.OnLoad caught an exception trying to load mechjeb_settings_global.cfg: " + e); generateDefaultWindows = true; } } else { generateDefaultWindows = true; } Dude… It's a blind guess, but look for a file called "mechjeb_settings_global.cfg". If it exists, check the access permissions. Also, that File.Exists<FooBar>("filename") stunt is similar to something I'm using on the Experimental version of KSPe (with mine being a complete System.IO.File implementation!). I didn't pushed this into Mainstream (TweakScale, etc) because Mono apparently has a flaw where a DLL failing to be loaded would leave some runtime data structures inconsistent, and then all the Reflection calls would bork exactly this way!! Since you are using KSP 1.8.1, and so .NET Framework 4.x, I have to reconsider my position - it was never a Mono problem, it's something on KSP itself! DAMN!! [Nope - see below] In a way or another, it appears to be the same problem. You can't have failed DLL loadings on the installment. Knowing this, I redid my analysis on your log and found: [ERR 00:55:38.755] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.755] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.804] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.0, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.804] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.0, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.839] ADDON BINDER: Cannot resolve assembly: SEPScience.Unity, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.839] ADDON BINDER: Cannot resolve assembly: SEPScience.Unity, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.843] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null [ERR 00:55:38.843] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null [ERR 00:55:52.674] ADDON BINDER: Cannot resolve assembly: KSP-AVC.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 00:55:52.674] ADDON BINDER: Cannot resolve assembly: KSP-AVC.XmlSerializers, Culture=neutral, PublicKeyToken=null [ERR 00:55:52.675] ADDON BINDER: Cannot resolve assembly: KSP-AVC.XmlSerializers [ERR 00:58:09.901] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [ERR 00:58:09.901] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null The interesting thing: querying about an Assembly triggers the same message on the KSP.log . You need to try to load the DLL and fail (that triggers the same message!) in order to get this problem pesking you: the first DLL borking on the load, and every single call to the reflection API as the KSP.IO.File does will throw that Kraken Damned Exception! (and believe me, I'm fighting this crap for almost an year already!!). So, in order to fix things, you need to go the inverse way! You need to satisfy every add-on binder error above. That happening, that internal structures needed by the Reflection will be sane, and then KSP.IO.File.Exists<Type> will work! — — POST EDIT — — Nope. I could not made that affirmation. It can be something on Unity too.

I felt a disturbance on the Force… Well, you got a Houston. This scaring message is displayed to invite you to seek help, as your installment is prone to some of the problems described on this post. Nasty stuff, I'm sorry for that. But, hey, now that we know about it, we can fix it for you! [LOG 19:24:55.824] [TweakScale] INFO: WriteDryCost Concluded : 1699 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 78 Show Stoppers found; 16 Sanity Check failed; 918 unscalable parts. And.. yep. 78 "Show Stoppers". Every single one of them is about the Issue #34. (That 16 "Sanity Checks" are safe, by the way - these ones TweakScale knows how to workaround to prevent breakage, it tell you about to inform us it did something about.) Well, let's crack that nut: The good news about these ones is that usually they are related and shares a common cause. Let's check one random part to see what we get: [LOG 18:53:50.256] Applying update Contares/Patches/Contares_CORE_TweakScale/@PART[CRU-LG-A1] to Contares/Parts/Antennas/CRU-LG-A1/CRU-LG-A1.cfg/PART[CRU-LG-A1] [LOG 18:53:53.323] Applying update Contares/Patches/CONTARES_TweakScale/@PART[CRU-LG-A1] to Contares/Parts/Antennas/CRU-LG-A1/CRU-LG-A1.cfg/PART[CRU-LG-A1] Interesting. We have two patches applying updates on CRU-LG-A1. Both from Contares, what's even weirder. This trend appears to repeat on the other parts: [LOG 18:53:52.729] Applying update Contares/Patches/CONTARES_TweakScale/@PART[TLV_FIN_C] to Contares_RUS/Parts/UNION-2/TLV_FIN_C.cfg/PART[TLV_FIN_C] [LOG 18:53:57.039] Applying update Contares_RUS/Patches/Contares_RUS_TweakScale/@PART[TLV_FIN_C] to Contares_RUS/Parts/UNION-2/TLV_FIN_C.cfg/PART[TLV_FIN_C] Looking into the patches CSA_Contares_RUS and the others on github, the reason is clear. They are not checking if the patch was already applied, and then they just patch it again. // Triebwerke @PART[LFO-VIPERA]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } When you apply a patch like that twice on a part, you end up with multiple data and then TweakScale gets confused. When you apply exactly the same data twice, things works fine, but if the data is not the same (lets say type = stack on one, and type = free on other), TweakScale will misbehave - ending in disaster. The best way of action is to be absolutely sure you apply a patch on a part only once. If you are absolutely sure you want to overwrite whatever you have there, you need to patch things like this: // Triebwerke @PART[LFO-VIPERA]:NEEDS[TweakScale] { -MODULE[TweakScale],* { } %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } Please ask Contares' maintainers to review their patches to do what I said above. This will not only prevent the message, but will also making their patches more reliable and less prone to errors - I just saw a patch blindly shoving a "type = free" on a part without checking if there's a "defaultScale" there first - and this can trigger yet another FATALity on you later. In time, I usually respond faster when you ask for help on TweakScale's thread.

Yep, this had bitten my SAS too. I think it's the CDN they are using. I don't think this have a easy solution unless that CDN has an API for clearing cache - every time you upload a file, a script would clear the CDN cache for that URL.

Because TweakScale works the other way around. It does nothing, except if someone tells it to do something. You need to explicitly code a patch adding TweakScale into a part in order to get it working. The only thing TweakScale does by itself is, once someone shoves a TweakScale module on a part, to check for problems and if a nasty one is detected, undo the patch programatically. And even that, I did it with a bad taste on the mouth. So, in a nutshell, TweakScale is a very well behaving citizen on KSP Land. It only does what it is explicitly told to do, otherwise, it stays shut and quiet on its place.

That's the thing: KSP.log logs KSP events, Player.log logs UnityEvents. Sometimes, an KSP event is echoed into Player.log, but not always, Usually, we ask for KSP.log when we are sure it's bork on some Add'On, we ask for Player.log when we are sure it's a problem on Unity (or in the C++ land). When things are really hairy, we need both to make cross checks. On this time, I think we got "lucky". I think I managed to get something. I need to ask you to be very prudent on handling the Add"Ons mentioned, because absolutely most of the time, we are handling a Kraken Food (Unholy Interactions between modules are what Krakens feed of…). They work fine by themselves, but under a certain combinations of circumstances, a chain reaction is triggered and then KABOOM. [LOG 00:58:11.014] PartLoader: Compiling Part 'B9_Aerospace/Parts/Body_Mk2/body_mk2_section_0m_sas/B9_Body_Mk2_SAS_050m' [LOG 00:58:11.037] [MechJeb2] Starting the Dispatcher [LOG 00:58:11.134] ManeuverPlanner initialization: found 17 maneuvers [ERR 00:58:11.148] MechJeb caught exception in core OnLoad: System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at KSP.IO.File.Exists[T] (System.String filename, Vessel flight) [0x00053] in <9d71e4043e394d78a6cf9193ad011698>:0 at MuMech.MechJebCore.OnLoad (ConfigNode sfsNode) [0x00097] in <2e230d4e49354a07858a9faa52799159>:0 [LOG 00:58:11.183] PartLoader: Compiling Part 'B9_Aerospace/Parts/Body_Mk2/body_mk2_section_1m/B9_Body_Mk2_Fuselage_1m' I detected some borks on MechJeb2 on OnLoad while being instantiated by B9 Aerospace parts. This doesn't means that B9 is the culprit, it may be a rogue patch messing up with these two. In a way or another, the next step into diagnosing the problem is to deinstall B9 Aerospace. This should have us a negative confirmation (absence of the problem). Confirming it, the next step is to get a disposable KSP installment and install only B9 , MechJeb2 and the minimum dependencies to see what we get. If everything works fine, we have a confirmation that we have a third party stomping on their toes. If the minimal installment borks the same, you have something to show MechJeb2's and B9 Airspace's maintainers - I'm pretty sure they will be able to pinpoint the problem and find a solution from there.

Reading on a computer is so better… Well, that's the thing: when an exception happens on a Event Handler (as onAwake or onStart), all the chain is aborted as the running thread dies. It's the reason Firespitter 7.13 was borking KSP, it was trying to load something that didn't existed anymore and, without a try-catch on the handler, was raising the exception to the caller, that then was got with its pants down, and raised the exception to its caller - in a chain reaction that culminates with the thread killing itself. So, it can be anything. Something changes something somewhere in the past, and then MechJeb2 borks, killing the thread. One way to try to pinpoint the trouble maker is checking the KSP.log.. KSP.log logs some KSP events that are not logged on Unity's one. As an example, if the crash is happening exactly on the MainMenu Scene, we can trim down the search to Add'ons that instantiates themselves on that Scene.

But do what you do, keep your coffee away from these critters!

I think this is a good time to a new Article about how I plan to keep TweakScale working for everybody. But, this time, by not doing something! About Third Party Add'Ons Support. Well... TweakScale (the Module) is pretty cooperative, but it's also dumb as a door by itself. It needs help in order to be able to do its job. This help is provided by patches. However, as recent events had proven, bad patches can be a terrible thing. They should be maintained and curated with care. And this is where things can go trough the tubes as times goes by... It's plain impossible for a single dude to keep track and update patches for every single Add'On out there. Even by accepting pull requests with the feature, these patches will need to be maintained on every release of the Add'On it supports! This thing can escalate fast, as every single time every Add'On supported by TweakScale is updated, I need to check the patches myself and then issue a new TweakScale release if anything changes. And this is terribly bad due a lot of reasons, between them: It's too much work. There're no time available for a single person to do it by itself - there're tons and tons of Add'Ons on the wild! Every Add'On update can trigger a TweakScale new issue, that then should be downloaded by every TweakScale user - be he/she using that Add'On or not! Some Add'Ons get deprecated or just vanish from the face of Kerbin, and yet TweakScale have their patches lingering - waiting to play havoc as things changes and that patches became obsolete. TweakScale became responsible for potential induced problems on Third Parties when any of the default patches misbehave, damaging TweakScale's reputation. With a third-party Add'On doing this job, any glitch would be rapidly pinpointed by installing/uninstalling that Complement, saving me the hassle of handling the fallout from TweakScale. So TweakScale, in order to keep doing its good work safely and reliably, needs to go fitness: it needs to lose some fat. This fitness process already begun. KAX patches were internalized into KAX, and are not being distributed anymore as default. These patches were moved to the Extras/Deprecated folder on the distribution file as is, they are not maintained anymore - bugs and improvements on them will be handled on the KAX's project (where some bug fixing was already carried out, by the way). I will provide all the necessary support on the process. Since not all Add'On Authors will be willing to handle TweakScale patches themselves, some will linger on TweakScale 2.4.x series . But any Author willing to internalize them are welcome to do so - just, please, send me a note so I can move them out to the Deprecated and avoid stomping in your toes. New support will be implemented ideally on Companion Packs (essentially, a patch-only Add'On as All Tweak!!) where support for one or more Add'Ons would be implemented, curated and maintained separately. This is one of the main goals of TweakScale 2.5.x series, where any patch not reclaimed by the Add'On's Author will be moved to a Compatibility Pack (obviously, owned by me) to keep things working. TweakScale, from that point, will support directly only Stock and DLC parts. Link to the original article on my site.

Dude, you need to try coffee, milk and honey. Man, that's something.

And the airstrip too. (boy, trying to remember how I managed salvage the airstrip and land the cockpit on it….)

Well… It must not EXPLODE. See my entry - I managed to salvage intact the cockpit, the rest of the craft splashed on water virtually intact. It's not on the rules - but I'm trying to keep the cockpit inside the track just for the challenge.

I think it lacks the "not explode" item of the contest: But with that time, you can afford losing half a second to "fix" the issue and still get the first. DAMN. I have some serious work to do.

Aussies.

A possible way to make easier to judge could be, perhaps, some kind of automation using kOS or KRPC? The aircraft must run under the script, and only the ones passing on it will be eye balled after. The contestant download the same script, and publish the entry when the thing passes the script checks (including taking off, flying around by the minimum distance for the category, and then landing back on KSC). The judge later just download the craft and redo the script. If we have a confirmation, then the judge would do a proper review.

Happy Halloween!

(nope - I was wrong on thinking I was wrong) You need to copy 999_Scale_Redist.dll into GameData, as explained on the INSTALL and detailed on KNOWN_ISSUES . I'm sorry for that, but this was the only solution I could find to overcome the AddOn Binder Error Fest, that was being triggered on every third party module using Scale_Redist. Had I didn't did that, TweakScale partners would be drowned on support requests due their modules triggering that thing. It's exactly the same problem, sir. Extract the 999_Scale_Redist.dll into your GameData and the problem will be solved. — post edit — I confirmed my diagnosis above. My test bed was flawed and gave me false positives. Once I fixed the test bed, things worked as I said.

I workarounded this Addon Binder Error Fest as explained here. Not sure if FAR is suffering from this thing too, so I choose to link the post instead of risking derailing (further) this thread.

AddOn Binder Error Fest on KSP 1.8 It was found that on KSP 1.8 you can't have the same DLL installed on different directories without triggering a AddOn Binder Error Fest. Since, until the moment, AddOns willing to cooperate directly with TweakScale usually had their own copy of Scale_Redist.dll (the interface where such cooperation is realized), TweakScale's partners became a trigger for this Error Fest on KSP.log. It's not clear, at this time, if this Error Fest is prejudicial or just an annoyance, but in a way or another, by eliminating every redundant Scale_Redist.dll from the system had solved the issue. However, this created a new one: it's necessary to guarantee that Scale_Redist.dll be available to any potential client in need of it, otherwise (and obviously) such a client will bork on a new AddOn Binder Error (and this one is fatal). The way TweakScale managed to solve that second issue is to move Scale_Redist.dll to GameData, as 999_Scale_Redist.dll. I'm sorry for that, but this was the only solution I could find to overcome the AddOn Binder Error Fest, that was being triggered on every third party module using Scale_Redist. Had I didn't did that, TweakScale partners would be drowned on support requests due their modules triggering that thing.

Sometimes it is, but sometimes it's not. And the KSP.log provides a detailed error message for the problem, as in this case: [WRN 10:11:15.404] more than one pass specifier detected, ignoring all but the first: KAX/Patches/KAX_FAR/@PART[KAXVintage*]:AFTER[FerramAerospaceRe Well, I learnt something new today. You can't mix :FOR and :AFTER or :BEFORE on the same node no matter the symbol they refers (:AFTER something and then :FOR something else). It will be fixed on the next release, currently unscheduled however. Tanks for the heads up!

I will. I rushed things a bit today because we have a hard to crack sprint coming soon, and my time for this (TweakScale, not work!! ) will be somewhat impaired. I want to keep the housekeeping in check before that sprint and in time for some resting (and KSP playing, something I'm not really doing for some weeks now).