Lisias

Well… Since we are talking Python here… Long background history follows - it's interesting to read it do contemplate the huge problem I created, but the thingy became too long. So now I had to built a customised way to access that Storage the fastest I could as we are on the critical path of mission critical and highly tight on the timings process, so I cooked up a Connection Pool for the Storage Service to avoid connecting and authenticating on every access. I made (almost) everything right - kept the connections alive regularly and replaced it with new ones if they dies - so the Client would have instant access when needed. Except that I forgot to handle one exception inside a mutual exclusion lock and when that one exception that I didn't had foresee finally happened and leaked it into that critical section, the whole thing halted silently in a dead lock. And that crap, obviously, happened early early morning, when the authorisations for the leaving cargo at morning should start to get being fetched. At first light I received a call with a desperate dude yelling that he had LOTS OF TRUCKS FULLY LOADED waiting for permissions that were not arriving. By the time I diagnosed and fixed the problem, they had FOURTY TRUCKS waiting for me on the parking lot. It took 4 more hours to retrieve and process all the permissions from the partner's systems (while they were calling us swearing because I was DoS'ng their services). At Noon, the last truck that should had departed at 6:00AM finally left the parking lot and we stopped screwing up the partner's services (they shoved us on a dedicated machine after that). Good thing I was already working remotely. Had I being working on premises, the truck drivers would had hunted me and squashed me inside the server - most of them drove late night because of this stunt! Simplifying things a lot, this is more or less what I did: with self.THE_LOCK: # where lock is a threadling.Lock object all_connections = self.connections.keys() do_some_stuff() while all_connections: c = all_connections.pop() c.acquire_internal_lock() if not c.is_alive(): self.connections.pop(c) c.close() c.release_internal_lock() And this is more or less what I should had done: with self.THE_LOCK: # where lock is a threadling.Lock object all_connections = self.connections.keys() do_some_stuff() while all_connections: c = all_connections.pop() c.acquire_internal_lock() if not c.is_alive(): self.connections.pop(c) # thread safe operation try: c.close() except: # It's dead, Jim! pass c.release_internal_lock() Explain: we are talking multithread here - so the c.close() is a cross-thread trigger, where the close would call some house keeping business on that thread loop and exit - but the house keeping code would wait for the internal lock to be released first. The internal lock was a MUTEX created using the client's credentials+service_address as name - important, because that Storage was not reentrant and I had to prevent two threads trying to access the same store at the same time if by some reason the client asks for more stuff before I finish the last call. If c.close() blows an Exception on the first version of the code, the whole running thread exits in error and the internal lock of that connection is never released! So any attempt to recreate the connection to that Storage using that credentials would lock forever. On the second version of the code, if c.close()screws up, the thread keeps going, release the insternal lock and finishes normally. (removing the while loop from the THE_LOCK Lock is an optimisation - I don't need to halt the whole shebang, I only needed to lock the do_some_stuff) — — POST POST EDIT — — Interesting enough, I just realised I still have a flaw on that code! The REAL good code is: with self.THE_LOCK: # where lock is a threadling.Lock object all_connections = self.connections.keys() do_some_stuff() while all_connections: c = all_connections.pop() c.acquire_internal_lock() try: if not c.is_alive(): self.connections.pop(c) # thread safe operation c.close() except: # It's dead, Jim! pass finally c.release_internal_lock() The previous code was somewhat optimistic - if c.is_alive() would raise an exception, I would have the original problem again. Ok, I know it will not because I wrote that thing to consider an exception as evidence of death - but someone maintaining it later will not know that (not to mention that additional code would be needed later and then the assumption would break). This final form of the code is the one I had should had written. Well, I'm fixing that code now. (It's interesting how the human mind works: "you need to get out of the island in order to see the island…")

Sure thing! From the log: [LOG 13:01:37.402] [TweakScale] Version 2.4.6.8 /L [LOG 13:01:37.918] [TweakScale] ERROR: System.TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. ---> 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 KSPe.IO.Hierarchy`1+<>c[T].<calculateTypeRoot>b__10_0 (System.Reflection.Assembly assembly) [0x00000] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at System.Linq.Enumerable+<SelectManyIterator>d__167`3[TSource,TCollection,TResult].MoveNext () [0x0004e] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable+WhereSelectEnumerableIterator`2[TSource,TResult].MoveNext () [0x00059] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable.TryGetFirst[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Boolean& found) [0x00045] in <351e49e2a5bf4fd6beabb458ce2255f3> :0 at System.Linq.Enumerable.FirstOrDefault[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x00000] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at KSPe.IO.Hierarchy`1[T].calculateTypeRoot () [0x000a5] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T].CalculateTypeRoot () [0x00022] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T]..ctor (KSPe.IO.Hierarchy hierarchy) [0x00007] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T]..cctor () [0x0000a] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 --- End of inner exception stack trace --- at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_generic_class_init(intptr) at KSPe.Util.SystemTools+Assembly+Loader`1[T].TryPath (System.String path, System.String[] subdirs) [0x00000] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.Util.SystemTools+Assembly+Loader`1[T]..ctor (System.String[] subdirs) [0x0002e] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at TweakScale.Startup.Start () [0x00018] in <c8a4ba9de07c4f43928c3b6b1d79e4c1>:0 at error:0 [LOG 13:01:37.923] [TweakScale] "Houston, we have a Problem!" about Missing DLLs was displayed Oh well, it's that old KSP bug on the Assembly Resolver/Loader again. This crap is bitting our SASes since 1.8 (sigh). TL;DR: this weird bug happens when someone fails to load a DLL - the side effect is that after that, everybody fails to load their DLLs too. Usually, the first occurrence of a System.Reflection.ReflectionTypeLoadException is the trigger for the problem: [ERR 13:01:28.810] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.Reflectio nTypeLoadException' 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 <a1ca58b5ca7140639de29a81de5e3f32>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' Apparently, the B9_Aerospace_WingStuff thingy is missing a dependency called KSPUtil. You will need to reach whoever is maintaining this thingy and ask for further help! Cheers! — — POST EDIT — — I think it's B9 Aerospace ProceduralWings - but I'm not sure.

Pretty much, it's a cornerstone on some systems at dayjob. Also, it's what I use on my KSP config lint!

Abrams P-1 Explorer Source: https://en.topwar.ru/113619-eksperimentalnyy-samolet-razvedchik-abrams-p-1-explorer.html

IMHO, the best way to learn KSP is On the Kerbal Way! Take a look now and then on this thread: It's one of the oldest threads around here, with almost 10 years of very nice (and very crazy) crafts on KSP. A lot of them are crafts on sandbox made for fun, not to be used on career - but yet, this thread is a source of inspiration for me since my first days on KSP!

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!)