[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.7.6 - 2024-0322

[Rutabaga22]

I don't know what's happening.

Log:https://drive.google.com/file/d/1wQH7Pk81VZvJ336n9UIN9IpnCsx6p1Aa/view?usp=sharing

[Lisias]

2 hours ago, Rutabaga22 said:

I don't know what's happening.

Log:https://drive.google.com/file/d/1wQH7Pk81VZvJ336n9UIN9IpnCsx6p1Aa/view?usp=sharing

You need to install KIS!

[ERR 20:24:48.806] ADDON BINDER: Cannot resolve assembly: KIS, Culture=neutral, PublicKeyToken=null

[ERR 20:24:48.810] AssemblyLoader: Exception loading 'SuperKerbal': System.Reflection.ReflectionTypeLoadException: Exception o
f 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0

Additional information about this exception:

 System.IO.FileNotFoundException: Could not load file or assembly 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyTok
en=null' or one of its dependencies.
File name: 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null'

Cheers!

[Lisias]

NOTAM

Well, that was unexpected.

It's not exactly news that TweakScale suffered some regressions recently when I removed some "gambiarras" from the code tree. The rationally was simple: I was (potentially) screwing up 3rd parties the same way KSP-Editor was screwing up TweakScale - not exactly a nice move, and a sure source of headaches in the long run.

One of the problems I unleashed confused me because it was causing misbehaviours downto KSP 1.4.3, where KSP Editor should be behaving since the Editor's problems started to bite TweakScale on KSP 1.9.x . 

I was wrong.

The KSP Editor problems started to happen on KSP 1.4.3 (probably on KSP 1.4.2, the Brief) and me, without being aware, shoved a brute-force solution directly on TweakScale. When 1.9.x's Editor broke TweakScale again I thought it was the first time, and then I decided to write KSP-Recall to counter-screw the Stock's misbehaviours. By moving the counter-screws from TweakScale, I resurrected the problem on KSP versions that I thought was Screw Ups free - and then concluded that I had removed something I shouldn't, but could not find what as by "fixing" things on 1.4.3 I got back the screwups on KSP >= 1.9: it's hard to fix a bug that doesn't exists!

Well, aftermath:

• KSP Recall 0.3.0.2 was released, shoving AttachedOnEditor on parts' SAS downto KSP 1.4.3.
  • So, yeah, it's official. The last KSP version really "almost" bug free is, indeed, 1.3.1  
• I lost weeks (mainly due time scarcity) chasing my damned tail on TweakScale bugs that don't exist, instead of diagnosing the ones that really do. Again.  
• Next TweakScale release will demand KSP Recall from KSP 1.4.3 and upwards.
  • Annoying, I agree. But it's the less bitter solution from the range of possible solutions.
  • In a way or another, how much KSP < 1.8 players like me are still around?
• On the bright side, TweakScale's code base will probably have another cleanup.
  • There're good chances that the few remaining "gambiarras" can also be tracked down to some still unknown pretty old KSP's idiosyncrasies that at that time I misdiagnosed as TweakScale's problems.
  • And "gambiarras" don't pile up nicely, I can assure you.

[Aussie Toad Stool]

Tweakscale couldn't find the required dll? 

What be causing things to go wack?

https://drive.google.com/file/d/10vPJLyUpoXC7ck4tA1-G4jWC1uTPLBX2/view?usp=sharing  <- ksp.log here

Edited September 5, 2022 by Aussie Toad Stool
/ to . @ ksp.log

[Lisias]

7 hours ago, Aussie Toad Stool said:

Tweakscale couldn't find the required dll? 

What be causing things to go wack?

https://drive.google.com/file/d/10vPJLyUpoXC7ck4tA1-G4jWC1uTPLBX2/view?usp=sharing  <- ksp.log here

You got bitten by a nasty KSP bug on a thingy called Assembly Loader/Resolver. When something (absolutely anything) fails to be loaded by some reason, something breaks on this critical piece of code and from that point anything else trying to be loaded borks as if the DLL was not there.

In your case, it's SigmaDimensions:

[ERR 13:31:41.835] ADDON BINDER: Cannot resolve assembly: PreciseManeuver.Unity, Culture=neutral, PublicKeyToken=null

[ERR 13:31:41.860] AssemblyLoader: Exception loading 'SigmaDimensions': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.Reflecti
onTypeLoadException' 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0

Additional information about this exception:

 System.TypeLoadException: Could not resolve type with token 01000014 (from typeref, class/assembly Kopernicus.IParserEventSubscriber, Kopernicus.Parser, Version=1.
0.0.0, Culture=neutral, PublicKeyToken=null)

 System.TypeLoadException: Could not resolve type with token 0100003c (from typeref, class/assembly Kopernicus.Configuration.BaseLoader, Kopernicus, Version=1.0.0.0
, Culture=neutral, PublicKeyToken=null)

[ERR 13:31:41.872] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null

It's trying to load some Kopernicus' DLLs, and the DLLs are there, but the DLLs are not exactly what Sigma expected (see the "could no resolve token" thingy). This means that Sigma was compiled against a different version of the DLL that is present on the system. I can't say if your Sigma or your Kopernicus are too old, but you need to update one of them - I suggest to download the most recent zips from both and update your rig. If by downloading and installing the latest version of the involved DLLs you still get the problem, you will need to reach SigmaDimension's maintainers for further help, as I don't know SD or Kopernicus to identify the problem!

Cheers!

[Aussie Toad Stool]

Ah ok, The assembly loader giveth and taketh away. Sigma Dimensions was a old ksp resize mod that i used to play in 2.5 times scale. Guess i better find another mod to do that. Thanks for the help.

[Merlin1809]

Would it be possible for you to update this: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks to work again please? Currently it does not show Waterfall plumes. Adjusting them by hand is so tedious and this mod would have been a massive time saver.

[Lisias]

1 hour ago, Merlin1809 said:

Would it be possible for you to update this: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks to work again please? Currently it does not show Waterfall plumes. Adjusting them by hand is so tedious and this mod would have been a massive time saver.

Can you be more specific? I built a quick testbed and found no obvious misbehaviours:

I used:

• KSP 1.12.3 + DLCs
• ModuleManager (my fork, but it really doesn't matter - it mimics the Forum one even on the bugs)
• Latest TweakScale (2.4.6.16 at this moment)
• Latest TweakScale Companion for Frameworks (0.3.0.0 beta at this moment)
• Latest Waterfall (0.9.0 at this moment)
• Latest Stock Waterfall Effects (0.7.0 at this moment)

(links on this post)

Even that pesky bug that resets the plume's scaling on Revert to Launch is still there (really need time to tackled down this one, it will be one of that bugs that you take days to diagnose and 15 minutes to fix…).

One thing that I noticed is that I left the 0.3.0.0 flagged as Pre-Release, so there's a chance that you may be installed 0.2.0.0 instead. If  this is the case installing TSC-F 0.3.0.0 will fix your problem.

Otherwise, please send a craft file and a KSP.log where the problem happens - it may be some Kraken Food (bad interactions between PartModules).

Cheers!

[Merlin1809]

Spoiler

With the same mods as you.

With my normal modpack

Also with my normal modpack

Ok, so I just flew a plane and the plumes didn't show. I have version 0.3.0.0 installed. After testing again, it seems they only don't work for the Panther (with and without afterburner on). Tested it with my normal modpack and with a clean install.

14 hours ago, Lisias said:

Can you be more specific? I built a quick testbed and found no obvious misbehaviours:

I used:

• KSP 1.12.3 + DLCs
• ModuleManager (my fork, but it really doesn't matter - it mimics the Forum one even on the bugs)
• Latest TweakScale (2.4.6.16 at this moment)
• Latest TweakScale Companion for Frameworks (0.3.0.0 beta at this moment)
• Latest Waterfall (0.9.0 at this moment)
• Latest Stock Waterfall Effects (0.7.0 at this moment)

(links on this post)

Even that pesky bug that resets the plume's scaling on Revert to Launch is still there (really need time to tackled down this one, it will be one of that bugs that you take days to diagnose and 15 minutes to fix…).

One thing that I noticed is that I left the 0.3.0.0 flagged as Pre-Release, so there's a chance that you may be installed 0.2.0.0 instead. If  this is the case installing TSC-F 0.3.0.0 will fix your problem.

Otherwise, please send a craft file and a KSP.log where the problem happens - it may be some Kraken Food (bad interactions between PartModules).

Cheers!

Edited September 7, 2022 by Merlin1809

[Lisias]

1 hour ago, Merlin1809 said:

Ok, so I just flew a plane and the plumes didn't show. I have version 0.3.0.0 installed. After testing again, it seems they only don't work for the Panther (with and without afterburner on). Tested it with my normal modpack and with a clean install.

So your problem is lack proper support for some parts.

Waterfall recognises patches for SmokeScreen AFAIK, so perhaps you should install SmokeScreen and the SmokeScreen support for the Panther? I think this will solve your issue - and SmokeScreen is a serious improvement over the Stock plumes - so it worths to have it installed to have some visuals for parts that doesn't have Waterfall support yet.

(and the thing works fine with TweakScale!)

[Merlin1809]

1 hour ago, Lisias said:

So your problem is lack proper support for some parts.

Waterfall recognises patches for SmokeScreen AFAIK, so perhaps you should install SmokeScreen and the SmokeScreen support for the Panther? I think this will solve your issue - and SmokeScreen is a serious improvement over the Stock plumes - so it worths to have it installed to have some visuals for parts that doesn't have Waterfall support yet.

(and the thing works fine with TweakScale!)

But the Panther has Waterfall support. Without the TweakScale Framework addon it works normally. Or do you mean that the TweakScale Framework doesn't support all Waterfall parts?

Spoiler

Panther Engine without the TSC Framework installed with the waterfall plume.

Edited September 7, 2022 by Merlin1809

[Lisias]

9 hours ago, Merlin1809 said:

But the Panther has Waterfall support. Without the TweakScale Framework addon it works normally. Or do you mean that the TweakScale Framework doesn't support all Waterfall parts?

Occam's Razor:  It is generally understood in the sense that with competing theories or explanations, the simpler one, for example a model with fewer parameters, is to be preferred.

If we have a misbehaviour happening only a part while TweakScale (and the Companion) works in everything else, it's more reasonable to assume there's a problem on the part itself and not on TweakScale (or the Companion).

I need more evidence in order to pursue the problem from the TweakScale Companion side - until there, I will pursue the hypothesis of being something wrong with the Panther or with the patch applied to Panther.

I will do further tests as time allow, but since the misbehaviour couldn't be reproduced (yet) on a Stock part, I'm considering this as an "unrelated" bug. At least on the short term while new evidences aren't revealed.

— — POST EDIT — — 

It's definitively unrelated. On the same testbed used before, the Panther 's plume is scaling allright!

From now on is, definitivelly, something else on your rig. I can try to help, please send me the full KSP.log (and it must be the KSP.log), the Log/ModuleManager logs (all of them) and also the ModuleManager.ConfigCache from your GameData.

You can zip the whole shebang and publish it on DropBox or something - or, if you have a github account, you can paste de zip on a comment on this issue: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/issues/5#issuecomment-1238652108

Edited September 7, 2022 by Lisias
POST EDIT

[Merlin1809]

12 hours ago, Lisias said:

Occam's Razor:  It is generally understood in the sense that with competing theories or explanations, the simpler one, for example a model with fewer parameters, is to be preferred.

If we have a misbehaviour happening only a part while TweakScale (and the Companion) works in everything else, it's more reasonable to assume there's a problem on the part itself and not on TweakScale (or the Companion).

I need more evidence in order to pursue the problem from the TweakScale Companion side - until there, I will pursue the hypothesis of being something wrong with the Panther or with the patch applied to Panther.

I will do further tests as time allow, but since the misbehaviour couldn't be reproduced (yet) on a Stock part, I'm considering this as an "unrelated" bug. At least on the short term while new evidences aren't revealed.

— — POST EDIT — — 

It's definitively unrelated. On the same testbed used before, the Panther 's plume is scaling allright!

From now on is, definitivelly, something else on your rig. I can try to help, please send me the full KSP.log (and it must be the KSP.log), the Log/ModuleManager logs (all of them) and also the ModuleManager.ConfigCache from your GameData.

You can zip the whole shebang and publish it on DropBox or something - or, if you have a github account, you can paste de zip on a comment on this issue: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/issues/5#issuecomment-1238652108

Ok, so I've reinstalled KSP and all of these mods completely and now it's working. I don't know why, because I already had the newest version of every mod. Thanks for trying to help!

[Lisias]

4 hours ago, Merlin1809 said:

Ok, so I've reinstalled KSP and all of these mods completely and now it's working. I don't know why, because I already had the newest version of every mod. Thanks for trying to help!

Humm…. Do you know what? If you reinstalled the very same add'ons you had before, I can think on two possibilities:

1. Some patch on your rig was compromised
2. You was bitten by an interesting and evasive Module Manager (potential) weakness on calculating and using the SHA of the files on your rig.

You would not be the first one to get bitten by (2), by the way. The technical explanation is somewhat… "technical"  but TL;DR: digests (and SHA is a digest) are intended to check integrity, not identity. But MM use a digest (SHA) to do exactly the later, what now and then gives you a false positive and so MM don't recalculate the patches when it should.

Next time you get something weird like this, try to delete the ModuleManager.ConfigCache and restart KSP to see if the problems goes away, and only after it failing go for a full reinstall. Most of the time it will not fix the issue (collisions due the digest being used as identity are not that common after all), mas since it's a pretty cheap measure, it worths a try in the hope of avoiding a full reinstall.

Cheers!

[sturmhauke]

On 9/4/2022 at 2:24 AM, Lisias said:

And "gambiarras" don't pile up nicely, I can assure you.

I believe "gambiarra" translates most accurately to "dirty hack". It gets the job done, but it doesn't follow good coding practices, maybe only addresses a symptom but not the true underlying issue, is hard to read, is not easily extendible, etc.

[Lisias]

On 9/8/2022 at 2:35 PM, sturmhauke said:

I believe "gambiarra" translates most accurately to "dirty hack". It gets the job done, but it doesn't follow good coding practices, maybe only addresses a symptom but not the true underlying issue, is hard to read, is not easily extendible, etc.

Exactly! And the problems with "dirty hacks" is that once you do it more than once on the same code, you gets into a serious risk of having them screwing up with each other - and, by consequence, the code at a whole.

It's essentially what happened on KSP Editor - my first attempt to fix the problem ended up being a dirty hack (as I didn't understood the root problem at that time). Then, on KSP 1.9.x when KSP Editor struck again, the workaround I implemented ended up screwing up 3rd parties due the first "fix"; both "fixes" when piled made everything harder to diagnose.

Let me tell you the whole history, as I known it by now (and I still may be wrong!  ):

1. On KSP 1.4.3 (but probably the problem really started on 1.4.2, but since this release lasted only a few days…), TweakScale started to have the stack attachment nodes reset on KSP. I Didn't understood it was an Editor only problem, so I brute forced my way into the problem and it was applied all the time.
   1. The (now understood) collateral effect is that any other add'on that also changes de stack attachment nodes gets royally screwed at flight by TweakScale! 
2. On KSP 1.9.0, Editor started to reset also the radial attachment nodes! And this time, I managed to correctly diagnose the problem, and got it worked around on the right place only (Editor)
   1. But I let pass trough the Stack Nodes, as TS was brute forcing it all the time since some time and I wasn't seeing this as a problem anymore.
   2. And yet, it was not the best way possible to solve the problem.
3. Some time later, I realized the consequences of brute forcing my way about radial nodes and incepted KSP-Recall. KSP-Recall would be in charge of "unscrew" the radial attachments being screwed by Editor the soon as possible - so TweakScale was removed from the problem at all. Any mishap on the solution would be tackled down on KSP-Recall, where I was in way better position (the start of the OnLoad chain) to fix the problem before anyone else would try to change something.
   1. But the stack attachment nodes were left behind, again.
4. Early this year I finally was enlightened by some divinal entity, and understood the full problem - but, funny enough, I didn't cogitated the hypothesis that the problem was happening since 1.4.x!!
   1. So the proper fix I applied were not being applied on KSP < 1.9, and once I removed the gambiarras, I broke things for them
      1. And yeah, at least me still plays on them
5. Once I correctly diagnose the source of problem, I found a bug on TweakScale's code responsible to move parts to match the new Attachment Nodes positions: due something I missed while coding it, parts being attached "inverted" (i.e., the bottom node being used to attach it to the bottom node of the parent part), the thing was getting screwed at OnLoad.
   1. Further analyzing this code, I realized that it is, also, rooted on my initial misdiagnosing - I ended up rewriting a good fraction of TweakScale without being needed at all, as the unique problem on the original TS code is not being able to look for nodes on the Variants (as that code knows squat about it at first place)
6. So, now, instead of fixing the redundant code, I removed it and I'm reusing original TweakScale code - but adapted to fetch the Attachment Nodes from the Variant when available.
   1. Interesting enough, I'm fighting a glitch on the thing where the parts are being placed slightly ahead of the ideal position - this is what I'm working at the moment (as time allows).

Gambiarras are not a bad thing by definition - they may be the best technical solution given a specific problem (are you aware that adhesive tapes now and then are used even on airplane's engines, right?)

Spoiler

https://www.mirror.co.uk/news/uk-news/shocked-passenger-snaps-airport-worker-5789181

The problems are:

• Misunderstanding them as a proper, robust fix.
• Forgetting about them and building code over it, relying on the side effects (something, most of the time undesirable)

And this explains the whole drama - as well a lot of problems on KSP, by the way.

Early this year, once I proper diagnosed the problem, I found what appears to be the root cause: when the craft you are building starts with a part without variant as root, and it is followed by another part without variant, the ModulePartVariant fails to initialize itself and the whole craft is royally screwed. By starting the craft with a Variant, or having the second part as a Variant, the problem is not triggered and everything works as expected.

Or something like this, I forgot the gory details, I think I have it documented on a issue somewhere on the tracking (perhaps on KSP-Recall one).

So I'm guessing that whoever was in charge on fixing this problem never really diagnosed it as I eventually did, and so shoved a hell of a gambiarra on the Editor to work around the problem instead of fixing it. Then this stunt screwed TweakScale (and a lot of add'ons more - it only happened that I was the one stubborn enough to try to tackle the problem down), but I ended up doing another gambiarra over the initial Stock one. On KSP 1.9.x the third piled up gambiarra started to cause me problems (but, to make things absolutely clear, I'm pretty sure my first gambiarra, the second on the chain, screwed someone in the mean time).

And now we are where we are.

Edited March 23 by Lisias
Tyops gallore!! (yeah, I'm fixing them 1 year and a half later)

[sturmhauke]

1 hour ago, Lisias said:

Exactly! And the problems with "dirty hacks" is that once you do it more than once on the same code, you gets into a serious risk of having them screwing up with each other - and, by consequence, the code at a whole.

It's essentially what happened on KSP Editor - my first attempt to fix the problem ended up being a dirty hack (as I didn't understood the root problem at that time). Then, on KSP 1.9.x when KSP Editor struck again, the workaround I implemented ended up screwing up 3rd parties due the first "fix", both "fixes" when piled made everything harder to diagnose.

 

[Lucky21]

https://drive.google.com/file/d/1PSd8tpTya8WePRzA0uRDBHUrRMYMDK2Q/view?usp=sharing

Fatal Error, what is the cause? how do I fix it?

[Lisias]

1 hour ago, Lucky21 said:

https://drive.google.com/file/d/1PSd8tpTya8WePRzA0uRDBHUrRMYMDK2Q/view?usp=sharing

Fatal Error, what is the cause? how do I fix it?

Hi! You got a nasty occurrence of a duplicated patch:

[LOG 19:32:19.935] [TweakScale] ERROR: **FATAL** Part pp.vvmach (Plume Party Vapor Vent Mach) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

We will need to find who is double patching the pp.vvmach e fix it. Problem: I found the same patch happening 3 times on your log!

[LOG 19:09:24.429] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 19:09:24.430] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]
[LOG 19:09:24.431] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach]

And I don't have the slighest idea about the reason. KSP Recall modules are also being applied 3 times!

And the reason appears to be you having more than one copy of ModuleManager running on the rig!

[LOG 19:23:02.404] AssemblyLoader: Loading assembly at D:\Games\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.2.2.dll
[LOG 19:23:02.405] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0
[LOG 19:23:02.554] AssemblyLoader: Loading assembly at D:\Games\steamapps\common\Kerbal Space Program\GameData\Benjee10_Orion_v1.1.0\GameData\ModuleManager.4.2.2.dll
[LOG 19:23:02.568] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0

Interesting… It was my understanding that on KSP 1.12.3 duplicated DLLs would be resolved by promoting only the newest one to run, but apparently I was wrong.

Completely remove the directory GameData\Benjee10_Orion_v1.1.0 and see if the problem goes away - I expect it does.

After confirming the diagnosis, you will need to install Benjee10_Orion correctly: you need to unzip the package into a temporary directory, and then move the package's GameData contents into your KSP's GameData, instead of unzipping the thing on the KSP's Root and hoping for the best.

Additionally, pay special attention to avoid having more than one ModuleManager installed on your rig - apparently this is not safe as I was thinking.

[DY_ZBX]

Hi Lisias, I'm having a problem with "parts floating" when I try to open a carrier from a folder and merge it.

Here is a video of my demo.

https://drive.google.com/file/d/18YkxyBViRqDLSWlDtzULqFhZS-nnuTZi/view?usp=sharing

[Lisias]

4 hours ago, DY_ZBX said:

Hi Lisias, I'm having a problem with "parts floating" when I try to open a carrier from a folder and merge it.

Here is a video of my demo.

https://drive.google.com/file/d/18YkxyBViRqDLSWlDtzULqFhZS-nnuTZi/view?usp=sharing

Known issue. It's related to merging a craft created without KSP-Recall on a rig with KSP-Recall installed: I never got a firm grasp on the "Upgrade Pipeline" thingy that is what (I think at least) would do it automatically for you what I'm going to explain how to to it by "brute force":

In order to have KSP-Recall properly active on your crafts for merge, you need to  load and save every parcel craft first to make sure everyone has the PartModules installed, configured and active. Once everything has KSP-Recall's PartModules working, your merges will succeed. You need to do it only one time, by the way. Thanks Kraken.  

This is also needed with SubAssemblies. Craft Manager is on the rescue here, it allows you to load an Assembly as it was a ordinary craft and once the thing is loaded, KSP-Recall is injected on it and you can save the SubAssemblies back to the filename.

Danger, Will Robinson, Danger!! Technical Gobbledygook below!

Spoiler

TweakScale is not at fault at all. The problem is KSP's Editor, and the problem is detailed on my post above.

What's happening is that Editor is resetting the attachment nodes outside the PartModule's Life Cycle, making it impossible to overcome the problem in a clean way.

In the past, TweakScale was brute forcing its way on the problem, what worked - but ended up doing to 3rd parties what Editor did to Editor, and in a equally unmanageable way,

 KSP-Recall was born to solve this (and some others) problems on a more 3rd-party friendly way. Being run pretty early on the PartModule's Life Cycle, it has a chance of detecting and working around the problem before most Add'Ons can get hit by it (it's the reason it has "999_" on the name, to induce KSP to load it before common add'ons!!).

However, the damned thing must be installed, configured and active on the crafts in order to work. So KSP-Recall smartly detects when an pre-Recall craft file is being loaded and reconfigure itself, saving the day.

But merging crafts (and sub-assemblies) are a completely different beast, with things being made out of the PartModule's Life Cycle again. And this time I didn't found a workaround - the ideal solution is, probably, writing a proper KSP Upgrade Pipeline tool that would properly inject KSP-Recall on existing crafts - I say "probably" because this thing is executed after the OnLoad and before the first Update and I never managed to figure out exactly when. So I can't say for sure if this will work before trying it - and, as I mentioned before, I didn't managed to cut my teeth on it yet.

 

[DY_ZBX]

39 minutes ago, Lisias said:

Known issue. It's related to merging a craft created without KSP-Recall on a rig with KSP-Recall installed: I never got a firm grasp on the "Upgrade Pipeline" thingy that is what (I think at least) would do it automatically for you what I'm going to explain how to to it by "brute force":

In order to have KSP-Recall properly active on your crafts for merge, you need to  load and save every parcel craft first to make sure everyone has the PartModules installed, configured and active. Once everything has KSP-Recall's PartModules working, your merges will succeed. You need to do it only one time, by the way. Thanks Kraken.  

This is also needed with SubAssemblies. Craft Manager is on the rescue here, it allows you to load an Assembly as it was a ordinary craft and once the thing is loaded, KSP-Recall is injected on it and you can save the SubAssemblies back to the filename.

Danger, Will Robinson, Danger!! Technical Gobbledygook below!

  Reveal hidden contents

TweakScale is not at fault at all. The problem is KSP's Editor, and the problem is detailed on my post above.

What's happening is that Editor is resetting the attachment nodes outside the PartModule's Life Cycle, making it impossible to overcome the problem in a clean way.

In the past, TweakScale was brute forcing its way on the problem, what worked - but ended up doing to 3rd parties what Editor did to Editor, and in a equally unmanageable way,

 KSP-Recall was born to solve this (and some others) problems on a more 3rd-party friendly way. Being run pretty early on the PartModule's Life Cycle, it has a chance of detecting and working around the problem before most Add'Ons can get hit by it (it's the reason it has "999_" on the name, to induce KSP to load it before common add'ons!!).

However, the damned thing must be installed, configured and active on the crafts in order to work. So KSP-Recall smartly detects when an pre-Recall craft file is being loaded and reconfigure itself, saving the day.

But merging crafts (and sub-assemblies) are a completely different beast, with things being made out of the PartModule's Life Cycle again. And this time I didn't found a workaround - the ideal solution is, probably, writing a proper KSP Upgrade Pipeline tool that would properly inject KSP-Recall on existing crafts - I say "probably" because this thing is executed after the OnLoad and before the first Update and I never managed to figure out exactly when. So I can't say for sure if this will work before trying it - and, as I mentioned before, I didn't managed to cut my teeth on it yet.

 

Thank you for your reply, I have just tried it and found that the problem was not resolved.

I did the following operations.
Re-created and saved both crafts, but still had the same problem as in the video. And I also used Craft Manager at the same time.

When I don't modify the parent part, though, the problem doesn't seem to arise.

Edited September 9, 2022 by DY_ZBX

[Lisias]

4 minutes ago, DY_ZBX said:

When I don't modify the parent part, though, the problem doesn't seem to arise.

Whoops… You may had found a missing use case on KSP-Recall...

Thanks for the feedback, I will investigate this issue ASAP. https://github.com/net-lisias-ksp/KSP-Recall/issues/56

In time: can you check what happens if the parent craft have a Variant, and when it does not?

[DY_ZBX]

59 minutes ago, Lisias said:

Whoops… You may had found a missing use case on KSP-Recall...

Thanks for the feedback, I will investigate this issue ASAP. https://github.com/net-lisias-ksp/KSP-Recall/issues/56

In time: can you check what happens if the parent craft have a Variant, and when it does not?

It is a strange phenomenon that ksp defaults to the root component only when the first component is clicked from the game. Any modification of the root part on this basis will result in a drift when the components are merged.

(Modifying the root part means modifying the last point of contact of the vessel.)

Edited September 9, 2022 by DY_ZBX

[Lisias]

2 hours ago, DY_ZBX said:

It is a strange phenomenon that ksp defaults to the root component only when the first component is clicked from the game. Any modification of the root part on this basis will result in a drift when the components are merged.

(Modifying the root part means modifying the last point of contact of the vessel.)

I'm unsure I understood you. On that vídeo you sent, this root part modification was done, right?

I will rewatch it with more attention.