Got a bug with a subassembly here

[Billу]

Tried loading a subassembly and anything attached radially goes all over the place. I got the same issue with another fully stock assembly.

V1.12.3 on Win. 10

Anyone else got this issue? Any fixes like validating files?

https://gyazo.com/a149547f77e90caf52c4acc702006158

 

[James Kerman]

Welcome to the forum @Billy, your issue has been moved from KSP Discussion to our dedicated tech support subforum.

[Billу]

Just now, James Kerman said:

Welcome to the forum @Billy, your issue has been moved from KSP Discussion to our dedicated tech support subforum.

cheers mate

[dprostock]

OMG!

About ten days ago when I picked it up I found the same problem. I reinstalled the BSP again and rechecked the last installed mods (last three months) without being able to detect where the error was coming from.
Now I confirm that it is obviously another of the problems of Bugs Space Program....

[Billу]

18 hours ago, dprostock said:

OMG!

About ten days ago when I picked it up I found the same problem. I reinstalled the BSP again and rechecked the last installed mods (last three months) without being able to detect where the error was coming from.
Now I confirm that it is obviously another of the problems of Bugs Space Program....

Maybe try using a craft file and use merge instead of a subassembly, same issue or is it gone?

[dprostock]

20 hours ago, Billу said:

Maybe try using a craft file and use merge instead of a subassembly, same issue or is it gone?

In both situations.

I design a vehicle, and I keep it on the VAB list. When I select it in blending mode to add it to a new design, what you have observed happens.

Similarly, if I save the design as "subassembly" and select it, the same thing happens. 

This also happens when I start the design to "new", bring the vehicle with its parts completely separated or stacked in the wrong way.

My impression, which at the time of saving, erroneously records the relative position of the pieces. 

I have just noticed that when at the time of design, I duplicate a set of pieces, the same mishap happens, changes the spatial positions and totally breaking the original design.
They obviously have a serious problem.

[DeadJohn]

@Billy I have encountered similar wildly shifted parts when using "merge". I thought it was related to a mod but if you are not using mods then I need to reconsider.

This thread is in the "unmodded " part of the forum. Can you confirm that you aren't using any mods?

 

[swjr-swis]

3 hours ago, DeadJohn said:

Can you confirm that you aren't using any mods?

There are obvious non-stock parts in the lower left corner of the screenshot. Not sure what mod those are from, OP will have to say.

[GlobalEnterprise]

Not op, but I've run into this issue before: this happens with some of the service bays for some reason in my game.  Preassemblies with items in a service bay freak out, and scaling service bays also has odd consequences...  I don't know if its a result of a mod/modded item (I'm definitely playing modded), but some playing around and experimentation is giving me the feeling that it's something to do with how TweakScale (if on) handles the insides of containers, as scale changes make this bug much more apparent.  I don't know for sure though, so don't hold me to this info.  I need more time to mess with it and see what items cause it in my game.  Often times though, removing a service bay and its internal components solved my issues with a preassembly.  I now just save service bays as their own little assemblies and plop em in, which works just fine most of the time (still have some issues with internal components occasionally, but again don't know what's triggering it).

[AkatsukiMana]

Hey buddy I have encountered with the exactly same problem and I tried uninstalling of the Tweakscale and only keeps the 999_Scale_Redist.dll file in the /Gamedata folder and everything seems nominal now. Hope this will also work for you.

[Lisias]

Hi! TweakScale maintainer here.

It's not a TweakScale problem. It's something on  KSP-Recall.

When I fixed a problem loading crafts that started to happen on KSP 1.9, the code somehow started to screw up the SubAssemblies and the Merge.

If you remove KSP-Recall, then these problems will start to happen on loading crafts instead- we are between a rock and a hard place here.

The problem is affecting "only" parts that have variants- I have no report (neither managed to create a craft with the problem) where this happen with a part WITHOUT ModulePartVariant.

I'm working on the problem,  but until I fix this, the only workaround is to to not use TweakScale on parts with Variants on SubAssemblies (or crafts intended to be merged).

Removing KSP-Recall will lead to further problems on TweakScale because you will lose the fixes Recall implements.

Edited February 9, 2022 by Lisias
By the Krakens, I hate autocompletes!

[Lisias]

11 hours ago, GlobalEnterprise said:

Preassemblies with items in a service bay freak out, and scaling service bays also has odd consequences... 

Humm... I wasn't aware of that one...

 

11 hours ago, GlobalEnterprise said:

 I don't know if its a result of a mod/modded item (I'm definitely playing modded), but some playing around and experimentation is giving me the feeling that it's something to do with how TweakScale (if on) handles the insides of containers, as scale changes make this bug much more apparent.  

Well... let's dig on the problem.

On KSP 1.9, something on Editor started to screw up crafts using mods that change the position of a part. It's not TweakScale (neither anyone else's) fault, it was a change on Editor. Apparently Editor is brute forcing the parts back to prefab's by some reason AFTER the craft is loaded, screwing up everybody.

When TweakScale scales a part, it needs to reposition everything attached to that part. And so, TS is the most visible victim of this problem.

Since cargo bays are intended to have things attached inside, they are the mostest visible between the most visible victims of the problem. 

I don't remember making testing with cargo bays, I will fire up a KSP 1.8 and then a KSP 1.9 (when the problem started to happen) to see what I get - as time allows.

Time is currently my worst problem- all these tests and checks takes time, and this is limiting my response time to KSP problems and bugs as they are discovered...

 

— — POST EDIT — — 

Found some time for a quick test. It's sure that only parts with Variants are being misplaced on SubAssemblies and Merge, Cargo Bays are not being affected, neither his cargo if the part does not have variants, or the part is attached to a attachment point!

For more information: https://github.com/net-lisias-ksp/KSP-Recall/issues/34

Edited February 9, 2022 by Lisias
POST EDIT

[Lisias]

On 2/8/2022 at 10:33 AM, dprostock said:

My impression, which at the time of saving, erroneously records the relative position of the pieces. 

Nope. It's happening at loading from file. Saving is ok.

The reason is KSP (since 1.9) screwing up data from the loaded crafts on Editor using prefab data, bluntly overwriting whatever is on the craft file - for some reason that I can only speculate about : I think they tried to brute-force a workaround for a problem they didn't managed to diagnose, disregarding the consequences on everybody else.

But… It's a guess.

What I know for sure is that the fix for a problem happening on OnLoad implemented on KSP-Recall, besides fixing the problem at hands, created another one while using SubAssemblies, Loading for Merge and (I just reproduced it!) using Alt-Copy when some of the affected parts uses ModulePartVariant - exactly the parts being affected by the problem on OnLoad that KSP-Recall "fixed".

I'm working on the thing right now. Until this moment, this is the current status quo:

• The problem on the Alt+Copy is fixed, and will be released on TweakScale 2.4.6.10 
  • Gave up trying to do the right thing, I will brute-force my way on the problem and then I will try to cope with the collateral effects later
    • Exactly as it was done on KSP 1.9, by the way
• The current fix implemented on KSP-Recall was short-cut, and now the work around is applied by TweakScale.
• The problem on SubAssembly were minimised, but not 100% fixed
  • There's still a borderline situation (scaled variant surfaced attached to another scaled variant attached to a part) that was fixed by Recall, but on TweakScale I still struggling to fix.
  • But it's enough for a new release, it's way less worse than what we have now.

I don't like fixing widespread problems on TweakScale, but I don't have enough time to keep doing the needed research to understand exactly how and where KSP 1.9 is screwing up things - I only managed to pinpoint when.

[belay all of that! I found a mishap of mine, I forgot to update the saved positions as the craft is edited. At least one misbehaviour was fixed by that, so I may had jumped into conclusions on all what I said above!]

— — — POST EDIT — — — 

On 2/8/2022 at 10:33 AM, dprostock said:

I have just noticed that when at the time of design, I duplicate a set of pieces, the same mishap happens, changes the spatial positions and totally breaking the original design.

Managed to understand this one just now. You probably had something like this one:

I thought this was my fault due a mishap on the AttachedOnEditor Recall workaround - but then I found this - note that only one duplicate is misbehaving, the other ones are not.

On a more thorough test, I detected that the problem is only happening when the root part of the duplicate is a Separator. I double check using another part without variant as root, and the thingy worked fine:

Again, only when the root part is a Stack Separator I managed to reproduce this misbehaviour. Other parts may misbehave the same, but until this moment, only a Separator triggered the problem. Even a Decoupler (that is pretty similar to the Separator, including using the same Module) behave fine… 

I think I revealed another problem on KSP with my code being the trigger - otherwise, my thingy would be misbehaving with any part as root, not only a few ones (I patched everything having ModulePartVariant, and some of these patched parts are working fine when root!). 

Anyone has more examples of misbehaving duplicates, SubAssemblies and Merge? Until this moment, once the problem is triggered, it is triggered consistently on these 3 situations.

Moar info on this github issue.

Edited February 10, 2022 by Lisias
belay that; post edit

[Lisias]

On 2/6/2022 at 12:52 PM, Billу said:

Tried loading a subassembly and anything attached radially goes all over the place. I got the same issue with another fully stock assembly.

Anyone else got this issue? Any fixes like validating files?

Hi @Billy. Can you send me the SubAssembly misbehaving?

I'm trying to zero-in on the parts that triggers the problem when used as root part on a SubAssembly (until now, the Stock Separators are some of them), so I can try to find a pattern and understand what's happening.

To do so, please do as follows:

1. Clear the Editor, clicking on the "New" button
2. Open the SubAssembly Menu
3. Click the SubAssembly that is borking on you.
   1. This will initialise a Craft with it on Editor, and the craft will be ok.
   2. The problem is happening only when creating a Duplicate or doing SubAssembly or Merge
4. Save the craft as "SubAssembly with Problems" or something, then send it to me using dropbox, google drive or something. Or KerbalX...

This will help me on the diagnosing process.

Thanks!

Edited February 10, 2022 by Lisias
Tyops

[DaveyJ576]

I was just about to post about this very thing and I found this thread. Here is the problem I am having with a LRV prototype (very much a WIP). The first photo is the LRV folded up the way I intended:

The next photo shows what I get after I saved it to Sub-assemblies and reloaded it. I thought I was gooning something up until I found this thread.

These are all stock parts at this point. There is some Tweakscaling here with the wheels and all three panels. I sure would like to be able to fix this. The weird thing is that not everyone seems to be having this problem. I have seen LRV creations on the BDB thread that aren't borked (at least the poster didn't say they had problems). I will say that the problem seems to be linked to scaling a part. On all of my other Sub-assemblies that don't used scaled parts they come out fine. 

[dprostock]

I'm going to upload some examples.
In the first series, I take a series of designs saved in Subassembly with a new VAB editor.
The design in question is the "Venusino III" with a number of important pieces. 
I can bring it without problems, I can re-call another design "Venusino III" without inconvenience and stack them. 

Now I'm going to perform another stack:
"Bus con frenado aerodinamico" (the third one on the list ).
At the same time I will stack the pre-design "Spider" to which I must rotate to assemble it.
It can be observed that there are no problems beyond that the cap does not add up because it is pre-armed.
Please note the piece I have selected in the second image of the next series.

New situation.
I select the design listed as "Boya FTL". 
The design is turned over to the editor with the problem, the engine, which is the root, appears separated from the rest of the body of the vehicle.
I proceed to correct by unifying the design. 
I save/re-record it, delete the VAB editor to new, and proceed to select the "Boya FTL" that brings back the same part separation problem. 

I note that all designs, those that work and those that fail, share pieces of the same mods.

[Lisias]

14 hours ago, dprostock said:

I note that all designs, those that work and those that fail, share pieces of the same mods.

THIS is what's driving me crazy! 

This test:

Was made using THE VERY SAME CRAFT, using only Stock parts. Than I Alt+Click the parts one by one to see who would misbehave and who wouldn't.

From this set, only the Stack Separator misbehave - even when it was not scaled at all!

The Decoupler working fine was a hell of a surprise for me - both the Separator and the Decoupler shares a lot of characteristics (including the Module they use for the work, ModuleDecoupler), and yet, the Decoupler works fine but the Separator borks.

The Decoupler has variants, and so was patched with AttachedOnEditor. The Separator does not have variants, so it was not patched with it. So the AttachedOnEditor is not part of the problem.

When a part works as root, you can TweakScale it or not - they will behave as well.

When a part misbehave, it misbehave no matter it's TweakScaled or not.

And since I did that extra mile to disable TweakScale when the part is not scaled (and so saving a bit of CPU juice), it's obvious that TweakScale is also not directly involved on the mess - since I know the code, I know that what's happening is that TweakScale is reading bogus data about the current position of the borking part, and then when it calculates the correct position for the scaled part attached to the borked one, the parts ends up going to Kraken knows where. The AttachedOnEditor stunt was made exactly to counter act this misbehaviour - it saves the correct position of the part on it's node on Editing time, and reapply it when you are loading the craft on Editor to counter act the mess Editor is doing nowadays.

My current working theory is that there's yet a new point where things are screwed, and this screwing point is triggered when some parts are the root of the subassembly.

I have evidence of such two screwing points because I managed to find a stock part, the NCS Adapter:

The NCS Adapter works fine on the Alt+Click, but borks when you load it from a SubAssembly! (Remember, the crafts are saved fine - the problem happens only at Loading inside the Editor).

This is not random, once I detect a borking part, this part always misbehave when used as root no matter what. So it's deterministic.

The hard work, now, is to determine what makes the NCS Adaptor and the Separators (and also some other parts as shown above) different from the majority of parts that plays well. These two are completely different parts, with different modules, with different roles - and yet, both misbehave the same once they are root on a craft loading from a SubAssembly.

This is a hell of a puzzle….

 

20 hours ago, DaveyJ576 said:

I was just about to post about this very thing and I found this thread. Here is the problem I am having with a LRV prototype (very much a WIP). The first photo is the LRV folded up the way I intended:

These are all stock parts at this point. 

Yep, you was bitten by the problem. Since you just arrived here, let me resume the mess for you:

• On KSP 1.9, something inside Editor started to shove back prefab values on parts positioning, disregarding whatever is on the craft file
  • The problem only happens when you load the craft file on Editor. If you launch it directly on LaunchPad or RunWay, the crafts launches fine.
  • The problem only affects parts that have Variants.
• Since TweakScale reposition the scaled parts (for obvious reasons), TweakScale was victim of the problem.
• Initially I had brute forced by way on TweakScale, but that was starting to cause me problems - I was never sure when something wrong was happening due a bug on TweakScale core business, or from something else that was being screwed up by the TweakScale's "gambiarra"
• When the SubAssembly, Load on Merge and Alt+Click problems started to happen, trying to handle them on TweakScale started to cause problems on TweakScale itself on my test beds - so I created AttachedOnEditor to fix the problem on the right place and remove TweakScale from the crossfire.
  • By doing that, I also created a way to fix the problem for any other Add'On that would need it - instead of forcing people to use TweakScale to have the problem handled.
• What you are seeing on this thread is the disclosure of my findings while trying to nail this Kraken damned Editor misbehaviour.

 

20 hours ago, DaveyJ576 said:

There is some Tweakscaling here with the wheels and all three panels. I sure would like to be able to fix this. The weird thing is that not everyone seems to be having this problem. I have seen LRV creations on the BDB thread that aren't borked (at least the poster didn't say they had problems). I will say that the problem seems to be linked to scaling a part. On all of my other Sub-assemblies that don't used scaled parts they come out fine. 

To tell you the true, this should affect somehow every add'on that by some reason changes the part's position - TweakScale ends up being one of the most used add'ons that do that, so it ends up having a bigger exposition to the problem.

And, just to be clear, the problem only happens when you load the craft inside the Editor. When you launch the craft directly into the LaunchPad or Runway, the problem doesn't manifests.

Now, about this problem specifically:

It looks like this other one that I reproduced and fixed today:

Spoiler

(See https://github.com/net-lisias-ksp/KSP-Recall/issues/34 for the gory details!)

This one was my fault: I forgot to update the parts' position when saving the craft on AttachedOnEditor.  So, as you edit the part, the AttachedOnEditor insists on restoring to the last known position - and since this last known position was never being updated after you created the part, AttachedOnEditor was moving the part to the wrong place. 

Well, I'm finalizing a minor release for KSP-Recall today, by the morning at least this problem should be fixed for you once you update KSP-Recall.

 

14 hours ago, dprostock said:

I'm going to upload some examples.

<….>

So, just be sure, on the borking situations, the root part was the  DS "Thunder" Kerbstein Rocket Nose, I'm right?

From what Add'On is this part, it's KSP Interstellar Extended?

Edited February 11, 2022 by Lisias
tyops as usulla… and entertaining grammars! :D

[dprostock]

My list:

Spoiler

[x] Science! Continued (xScienceContinued 6.0.0.9)
ABookCase Orbital Reference System (ABCORS 0.5.1.5)
Astronomer's Visual Pack (AstronomersVisualPack 3:v4.11)
Astronomer's Visual Pack-8k Textures (AVP-8kTextures v1.12)
AT Utils (AT-Utils v1.9.6)
B9 Part Switch (B9PartSwitch v2.19.0)
Breaking Ground (BreakingGround-DLC 1.7.1)
Chatterer (Chatterer 0.9.99)
Chatterer Extended (ChattererExtended 0.6.2)
ClickThrough Blocker (ClickThroughBlocker 1:0.1.10.17)
Community Category Kit (CommunityCategoryKit v5.2.0.0)
Community Resource Pack (CommunityResourcePack 1.4.2)
Distant Object Enhancement /L (DistantObject v2.1.1.6)
Distant Object Enhancement /L default config (DistantObject-default v2.1.1.6)
Dock Rotate (DockRotate v1.12.1.55)
Easy Vessel Switch (EVS) (EasyVesselSwitch 2.3)
Engine Lighting Relit (EngineLightRelit 1.6.3.2)
Environmental Visual Enhancements Redux (EnvironmentalVisualEnhancements 3:1.11.6.1)
Final Frontier (FinalFrontier 1.10.0-3485)
FTL Drive Continued (FTLDriveContinued 0.2.3.2)
Hangar Extender (HangerExtenderExtended 3.6.0.2)
IndicatorLights (IndicatorLights 1.8.1)
IndicatorLights Community Extensions (IndicatorLightsCommunityExtensions 1.6.2)
Kalculator (Kalculator 0.2.3)
Keep It Straight (KeepItStraight 1.4.0)
Kerbal Alarm Clock (KerbalAlarmClock v3.13.0.0)
Kerbal Attachment System (KAS 1.10)
Kerbal Engineer Redux (KerbalEngineerRedux 1.1.9.0)
Kerbal Inventory System (KIS 1.29)
Kerbal Joint Reinforcement - Next (KerbalJointReinforcementNext v4.1.15)
Kerbal Reusability Expansion (SpaceXLegs 2.9.2)
KSP Recall (KSP-Recall v0.2.1.3)
Making History (MakingHistory-DLC 1.12.1)
MastodonPatch (MastodonPatch v0.0.0.1)
MechJeb 2 (MechJeb2 2.12.3.0)
Mk2 Stockalike Expansion (Mk2Expansion 2:1.9.1.2)
Mk3 Stockalike Expansion (Mk3Expansion 1.6.1.3)
Module Manager (ModuleManager 4.2.1)
MSP-3000 Material Science Pod (MSP3000 v1.1)
Near Future Construction (NearFutureConstruction 1.3.1)
Near Future IVA Props (NearFutureProps 1:0.7.1)
Near Future Solar (NearFutureSolar 1.3.2)
Near Future Solar Core (NearFutureSolar-Core 1.3.2)
Near Future Spacecraft (NearFutureSpacecraft 1.4.3)
Planet Wiki (PlanetWiki 1:4.1)
PlanetShine (PlanetShine 0.2.6.3)
PlanetShine - Default configuration (PlanetShine-Config-Default 0.2.6.3)
QuickCursorHider (QuickCursorHider 1:1.1.0.7)
RasterPropMonitor (RasterPropMonitor 1:v0.31.6)
RasterPropMonitor Core (RasterPropMonitor-Core 1:v0.31.6)
ReStock (ReStock 1.4.2)
ReStock Extra - Rigid Legs (RestockRigidLegs 1.4.2)
ReStock+ (ReStockPlus 1.4.2)
SCANsat (SCANsat v20.4)
scatterer (Scatterer 3:v0.0831)
Scatterer Default Config (Scatterer-config 3:v0.0831)
Scatterer Sunflare (Scatterer-sunflare 3:v0.0831)
Science - Full Reward! (Continued) (Science-Full-Reward v5.2)
Science - Full Transmit! (Science-Full-Transmit v1.1)
ScienceAlert ReAlerted (ScienceAlert 1.9.10)
Show FPS (ShowFPS 1:0.3.1)
SimpleFuelSwitch (SimpleFuelSwitch 1.4)
SpaceTux Library (SpaceTuxLibrary 0.0.8.4)
Stock Waterfall Effects (StockWaterfallEffects 0.6.3)
Stockalike Station Parts Expansion Redux (StationPartsExpansionRedux 2.0.6)
Surface Mounted Lights (surfacelights 1.19)
TAC Fuel Balancer (TacFuelBalancer v2.21.5.2)
TextureReplacer (TextureReplacer v4.5.3)
The Janitor's Closet (JanitorsCloset 0.3.7.8)
Throttle Controlled Avionics (ThrottleControlledAvionics v3.7.2)
Toolbar (Toolbar 1:1.8.0.7)
Toolbar Controller (ToolbarController 1:0.1.9.6)
Tracking Station Evolved (TrackingStationEvolved 7.0)
Trajectories (Trajectories v2.4.3)
Transfer Window Planner (TransferWindowPlanner v1.7.2.0)
TweakScale - Rescale Everything! (TweakScale v2.4.6.8)
Utility Weight (UtilityWeight 2.0.0)
VaporVent (VaporVent 1.1.12)
Waterfall - Restock (WaterfallRestock 0.2.3)
Waterfall Core (Waterfall 0.8.1)
Zero MiniAVC (ZeroMiniAVC 1:1.1.2.4)
 

and 

DanGerous Systems 0.2  ( Manual Install ) 

 

 

If the designs (ships) are needed, they will notify me and we will see how I send them. ( Kedex  )

[Lisias]

6 minutes ago, dprostock said:

If the designs (ships) are needed, they will notify me and we will see how I send them. ( Kedex  )

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

[dprostock]

5 hours ago, Lisias said:

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

Executing.

[DaveyJ576]

@Lisias, I downloaded your patch and you have made progress. I can now load my LRV prototype from the Sub-assembly in either the SPH or the VAB without it being borked. However, if I try to combine it with another craft, like my Lunar Module, it still comes out messed up. I load the sub-assembly for the LM, then bring up the LRV to try to attach it to the proper spot on the LM and the LRV comes out of the sub-assembly rearranged.

First photo is the LRV right out of the sub-assembly as it should be:

 

Second photo is how it comes out when trying to connect it to my LM:

Obviously not how it should be. Can you suggest a work around? Thanks!

[Lisias]

55 minutes ago, DaveyJ576 said:

Obviously not how it should be. Can you suggest a work around? Thanks!

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

[Lisias]

16 hours ago, DaveyJ576 said:

Obviously not how it should be. Can you suggest a work around? Thanks!

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

[Lisias]

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.

 

[kspkat]

I don't mean to gravedig a thread but I had this exact same issue, I pull out a subassembly and half the rocket parts are far away from the other half.

I found a fix / temporary workaround for now. I am not sure what the side-effects are, so far I can't tell. You should have both TweakScale and KSPRecall installed.

GameData\999_KSP-Recall\KSP-Recall.cfg change the following:

Quote

@AttachedOnEditor:NEEDS[KSPRECALL-ATTACHED-ON-EDITOR] = true

to:

Quote

@AttachedOnEditor:NEEDS[KSPRECALL-ATTACHED-ON-EDITOR] = false

This will automatically turn off the option "KSP-Recall::AttachedOnEdit" in game (found by right clicking part)

I was forever manually turning this option off and it was tedious but every single time it fixed the subassembly issue so I kept on doing it. I am unsure what side effects will occur so do so at your own risk! Also it'd be a good idea to remember this change in case of future problems.

Now it should automatically turn this option off, thereby fixing the problem (again, at the cost of unknown side effects) As this is a config option it should be reversible.