Lisias

ANNOUNCE KSP Recall 0.2.2.1 is on the Wild, featuring: Formally closes issues: #35 AttachedOnEditor is not working for SubAssemblies. #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor A new problem was found, affecting Editor since KSP 1.9, where some parts are triggering a strange misbehaviour when you Alt+Click a part for a duplicate, when Loading a craft for Merge or when loading a SubAssembly. It was determined that when Parts without ModulePartVariant is the root of the SubAssembly, the parts attached to it must have the ModulePartVariantotherwise the problem will be triggered. I realised that the problem is that the Positions on the Attachment Nodes are not being initialised by the vanilla Parts - apparently the initialisation was moved to the ModulePartVariant module. This may be the reason Squad choose to shove prefab back into the craft when loading it from the Editor, as apparently they didn't were able to pinpoint the cause of the misbehaviour... Problem: I solved the problem for SubAssemblies and Craft files saved after installing the newest Release of KSP-Recall, but didn't managed to cook a way to salvage the pre-existent ones. - Currently, there's no other alternative but to redo your SubAssemblies. I failed to find a viable automated process for salvaging them. 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. Right Now. SpaceDock (and CKAN users). Right Now. I was called to duty before publishing the release on SpaceDock, sorry. As long as I solve the RL problem, I will update SpaceDock - but experience taught me to do not be optimistic about these things.

Not a problem, it makes sense. May I ask you to post on KSP-Recall too? It's interesting information, and some KSP-Recall users don's use TweakScale! Kerbthrottling!!!!

Unlikely, there're some serious bugs on these releases that are still to be addressed - and, frankly, I think the KSP1 shop is already closed. We can still hope for a new 1.12.4 maintenance release, but don't hold your breath. And, without having these bugs addressed, I doubt they will update the Console version - people on Consoles are getting fed up with buggy games, see Cyberpunk 2077 in the past and recently Battlefield 2042. Of course I can't talk for them (I may be completely wrong), but if I was on their shoes I would avoid risking an update that could be the straw that will brake the camel's back.

Having a "gun" pointed your heads is a hell of a motivator!!!

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!