**NEW** Misbehaviour on KSP introduced by AttachedOnEditor about ksp-recall HOT 37 CLOSED

The Fault of Schrödinger. It's my fault, but at the same time it's not my fault… :P

I think I found what's happening: the order of the event handling should be considered random, but empirically it's defined by the order of the PartModules on the part's array of modules, that by itself is determined by the order the modules are loaded from the prefab, that by itself is determined by the order in which they are loaded from the GameData, that by itself is determined by the alphabetical sort made by KSP before trying to load things.

So, ModulePartVariant is probably called way later then ModuleEngine, by example.

I'm guessing that some new KSP Module on KSP 1.9.0 was assuming that ModulePartVariant would be handled before it, but since it was being handled before the Variant, something was left behind.

However, when I tackled down that problem I forgot to handle OnCopy correctly, that should preserve the current part position too in order to have it (re)applied by OnStart. What makes this my fault.

Problem is that, by the time I can handle OnCopy, the ModulePartVariants' OnCopy was not handled yet! So the available information is not valid, and my OnCopy handling became bonks. This explains why this problem is not my fault - and my explain the reason Squad decided to "solve" the problem this terrible way.

So… Some UnityEngine's Life Cycle black magic is on the need...

from ksp-recall.

No, no, no!!! It was not my fault after all!!! :D

The fix is working perfectly on KSP 1.9.1!!

It's something happening after KSP 1.9.1, working on detecting where the problem started to happen!

from ksp-recall.

Unsurprisingly, everything works fine on KSP 1.8.1 - what means that whatever is happening, affects KSP 1.9.x only.

from ksp-recall.

DAMN . This NEW problem started to happen on KSP 1.10.x probably (I have only 1.10.1 installed at this moment).

from ksp-recall.

FINALLY nailed it.

This is what's happening, believe it or not: When using Radial Symmetry, everything just works fine - no need for AttachedOnEditor at all. This made things extremely hard to diagnose because I just wasn't believing that things were fine on this use case!!

We have problems only with "single" parts, and with Copies for Mirror Symmetry.

Yep, it's what you had read: the most complicated use case works fine, we have problems with the most simple ones. (I had told you it's hard to believe)….

In a way or another, the crap is fixed now:

from ksp-recall.

It's kinda symptom for the nowadays mixture of neoliberalism and everyday-satanism (yes I mean that) which is poured over the whole world by those incompetent and corrupt representants of our species, those sociopath half-bakes who turn everything 180° around and call it new normal.

from ksp-recall.

It's kinda symtom for the nowadays mixture of neoliberalism and everyday-satanism (yes I mean that) which is poured over the whole world by those incompetent and corrupt representants of our species, those sociopath half-bakes who turn everything 180° around and call it new normal.

As weird as it appears, yeah. That's it - it's the very same behaviour applied to Computer Engineering. Just like Boeing, by the way.

from ksp-recall.

Well, I have very good news and terrible ones:

The good news is that the stunt is working now on KSP 1.10.x, and probably newer ones (still to be tested). That new problem I detected was not KSP 1.10 specific, it was merely detected on KSP 1.10.x, and by pure chance not on 1.9.x until I overcome my bias and start to cross-check things.

The terrible news is that the first time you load an affected craft after installing KSP-Recall, the craft became completely screwed up - all affected parts jump into Global Coordinate 0,0,0!!

(deep, despairing sigh)

Once you rebuilt the craft and save it, it stays fine. Crafts built from scratch stays fine too.

The damage for KSP 1.9.x users is already done. The very least I can do for them now is to release the Radial fix - they will still be mad with me on installing, but at least they will be able to use the thing after the initial trauma.

THANKS GOD this crap doesn't happen on Flight Time, only on Editor…

from ksp-recall.

I will keep the fix locked for KSP 1.9.x only until I figure out what's screwing up crafts on first load under AttachedOnEditor.

I'm placing my bets on the UpgradePipeline stunt.

from ksp-recall.

Humm… The UpgradePipeline stunt...

from ksp-recall.

Oukey. Found a workaround for the workaround - the craft will still be mangled at first, but not worse than the user already have. And once the user fix the craft, they stay fixed.

Commit: 9458f05

Now I need to find a way to make the first run work fine, finding my way around the UpgradePipeline. But I will leave this fight for another day.

from ksp-recall.

I will issue a new Release, as this have important fixes for everybody now. I will try to fix the upgrade pipeline thingy for the next release (without a date yet, RL™ is - as always - bitting).

from ksp-recall.

The commit 5182711 for the issue #35 screwed up things again here.

Well, as weird as it sounds, this ended up being a good thing. Now I know for sure where is the problem: the OnCopy must be handled differently on merging subassemblies.

[EDIT] NOPE. I reverted the commit and the problem persisted. It's something else, and I'm failing at this moment to understand exactly what's happening. [/EDIT]

I wish I could read the KSP source code - this is smelling terribly as a race condition. Without knowing the rules, I can't do things the "right" way.

from ksp-recall.

Just to be on the safe side, this is a note to myself in case I forget this again: by plain removing the AttachedOnEditor.dll file, the problem still happens.

Ergo, it's not something KSP-Recall is doing wrong.

It may be something it is not doing. Since the thingy works on KSP 1.8.1, it appears not be something on TweakScale - but, granted, it can be something TweakScale was doing wrong since ever and something on KSP stopped being lending it a hand...

from ksp-recall.

(sigh). O had already solved the puzzle above, but forgot about!

Problem is that, by the time I can handle OnCopy, the ModulePartVariants' OnCopy was not handled yet! So the available information is not valid, and my OnCopy handling became bonks. This explains why this problem is not my fault - and my explain the reason Squad decided to "solve" the problem this terrible way.

So… Some UnityEngine's Life Cycle black magic is on the need…

This a note for my future self: always reread the issue from the start, don't try to trust your (failing) memory!!!

from ksp-recall.

On commit TweakScale/TweakScale@56e5ed0 I removed on TweakScale a pretty old "gambiarra" that had always left a bad taste on my mouth.

KSP-Recall is handling KSP idiosyncrasies now, and this way I remove some surface of attack for 3rd parties' bad interactions. Not to mention that Recall fixes the problem for everybody, not only for TweakScale.

from ksp-recall.

Additionally, this is to document something that I'm recurrently forgetting to consider: the SubAssembly bug happens only for Stacked Attachments. Surface Attachments are fine!

Test on KSP 1.9.1, latest official KSP-Recall release:

from ksp-recall.

Also worths to mention that the subassemblies are working fine for scaled parts WITHOUT Variants!

(damn, I should had did this check sooner!!!)

from ksp-recall.

Well… Not sure if this will be useful (the problem may be related to the FSM) but yet…

This is the stackdump on the OnLoad of a part when loading a Craft from file:

[LOG 04:15:55.935] [KSP-Recall-AttachedOnEditor] TRACE:   at KSPe.Util.Log.Logger.stack (System.Object offended, System.Boolean forced) [0x00000] in <49c512f865634d58b19408150df06518>:0 
  at KSP_Recall.AttachedOnEditor.AttachedOnEditor.OnLoad (ConfigNode node) [0x00000] in <cf31acf231f64f3d8b26b7ff2d1b383a>:0 
  at PartModule.Load (ConfigNode node) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at Part.AddModule (ConfigNode node, System.Boolean forceAwake) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at PartLoader.ParsePart (UrlDir+UrlConfig urlConfig, ConfigNode node) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at PartLoader+<CompileParts>d__56.MoveNext () [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <7d9ec060e791409ab3eb85c61e312ed6>:0 

And this is the one for OnLoad when loading a SubAssembly:

[LOG 04:18:07.249] [KSP-Recall-AttachedOnEditor] TRACE:   at KSPe.Util.Log.Logger.stack (System.Object offended, System.Boolean forced) [0x00000] in <49c512f865634d58b19408150df06518>:0 
  at KSP_Recall.AttachedOnEditor.AttachedOnEditor.OnLoad (ConfigNode node) [0x00000] in <cf31acf231f64f3d8b26b7ff2d1b383a>:0 
  at PartModule.Load (ConfigNode node) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at Part.LoadModule (ConfigNode node, System.Int32& moduleIndex) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruct.LoadShip (ConfigNode root, System.UInt32 persistentID, System.Boolean returnErrors, System.String& errorString) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruct.LoadShip (ConfigNode root, System.UInt32 persistentID) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruct.LoadShip (ConfigNode root) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruction.OnPipelineFinished (ConfigNode node, ShipTemplate template, Callback`1[T] onComplete) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruction+<>c__DisplayClass54_0.<CreateConstructFromTemplate>b__0 (ConfigNode n) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSPUpgradePipeline.Process (ConfigNode n, System.String saveName, SaveUpgradePipeline.LoadContext loadContext, Callback`1[T] onSucceed, Callback`2[T,U] onFail) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruction.CreateConstructFromTemplate (ShipTemplate template, Callback`1[T] onComplete) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at EditorLogic.SpawnTemplate (ShipTemplate st) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at EditorLogic.OnPartListIconTap (ShipTemplate st) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSP.UI.Screens.EditorPartList.TapIcon (ShipTemplate st) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSP.UI.Screens.EditorSubassemblyItem.MouseInput_Spawn () [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at UnityEngine.Events.InvokableCall.Invoke () [0x00000] in <7d9ec060e791409ab3eb85c61e312ed6>:0 
  at UnityEngine.Events.UnityEvent.Invoke () [0x00000] in <7d9ec060e791409ab3eb85c61e312ed6>:0 
  at UnityEngine.UI.Button.Press () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ReleaseMouse (UnityEngine.EventSystems.PointerEventData pointerEvent, UnityEngine.GameObject currentOverGo) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ProcessMousePress (UnityEngine.EventSystems.PointerInputModule+MouseButtonEventData data) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent (System.Int32 id) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.Process () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.EventSystem.Update () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 

And this one, for Merge:

[LOG 04:17:45.034] [KSP-Recall-AttachedOnEditor] TRACE:   at KSPe.Util.Log.Logger.stack (System.Object offended, System.Boolean forced) [0x00000] in <49c512f865634d58b19408150df06518>:0 
  at KSP_Recall.AttachedOnEditor.AttachedOnEditor.OnLoad (ConfigNode node) [0x00000] in <cf31acf231f64f3d8b26b7ff2d1b383a>:0 
  at PartModule.Load (ConfigNode node) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at Part.LoadModule (ConfigNode node, System.Int32& moduleIndex) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruct.LoadShip (ConfigNode root, System.UInt32 persistentID, System.Boolean returnErrors, System.String& errorString) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruct.LoadShip (ConfigNode root, System.UInt32 persistentID) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at ShipConstruct.LoadShip (ConfigNode root) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at EditorLogic.ShipToLoadSelected (System.String path, KSP.UI.Screens.CraftBrowserDialog+LoadType loadType) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSP.UI.Screens.CraftBrowserDialog.onPipelineFinished (ConfigNode n, KSP.UI.Screens.CraftEntry sItem, KSP.UI.Screens.CraftBrowserDialog+LoadType loadType) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSP.UI.Screens.CraftBrowserDialog+<>c__DisplayClass119_0.<pipeSelectedItem>b__0 (ConfigNode n) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSPUpgradePipeline.Process (ConfigNode n, System.String saveName, SaveUpgradePipeline.LoadContext loadContext, Callback`1[T] onSucceed, Callback`2[T,U] onFail) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSP.UI.Screens.CraftBrowserDialog.pipeSelectedItem (KSP.UI.Screens.CraftEntry sItem, KSP.UI.Screens.CraftBrowserDialog+LoadType loadType) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at KSP.UI.Screens.CraftBrowserDialog.onButtonMerge () [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 
  at UnityEngine.Events.InvokableCall.Invoke () [0x00000] in <7d9ec060e791409ab3eb85c61e312ed6>:0 
  at UnityEngine.Events.UnityEvent.Invoke () [0x00000] in <7d9ec060e791409ab3eb85c61e312ed6>:0 
  at UnityEngine.UI.Button.Press () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ReleaseMouse (UnityEngine.EventSystems.PointerEventData pointerEvent, UnityEngine.GameObject currentOverGo) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ProcessMousePress (UnityEngine.EventSystems.PointerInputModule+MouseButtonEventData data) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent (System.Int32 id) [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.StandaloneInputModule.Process () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 
  at UnityEngine.EventSystems.EventSystem.Update () [0x00000] in <edc19f239d8642a2b533c214a7b029d5>:0 

from ksp-recall.

Humm… Apparently our old friend KSPUpgradePipeline may be implicated on the mess. It is being called on Merge and SubAssembly, but not on Loading the craft from file…

  at KSPUpgradePipeline.Process (ConfigNode n, System.String saveName, SaveUpgradePipeline.LoadContext loadContext, Callback`1[T] onSucceed, Callback`2[T,U] onFail) [0x00000] in <48dcb08e2e1542e2af1286b02d2eb072>:0 

I want to emphasise APPARENTLY because correlation is not the same as causality!

It also worth to mention that I know for sure that KSPUpgradePipeline is also used while loading a Craft from file (see TweakScale's commit TweakScale/TweakScale@645cca7 for further details) , it only happens this is happening on a different stage of the PartModule's life cycle - and I suspect the problem may be it.

from ksp-recall.

Au contraire from what's suggested on Forum, Cargo Bays are not affected by this problem (unless they have PartModuleVariant).

This quick test demonstrates that only Parts with Variants, scaled and attached superficially are prone to the problem on Merge and SubAssemblies.

from ksp-recall.

The problem described in red on the last post was fixed by commit 31e4a09

from ksp-recall.

This one caught me with my pants down - I must have misdiagnosed something, because this behaviour doesn't makes sense if I would be right:

Given this test craft:

If I alt+click on the Kerbodyne ADTP-2-3 part:

The duplicate is OK:

BUT If I alt-click on the TS-25 Stack Separator:

The duplicate is screwed up!!!

For what I understand, both duplicates should be screwed the same!!

Then I made this other test craft with an UNESCALE TS25.

Same problem, the scaled fuel tank (that have a variant) was misplaced the same:

And then I made this other craft, switching the first separator with a decoupler:

And then made the following duplicates with Alt+Click:

As long the root part of the Duplicate is not a Separator, things works fine! So this is not something I'm doing wrong, it's something I'm triggering when the root part is a Separator (perhaps others? Need to investigate)!

from ksp-recall.

Both the Separator and the Decopler use the ModuleDecouple, so I don't think the misbehaviour is related to it.

The Decoupler has ModulePartVariantand the Separator has not, so I made this new test to use another part without Variant as root:

And the damned thing worked fine.

Craft file (made on KSP 1.9):
craft_file.zip

from ksp-recall.

Found something that appears to support my working theory:

The difference between both SubAssemblies is the root part, as follows:

Additionally, it was found that Alt+CLick is not necessarily reproducing the problem the same as SubAssembly and Load To Merge!

Both test crafts worked fine while Alt+CLicking them, besides the NCS Adapter being knwon to bork on the SubAssembly.

I think I can conclude that some of the Alt+Click problems were due the AttachedOnEditor not updating its data on saving.

However, this misbehaviour still happens when the root part is a Stack Separator. Life is not interesting?

from ksp-recall.

I determined that the problem is, INDEED, related to what part is the root of the subassembly.

The following crafts are virtually equals, being the only difference that part that are attached to the Kerbodyne ADTP-2-3:

The decoupler is OK:

The Separator is not:

I just can't figure out - at least by now - why the Separator borks and the Decoupler works. I will try to analyse the craft files looking for a clue.

craft files (used on KSP 1.9) : craft_files.zip

from ksp-recall.

Found a pattern! It's pretty obvious, to tell you the true.

Parts without Variants are borking when used as root! At least on SubAssemblies - mysteriously, some of these parts works fine on Alt+Click, what suggests we have two different problems with the same misbehaviour.

The following craft is a known friend from a previous test:

And, exactly as the previous test, it works fine on Alt+Click (what leaded me to the wrong conclusion that Parts without Variants would not be the source of the problems:

But then I saved the subtree into a SubAssembly file and tried to use it:

Craft file (KSP 1.9): craft_file.zip

from ksp-recall.

Oukey, so the current suspects are Parts without Variants used as root.

Now we need to establish if the problem is on the Part itself, or in some kind of interaction using it - i.e., we need to know if they are the culprits or the triggers for the problem.

So I made this new test craft, using only parts without variants that I know triggered the problem earlier:

Then I Alt+Click (left) and saved to a SubAssembly and loaded (rigth) the subtree starting from the Separator - a condition that was already established to trigger the problem:

And voilá: things are working fine!

We finally stablished the Modus Operandi of the problem: when the root part has no variants, a part with variant attached to it will be horribly misplaced: every time on SubAssemblies, some times on Alt+Clicks.

On any other situation (at least until this moment), the thing works fine.

Craft file:
Untitled Space Craft E.craft.zip

from ksp-recall.

Analysis of the TweakScale code being victim of this problem suggests that whatever is happening, it's related to the attachment point failing to be correctly initialised, what so screws up the TS attempt to Translate the attachment point to the correct place using attachedPart.transform.Translate().

from ksp-recall.

Damn. I think I know why this crap started to happen at first place.

Somehow, Squad created a race condition while initialising things.

The an.nodeTransform of the this.part.attachNodes are still null on OnLoad.

Let's try to move the Initialisation of the module to the first Update(), as I do with TweakScale…

EDIT: wrong turn. Move on, nothing to see here!

from ksp-recall.

Krapp…

Even on the first Update, the nodeTransform is still null… (sigh).

from ksp-recall.

HUMM… WAIT…

If on the First Update(), the nodeTransform is still null, how in hell I will restore it later? The restore happens on that very first Update()!

And I can't try using the second Update() thingy in the hopes something gets magically fixed because TweakScale also works on the very first Update() and need the data ready to be used by that time…

EDIT: wrong turn. Move on, nothing to see here!

from ksp-recall.

I think my last line of research was a dead end. The nodeTransform of all nodes of all parts is null at first Update, but since SubAssemblies starting with a part with variant is working nevertheless, the nodeTransform is not the part of the solution.

Well…. "de volta pro tronco…"

from ksp-recall.

I nailed it on commit a49fa99 ! :)

But there's a caveat - I couldn't salvage existing SubAssemblies, I needed to recreate them (with the updated release 3 of AttachedOnEditor) in order to made then work.

This is somewhat unfortunate - I will publish a PRE-RELEASE for KSP-Recall and then I will try to figure out something to try to salvage pre-existent SubAssemblies.

from ksp-recall.

Pre Release 0.2.2.0 on this tag.

I will try to cook up something to salvage the pre-existent SubAssemblies before spreading this to the wide public.

from ksp-recall.

Well, my attempts to salvage current SubAssemblies had failed. I found no way "intercept" the loading process from inside the AttachedOnEditor module.

I think I would need to write a UpgradePipeline thingy to such task - but, unfortunately, I don't have the time to learn to do it by now.

So I'm concluding this issue and I'm releasing a new KSP-Recall release as is.

from ksp-recall.

For the sake of historic accuracy, this issue ended up being a duplicated of #32 - but ended up being handled separately because I didn't managed to correctly diagnose the real cause of the problem at that time.

from ksp-recall.