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

[Lisias]

46 minutes ago, linuxgurugamer said:

@Lisias

Question about docking ports.  I'm having a problem getting a couple of SpaceY docking port to connect, they are the 7.5m scaled up to 10m.

Does Tweakscale adjust any of the internal parameters, such as the acquireForce, acquireRange, nodetype, etc?

If the part uses a Stock PartModule, the module is handled by TweakScale using the default ScaleExponents. About the Docking Node, the values are:

TWEAKSCALEEXPONENTS
{
	name = ModuleDockingNode
	undockEjectionForce = 2
	acquireForce = 2
	acquireTorque = 2
}

Data from the Parts are handled by another, specific Exponent.

There's something you think should be scaled and it's not?

— — POST EDIT — — 

Yep, there're some missing attributes from the default Exponent for the ModuleDockingNode!

There's already an issue for it:

https://github.com/net-lisias-ksp/TweakScale/issues/270

And… scaling the nodeType will be a challenge...

So, in a nutshell, scaling the Docking Parts are problematic for now on KSP 1.12...

Edited January 30, 2023 by Lisias
post edit.

[SeniLiX]

I got 60 of this kind of error:

[TweakScale] ERROR: **FATAL** Part LiquidEngineKE-1 (Kerbodyne KE-1 "Mastodon" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

After some research I figured it's because tweakscale attempts to apply itselt to a part and it fails. 

Question:

Would it be possible to have tweakscale just skip over these parts instead? I know that would mean you would not be able to use tweakscale on these specific parts, but I am running with a large list of parts mods and would be perfectly fine to run without these.

For good measure, here is a link to the full log:

https://www.dropbox.com/s/8lvm90o07dy7dnr/KSP.log?dl=0

 

[AccidentalDisassembly]

12 hours ago, Lisias said:

If the part uses a Stock PartModule, the module is handled by TweakScale using the default ScaleExponents. About the Docking Node, the values are:

TWEAKSCALEEXPONENTS
{
	name = ModuleDockingNode
	undockEjectionForce = 2
	acquireForce = 2
	acquireTorque = 2
}

Data from the Parts are handled by another, specific Exponent.

There's something you think should be scaled and it's not?

— — POST EDIT — — 

Yep, there're some missing attributes from the default Exponent for the ModuleDockingNode!

There's already an issue for it:

https://github.com/net-lisias-ksp/TweakScale/issues/270

And… scaling the nodeType will be a challenge...

So, in a nutshell, scaling the Docking Parts are problematic for now on KSP 1.12...

One word of caution on the nodeType - mods like KSTS seem to use the nodeType defined in a part's config (maybe even as a string value or something) to determine what kinds of vessels can interact, so if a 3.75m docking port got scaled down to 2.5m and the intended behavior is to be able to dock with 2.5m ports, it would need to acquire the nodeType of the 2.5m ports and lose all others, I think... But not totally sure. Not sure what you might do with intermediate sizes other than disallow them...

[Lisias]

7 hours ago, AccidentalDisassembly said:

One word of caution on the nodeType - mods like KSTS seem to use the nodeType defined in a part's config (maybe even as a string value or something) to determine what kinds of vessels can interact, so if a 3.75m docking port got scaled down to 2.5m and the intended behavior is to be able to dock with 2.5m ports, it would need to acquire the nodeType of the 2.5m ports and lose all others, I think... But not totally sure. Not sure what you might do with intermediate sizes other than disallow them...

I'm planning to do what it's already being done with attachment nodes: scale it to the nearest size. Obviously, subject to further considerations.

 

8 hours ago, SeniLiX said:

I got 60 of this kind of error:

[TweakScale] ERROR: **FATAL** Part LiquidEngineKE-1 (Kerbodyne KE-1 "Mastodon" Liquid Fuel Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

After some research I figured it's because tweakscale attempts to apply itselt to a part and it fails. 

No, you concluded wrongly. By analysing your KSP.log, I found that TweakScale patched the part only once.

The problem is that you have a deprecated add'on installed, remove GameData/TweakScaleMakingHistoryConfigs and things will be fine:

[LOG 00:54:57.329] Applying update TweakscaleMakingHistoryConfigs/Coupling/@PART[Decoupler_1p5] to SquadExpansion/MakingHistory/Parts/Coupling/Decoupler_1p5.cfg/PART[Decoupler_1p5]

 

9 hours ago, SeniLiX said:

Question:

Would it be possible to have tweakscale just skip over these parts instead? I know that would mean you would not be able to use tweakscale on these specific parts, but I am running with a large list of parts mods and would be perfectly fine to run without these.

Yes, it's "possible".  But this was what cause so much trouble in 2019 on. my first year of tenure on TweakScale, so I won't do it. (and that's final).

Double patching is terrible, it leads to confusions both on TweakScale as with KSP itself, as some PartModules doesn't cope too well with reindexings on the this.part.Modules, what can screw you whatever you use the affected parts or not. I had to deactivate features from TweakScale due this.

So, in a nutshell: had I been allowing it, you would be using deprecated and unreliable patching with patches that are missing new attributes being added to parts since KSP 1.7 or 1.6 - not to mention possible misbehaviours on 3rd parties or KSP as explained by the issue I linked above.

As a personal note, if you can live without some broken parts, my best suggestion is to remove them from the game instead of risking contaminating your gaming with problems that may or may not lead to game corruption by things beyound our control. Lots and lots of people had lost their savegames in the past because of this.

note to myself: https://github.com/KSP-CKAN/NetKAN/pull/9544

[SeniLiX]

Thank you very much for your help @Lisias in finding the culprit. It fixed it!

Only thing now is it says it found 6 parts which failed a sanity check, but I assume that has already been looked in to and shouldn't cause any concern.

I like that you are also going to mark the "TweakScaleMakingHistoryConfigs" as conflicting in CKAN, it would surely help preventing others from making the same mistake as I did.

Thanks again  

[Lisias]

2 hours ago, SeniLiX said:

Thank you very much for your help @Lisias in finding the culprit. It fixed it!

Only thing now is it says it found 6 parts which failed a sanity check, but I assume that has already been looked in to and shouldn't cause any concern.

I like that you are also going to mark the "TweakScaleMakingHistoryConfigs" as conflicting in CKAN, it would surely help preventing others from making the same mistake as I did.

Thanks again  

Welcome!

Do you have firespitter installed? If yes, download and install the TweakScale Companion ÜberPaket, it will install TS support for it (and some others).

 

[henrylzy]

On 1.12.5, TS(2.4.6.21) seems to break(or displace certain parts) crafts while merging in the editor.

It happened between Jan. 29th and Jan. 30th as Steam updated KSP for a minor fix, as well as TS was updated to 2.4.6.21.

Here's what happened when I merge the launch platform to a shuttle orbiter.

The root for the platform was the bipod that connects the fuel tank with the orbitor. However if I merge the original craft file for the SOCK's shuttle orbiter provided by Modular Launch Platform, everything works fine.

If I load up the platform first then merge the orbiter, the same thing happens as the engines would appears inside the cockpit.

 

Another thing is that changing the view in the editor or moving the orginal craft around actually affect this displacement, and it's always the SRBs and the tail holder that moves, while other parts were staying where they should be.

 

To rule out conflicts, I left only essential mods in GameData folder as shown below. All mods were freshly installed for this test.

 

Except Recall, everything I kept was either mods or dependencies for SOCK, BDB, Habtech2 and Modular Launch Pad.

 

Here's my step to recreate the issue

1. Load KSP with mods above, as well as TS which is not shown in the screenshot above.

2. Load the craft file provided by Modular Launch Pad

3. Reroot to the bipod that connects the tank and the orbiter

4. Dettach the orbiter and save the rest as a new craft

5. Attach the orbiter back, reroot to the cockpit, then remove the pad from the bipod and save the orbiter as a new craft

6. Merge the launch pad from the craft file saved in step 4

 

 

[Lisias]

3 hours ago, henrylzy said:

Here's my step to recreate the issue

1. Load KSP with mods above, as well as TS which is not shown in the screenshot above.

2. Load the craft file provided by Modular Launch Pad

3. Reroot to the bipod that connects the tank and the orbiter

4. Dettach the orbiter and save the rest as a new craft

5. Attach the orbiter back, reroot to the cockpit, then remove the pad from the bipod and save the orbiter as a new craft

6. Merge the launch pad from the craft file saved in step 4

That's unfortunate, to say the least. Doesn't looks exactly as a TweakScale bug, because I could not reproduce the problem.

Well.. First things first. I tried to reproduce the problem on a clean KSP 1.12.5 first, to rule out 3rd party influences.

So I fired my "ACP" KSP test rig, with KSP 1.12.5 and the latest releases of Forum's Module Manager, TweakScale and some other Add'Ons I publish on Forum. If this is a inherent TweakScale mibehaviour, I would be able to reproduce it on this rig.

So I fired up a new SandBox game, gone to VAB and :

1. loaded the Stock craft Dynawing - a somewhat similar Stock craft to the one you used.
2. Activated Chain Scale and Auto Scale on TweakScale's settings.
3. Scale up the root part (the MK3 Cockpit) to 5m
   1. Nothing wrong happend.
4. Saved the craft and load it back
   1. Nothing wrong happened
5. Now I rerooted the craft into the Mk3 Cargo bay where the Hydraulic Detachment Manifold is plugged into
   1. Nothing wrong happened
6. Now I rerooted the craft into the Kerbodyne S3-14400 fuel tank
   1. Nothing wrong happened
7. I tried to reroot into the Hydraulic Manifold itself, but Editor didn't allowed.
8. Saved and Loaded the craft a bunch of times while rerooting the thing into different parts.
   1. Nothing wrong happened
9. Then I removed the boosters+tank from it, saved it Shuttle as Craft A
10. Reloaded the original craft. rerooted and removed the Shuttle from it, and saved as Craft B
11. Loaded the Craft A, then injected the Craft B as subassembly into it, rebuilding the original craft.
    1. And got royally screwed by AutoScale!!!  
12. So I tried again, but deactivating the AutoScale and Chain Scale from TS.
    1. Nothing wrong happened. Even the EAS struts reconnected to where they were.

So this rules out TweakScale as being the cause of the problem. If it works on Stock, anything wrong on your rig is being caused by something else - where TweakScale can be, at worst, involved on the problem somehow.

I will install Modular Launch Pads and try the same tests using the craft you mentioned. I will edit this post with my findings.

 

3 hours ago, henrylzy said:

It happened between Jan. 29th and Jan. 30th as Steam updated KSP for a minor fix, as well as TS was updated to 2.4.6.21.

Uh… Steam doesn't updates add'ons, and the last release for KSP is from January 11, just checked the SteamDB for the Manifests.

I think you are meaning CurseInstaller or CKAN, right?
 

— — POST EDIT — — 

I forgot to test merging the subassembly. Edited the steps above.  No change on the results.

Edited February 1, 2023 by Lisias
POST EDIT

[AlonzoTG]

damn mod has broken most of my entire collection dating back to 2014.... 

It seems to breaking specific parts, all of which are stock: 

 

-> stock decouplers.

-> stock probe cores.

-> stock trusses

-> stock antennas. 

 

No other parts are affected. =| 

All spawn at 20M scale.   (SRSLY??????) 

Workaround is to manually edit the craft file and remove tweakscale module. 

[Lisias]

8 minutes ago, AlonzoTG said:

damn mod has broken most of my entire collection dating back to 2014.... 

It seems to breaking specific parts, all of which are stock: 

 

-> stock decouplers.

-> stock probe cores.

-> stock trusses

-> stock antennas. 

 

No other parts are affected. =| 

All spawn at 20M scale.   (SRSLY??????) 

Workaround is to manually edit the craft file and remove tweakscale module. 

I need your KSP.log in order to try to check this. This is not TweakScale normal behaviour (of course), and this wasn't happened on any of my test beds.

It's more likely a 3rd party interaction than anything else.

What you describe may happen when someone screw up the default patches badly, confusing TweakScale into rescale the parts using a bogus defaultScale.

[henrylzy]

16 minutes ago, Lisias said:

That's unfortunate, to say the least. Doesn't looks exactly as a TweakScale bug, because I could not reproduce the problem.

Well.. First things first. I tried to reproduce the problem on a clean KSP 1.12.5 first, to rule out 3rd party influences.

So I fired my "ACP" KSP test rig, with KSP 1.12.5 and the latest releases of Forum's Module Manager, TweakScale and some other Add'Ons I publish on Forum. If this is a inherent TweakScale mibehaviour, I would be able to reproduce it on this rig.

So I fired up a new SandBox game, gone to VAB and :

1. loaded the Stock craft Dynawing - a somewhat similar Stock craft to the one you used.
2. Activated Chain Scale and Auto Scale on TweakScale's settings.
3. Scale up the root part (the MK3 Cockpit) to 5m
   1. Nothing wrong happend.
4. Saved the craft and load it back
   1. Nothing wrong happened
5. Now I rerooted the craft into the Mk3 Cargo bay where the Hydraulic Detachment Manifold is plugged into
   1. Nothing wrong happened
6. Now I rerooted the craft into the Kerbodyne S3-14400 fuel tank
   1. Nothing wrong happened
7. I tried to reroot into the Hydraulic Manifold itself, but Editor didn't allowed.
8. Saved and Loaded the craft a bunch of times while rerooting the thing into different parts.
   1. Nothing wrong happened

So this rules out TweakScale as being the cause of the problem. If it works on Stock, anything wrong on your rig is being caused by something else - where TweakScale can be, at worst, involved on the problem somehow.

I will install Modular Launch Pads and try the same tests using the craft you mentioned. I will edit this post with my findings.

 

Uh… Steam doesn't updates add'ons, and the last release for KSP is from January 11, just checked the SteamDB for the Manifests.

I think you are meaning CurseInstaller or CKAN, right?

Steam did update game itself(not mods) somewhere between the 29th and 30th for me, for the launcher update released on Jan. 26(tbh I don't know why it wasn't done until 3-4 days later), and I don't think that's the issue here.

And an update to the issue, I got the problem solved and I have no idea why.

Long story short, saving the crafts again with TS 2.4.6.19 and Recall 0.3.0.8 solved the issue. Not sure whether TS or Recall caused it for me though, and it's weird since I was testing on a clean KSP 1.12.5 as well.

 

I was so sure it was caused by TS because once I remove TS from KSP, problem solved.

So I tried to revert TS back to 2.4.6.19 but still not works, and it should since I was using it for a while without any issue.

Then I tried to revert all other mods back to older versions, then I realized that all other mods were the same version before this issue occured, except Recall.

I ran the game with TS version 2.4.6.19 and Recal 0.3.0.8, load the orbiter, then merge the pad to it, still not working.

Then, somehow I think I should save both craft again for no reason at all, and I did, then problem solved.

[Lisias]

7 minutes ago, henrylzy said:

Long story short, saving the crafts again with TS 2.4.6.19 and Recall 0.3.0.8 solved the issue. Not sure whether TS or Recall caused it for me though, and it's weird since I was testing on a clean KSP 1.12.5 as well.

Damn it, you confirmed my initial guess. B9PS apparently needs KSP-Recall in order to work together TweakScale.

I recently removed Recall from parts with B9PS due potential conflicts a user reported, but as it appears, it's better to keep B9PS under Recall's unbrella - a potential conflict is better than a carnage like this.

[Lisias]

On 2/1/2023 at 5:42 PM, AlonzoTG said:

damn mod has broken most of my entire collection dating back to 2014.... 

It seems to breaking specific parts, all of which are stock: 

 

-> stock decouplers.

-> stock probe cores.

-> stock trusses

-> stock antennas. 

 

No other parts are affected. =| 

All spawn at 20M scale.   (SRSLY??????) 

Workaround is to manually edit the craft file and remove tweakscale module. 

Sir, I managed to reproduce this misbehaviour by intentionally screwing up the default TweakScale patches. It's old knowledge, to tell the true, these things are happening since forever - people installs crappy patches on the the rig, and then blame TweakScale for doing what's it is expected to do: to scaling things using the patches applied.

Your problem is not this "damn mod". The problem is the damn crappy patches you installed on your rig, and I strongly suggest you start considering carefully about restricting yourself from installing things on it without the proper care.

I also suggest you to consider a good Backup practice - you stating that you had "fixed" the problem by manually editing the crafts leads to the conclusion you don't do backups at all (otherwise you won't had to edit them, a simple restore from the most recent backups would had done the job).

I have almost 5 years of historical records of TweakScale, carefully documenting all the problems (including my own's) and anyone caring to read all that krap will eventually conclude what follows: about 80 to 90% of all support tickets are due something else screwing up things, and TweakScale is the one calling about the problem, not causing it.

I understand your anger and frustration, this was exactly the reason I choose to adopt TweakScale at first place:

It took me almost a year to correctly identify and workaround all the issues that leaded to this problem. From bad patches inducing TweakScale to calculate Zero on some part's mass (making them "stuck" on the 3D world, and everything attached to it started to blow up due the stress) to double patching, confusing TweakScale in using the wrong patch set on a time where the KSP Upgrade Pipeline didn't existed yet - you name it.

(I still have that savegame, by the way - I think I will be able to retake that one still this year!  )

I had my bad moments, no doubt - but on the absolutely majority of the time, the source of the bugs were, and still are, tracked down into 3rd parties' misbehaviours or problems on their artefacts.

I suggest you to take a deep breath, calm down and then bear with me in order to diagnose the problem that screwed you. There's a very high chance that whatever had screwed you will screw up someone else again, and it's better for both of us to diagnose it and to have a fix for it as soon as possible.

Please send me your KSP.log where the problem was reproduced - make a full backup of the thing as a disposable copy, install TweakScale back on the disposable copy and then when things go south, quit KSP and send me a screwed craft file and the full KSP.log (please send the KSP.log, not the Player.log - this one is almost useless to me).

Good luck.

— — POST EDIT — — 

A series of intensive testes (see the posts below) revealed that, this time, the problem is another completely different.

It's uncertain if this is really TweakScale's fault, but it's not ruled out neither. This is a very weird one.

Edited February 3, 2023 by Lisias
POST EDIT

[starfall22]

5 hours ago, Lisias said:

I need your KSP.log in order to try to check this. This is not TweakScale normal behaviour (of course), and this wasn't happened on any of my test beds.

It's more likely a 3rd party interaction than anything else.

What you describe may happen when someone screw up the default patches badly, confusing TweakScale into rescale the parts using a bogus defaultScale.

Funny, i updated my tweakscale from the older version... Pellinors, and i have the same issue. Though your mod did warn me of some gamebreaking things being detected, after which i removed all tweakscale, fuel switch and interstellar extended, or whatever those were, and reinstalled everything. Hoping that would possibly fix things. Since the log file was the size of one of those gigantic trusses, i abandoned the thought of pasting it into pastebin and ask here about it. Anyways, launching the game without the notification this time, i checked on the things, they were still HUGE... Funny how one of my satellites ended up being a giant frame weighing 32 000 tons, with the main pieces of the satellite safely inside in the middle of the thing. So anyways, im reinstalling my whole modlist right now, but on the off chance that this doesnt work, i guess what i wanted to say is that... I HAVE THE SAME ISSUE!!!
Im not sure what the log file would give but its too big to be pasted to pastebin. If you want to see my logs, im afraid you are going to have to reccomend me a substitute where i could paste a txt file with the size of... 9 MEGABYTES??? dear god. I remember times when there were games that took less room
Well, anyways... if you know of a place, let me know and ill upload it. If you wish i can send you my save files as well. This bug still did explode my rover and rocket on the mun  The latter has debris flying away from the mun on escape trajectory
Just for the heck of it, here is what my satellite looked like, just to get the visual idea

I nosed through some of the logs presented... i think this is something that is interesting... the numbers the truss is changed TO seems correct, but why was it saved as 50.000 before? Anyways, any ideas how to fix this? Cause tweakscale does it to any save from any time. Something in this update process got messed up big, so the 40 saves that i have are no good, cause the issues persist with the fresh install and i am unsure if i can restore my mod folder to previous state. As i dont think i should eventry , since using the old version was not a good idea to begin with.

 [WRN 03:14:01.300] [KSPCF:ModuleIndexingMismatch] Part "trussPiece1x" configuration has changed. Synchronizing persisted modules...
[LOG 03:14:01.300] [TweakScale] WARNING: Upgrading ScaleType! Craft 4288766914 had the part trussPiece1x:FFDD6052 scaling changed from (TweakScale: default=100.000, current=50.000) to (stack: default=0.625, current=0.313)
[LOG 03:14:01.300] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[WRN 03:14:01.325] [KSPCF:ModuleIndexingMismatch] Module "AttachedOnEditor" at index [3] doesn't exist in the persisted part, a new instance will be created
[WRN 03:14:01.328] [KSPCF:ModuleIndexingMismatch] Part "roverWheel1" configuration has changed. Synchronizing persisted modules...
[LOG 03:14:01.329] [TweakScale] WARNING: Upgrading ScaleType! Craft 4288764160 had the part roverWheel1:FFDD6010 scaling changed from (TweakScale: default=100.000, current=100.000) to (free: default=100.000, current=100.000)

Edited February 2, 2023 by starfall22
additional info

[Lisias]

42 minutes ago, starfall22 said:

Funny, i updated my tweakscale from the older version... Pellinors, and i have the same issue. Though your mod did warn me of some gamebreaking things being detected, after which i removed all tweakscale, fuel switch and interstellar extended, or whatever those were, and reinstalled everything. Hoping that would possibly fix things. Since the log file was the size of one of those gigantic trusses, i abandoned the thought of pasting it into pastebin and ask here about it. Anyways, launching the game without the notification this time, i checked on the things, they were still HUGE... Funny how one of my satellites ended up being a giant frame weighing 32 000 tons, with the main pieces of the satellite safely inside in the middle of the thing. So anyways, im reinstalling my whole modlist right now, but on the off chance that this doesnt work, i guess what i wanted to say is that... I HAVE THE SAME ISSUE!!!

Damn. There's something happening on the field, and I don't have the slightest idea what at this moment.

I can rule out Auto Scale and Chain Scale being wrongly triggered on Flight Scene as these things are handled by events that only happen on Editor. There's no way (known to me at least) that these features would be triggered on Flight Scene.

Borked patches are a known way to cause these problems, and I could easily craft a patch to do this kind of damaged on my test bed. So I think I know what is happening, but I don't know why it's happening.

And since you reproduce the problem using an old release of TweakScale, not to mention that newer TweakScale had given you a Warning about something fishy, I think that what remains to be known is who is applying these patches.

 

55 minutes ago, starfall22 said:

Im not sure what the log file would give but its too big to be pasted to pastebin. If you want to see my logs, im afraid you are going to have to reccomend me a substitute where i could paste a txt file with the size of... 9 MEGABYTES??? dear god. I remember times when there were games that took less room
Well, anyways... if you know of a place, let me know and ill upload it. If you wish i can send you my save files as well. This bug still did explode my rover and rocket on the mun  The latter has debris flying away from the mun on escape trajectory
Just for the heck of it, here is what my satellite looked like, just to get the visual idea

Please send your KSP.log (you will find it on the same place where the KSP's exe file is!) using dropbox, google drive or by dragging it on a post on this issue on Github (you will need a github account for it). I would suggest you to zip the thing first!

If you can find the ModuleManager.ConfigCache file (directly into your GameData directory) and the ModuleManager's logs (into <where_you_ksp_exe_is>/Logs/ModuleManager) they may be of help if the KSP.log doesn't have all the data I need (i.e., the patches were being loaded from the ConfigCache).

 

[starfall22]

14 minutes ago, Lisias said:

Damn. There's something happening on the field, and I don't have the slightest idea what at this moment.

I can rule out Auto Scale and Chain Scale being wrongly triggered on Flight Scene as these things are handled by events that only happen on Editor. There's no way (known to me at least) that these features would be triggered on Flight Scene.

Borked patches are a known way to cause these problems, and I could easily craft a patch to do this kind of damaged on my test bed. So I think I know what is happening, but I don't know why it's happening.

And since you reproduce the problem using an old release of TweakScale, not to mention that newer TweakScale had given you a Warning about something fishy, I think that what remains to be known is who is applying these patches.

 

Please send your KSP.log (you will find it on the same place where the KSP's exe file is!) using dropbox, google drive or by dragging it on a post on this issue on Github (you will need a github account for it). I would suggest you to zip the thing first!

If you can find the ModuleManager.ConfigCache file (directly into your GameData directory) and the ModuleManager's logs (into <where_you_ksp_exe_is>/Logs/ModuleManager) they may be of help if the KSP.log doesn't have all the data I need (i.e., the patches were being loaded from the ConfigCache).

 

actually the problem appeared after updating from the old tweakscale to your version. What makes it act this way, i have no clue.
Anyways, here is the file for all the stuff gamedata (not the mods, just the dll-s cfg-s and configcache with the rest of the module manager things.) along with the log the size of godzilla. https://drive.google.com/file/d/1Nkqu4oWxRHvsfhfJKj1w8WKtUxps_OW_/view?usp=sharing

Ah, here is the save after the update (persistant) and the quicksave1 is from before the update... idk, if they can be of any use.
https://drive.google.com/file/d/1zHbLAZnX93vCW9Wh6rb3w8I__FmhwMKE/view?usp=sharing

Edited February 2, 2023 by starfall22
addition of info

[Lisias]

1 hour ago, starfall22 said:

actually the problem appeared after updating from the old tweakscale to your version. What makes it act this way, i have no clue.
Anyways, here is the file for all the stuff gamedata (not the mods, just the dll-s cfg-s and configcache with the rest of the module manager things.) along with the log the size of godzilla. https://drive.google.com/file/d/1Nkqu4oWxRHvsfhfJKj1w8WKtUxps_OW_/view?usp=sharing

Well, the blown up part in your screenshot is the "strutCube" (internal KSP name for the "Cubic Octagonal Strut"). So I gone through a fishing expedition on your logs. Found this:

[WRN 03:11:51.698] [KSPCF:ModuleIndexingMismatch] Part "strutCube" configuration has changed. Synchronizing persisted modules...
[LOG 03:11:51.698] [TweakScale] WARNING: Upgrading ScaleType! Craft 4283071424 had the part strutCube:FFE2A390 scaling changed from (TweakScale: default=100.000, current=100.000) to (stack: default=0.313, current=0.313)

The entry for KSPCF is telling us that this part had the order of the Modules different from expected, and then KSPCF reordered it. This is not a problem for TweakScale (as long there's only one MODULE section for TweakScale on the part, and this is the reason TweakScale freaks out when it finds more then one).

The second line is telling me that the original craft file had different scalings from what is defined on the TweakScale patches. From the ConfigCache, I got:

UrlConfig
{
        parentUrl = Squad/Parts/Structural/strutCubicOcto/strutCubicOcto.cfg
        PART
        {
                name = strutCube
                module = Part
<....>
                MODULE
                {
                        name = TweakScale
                        type = stack
                        defaultScale = 0.3125
                }
  

So this confirms that your patching is good, it's the same I get here on my rig. But your log is saying that TS had migrated the patching from a 100/100 to stack 0.3125/0.3125 - what makes sense, as some time ago TweakScale had the patches revamped and I wrote a migrating code to avoid screwing up people like it happened to you.

So perhaps the migration code became broken somehow? 

So I created a test craft consisting of a Drone Core and an strutCube. The strutCube TweakScale section is:

        MODULE
        {
                name = TweakScale
                isEnabled = True
                active = True
                available = True
                currentScale = 0.3125
                defaultScale = 0.3125
                defaultTransformScale = (0, 0, 0)

So I changed it to:

        MODULE
        {
                name = TweakScale
                isEnabled = True
                active = True
                available = True
                currentScale = 100
                defaultScale = 100
                defaultTransformScale = (0, 0, 0)

To match what I think it's yours, and fired up my KSP.

I got the same log entry as yours, and when I loaded the craft on Editor…. Yeah. The strutCube got gigantic. (sigh).

Ok,  confirmed.

But now I have a problem - when I wrote that code, it worked. It was intended to survive issue #87 .  I spent the whole year (Dec 2019 to Dec 2020) fixing things slowly to avoid breakage, and - damn - I had tested the damn thing.

I don't know what changed (yet), but I'm working on it. https://github.com/net-lisias-ksp/TweakScale/issues/285

I already know exactly the code that it's borking, but I don't now yet why. Working on it right now.

— — POST EDIT — — 

It worths to mention that on March, 2022 I made TweakScale to behave from migrating users from All Tweak.

All Tweak is a hack to add a minimalistic patch to anything that is not patched with TweakScale by blindly adding "free" scaling on them. All Tweak was a head ache at that time as when someone writes proper patchings, parts that were using All Tweak misbehave exactly as this issue.

Well, at least I know where to start to look for what changed from March 2022 to nowadays. Now I have a benchmark.

 

Edited February 2, 2023 by Lisias
post edit

[starfall22]

so tweakscale does the correct thing, by making the strutcube the size its supposed to be? I found those lines in my logs as well that stuck out. This happened to everything that had one of those strutcubes on it. I think my rocket that was on the mun had one of its decouplers turn into a stargate as well. Anyways, the sad part is that pretty much everything in my game has one or more of those on it. Any way to fix this? Should i go through my save file and look for those values and manually change them. Since right now, if i load anything in, i get fireworks. And pieces doing mach 10+ off the surface. uff, that would be alot to change though i guess. But i only have like,  5 relays, 1 rocket that has the issue, and 2 rovers.  There really shoulnt be more than 20-30 of those values in the save. Im just not exactly sure what their values should be. The strutcube apparently has to be 0.3125...

[Lisias]

55 minutes ago, starfall22 said:

so tweakscale does the correct thing, by making the strutcube the size its supposed to be? I found those lines in my logs as well that stuck out.

Well, it was doing the right thing before. Now it doesn't. I'm trying to figure out what and why, but at least I already know where.

It's going to be a long night.

 

55 minutes ago, starfall22 said:

This happened to everything that had one of those strutcubes on it. I think my rocket that was on the mun had one of its decouplers turn into a stargate as well. Anyways, the sad part is that pretty much everything in my game has one or more of those on it.

There're more parts affected, but the strutCube is one of the most used. Statistics can bite our sorry SAS on the most unexpected ways.

 

55 minutes ago, starfall22 said:

Any way to fix this?

Yes. More than one, by the way:

For crafts that does not have parts scaled, load them and save them on a KSP rig without TweakScale installed. This will get the TwealScale module section removed from the crafts, and when you load them again with TweakScale installed, things will be fine. A quick and dirty way to do that by brute force is to open the craft file using a TextEdit e do a search and replace for "name = TweakScale" to "name = TweakScaleFoo". When loading the craft KSP will complain about missing "TweakScaleFoo" module - just ignore it and load the craft anyway. KSP will inject back a new TweakScale section with current, problemless data.

For crafts that does have scaled things, things are going to get a bit more complicated. One easy hack is to delete the "patches" folder from the new TweakScale and unzip the ones from the older TweakScale. You will use older patches, that are (probably) compatible with your crafts, avoiding to trigger the problem. These patches are old and I deprecated them for a reason but, hell, the whole meaning of this whole stunt is to have a nice KSP gaming session and you are not getting one right now. Screw that patches, use whatever will make things work for you now.

 

55 minutes ago, starfall22 said:

Should i go through my save file and look for those values and manually change them. Since right now, if i load anything in, i get fireworks. And pieces doing mach 10+ off the surface. uff, that would be alot to change though i guess. But i only have like,  5 relays, 1 rocket that has the issue, and 2 rovers.  There really shoulnt be more than 20-30 of those values in the save. Im just not exactly sure what their values should be. The strutcube apparently has to be 0.3125...

For things that are unescaled, just rename the TweakScale module to any sillyness and KSP will get rid of them and inject back nice, modern values.

Frankly, this is one of the things I was intending to prevent with a thingy called Stealth Save, where TweakScale modules would be omitted while saving unscaled crafts. But I had to deactivate that thing due issues with 3rd parties.

— — — 

On a side note, I just realize that TweakScale 2.5 (BETA) doesn't presents the problem, only the mainstream branch (2.4 series) are problematic right now.

I'm trying to figure out why Beta is working and Release is not. On the bright side, once I understand why Release gone South the fix will be obvious.

What leads to a 3rd way to survive the problem: Install TweakScale 2.5 beta. This thing is bleeding edge, and it can bite you in the SAS because, well, it's in frantic development and I didn't properly tested most of the new code. But, hell, this thing is working for your use case.

And you can revert back to TweakScale 2.4.6.21 later - I do it constantly on my test beds withuot any (noticeable) problem until the moment.

(ping @starfall22 about the 3rd option)

Edited February 2, 2023 by Lisias
3rd option

[starfall22]

6 minutes ago, Lisias said:

For crafts that does not have parts scaled, load them and save them on a KSP rig without TweakScale installed. This will get the TwealScale module section removed from the crafts, and when you load them again with TweakScale installed, things will be fine. A quick and dirty way to do that by brute force is to open the craft file using a TextEdit e do a search and replace for "name = TweakScale" to "name = TweakScaleFoo". When loading the craft KSP will complain about missing "TweakScaleFoo" module - just ignore it and load the craft anyway. KSP will inject back a new TweakScale section with current, problemless data.

For crafts that does have scaled things, things are going to get a bit more complicated. One easy hack is to delete the "patches" folder from the new TweakScale and unzip the ones from the older TweakScale. You will use older patches, that are (probably) compatible with your crafts, avoiding to trigger the problem. These patches are old and I deprecated them for a reason but, hell, the whole meaning of this whole stunt is to have a nice KSP gaming session and you are not getting one right now. Screw that patches, use whatever will make things work for you now.

hmrh, now im trying to figure out if i actually had any parts that were scaled. What happens to a craft if i rename the tweakscale part and it does have "tweaked" things on it?

[Lisias]

5 hours ago, starfall22 said:

hmrh, now im trying to figure out if i actually had any parts that were scaled. What happens to a craft if i rename the tweakscale part and it does have "tweaked" things on it?

It gets descaled to default settings! This can be quite entertaining on flying crafts...

Backup everything and give TweakScale 2.5 Beta a shot. It appears to be your best option right now.

— — — POST EDIT — — — 

@starfall22, the problems started at 2.4.6.19 .

Download and install 2.4.6.18 and you should be right - at least, on my test bed, the problem didn't happened.

Edited February 2, 2023 by Lisias
bad grammars. good think I'm not a writer...

[dan1ell1ma]

12 hours ago, Lisias said:

Well, the blown up part in your screenshot is the "strutCube" (internal KSP name for the "Cubic Octagonal Strut"). So I gone through a fishing expedition on your logs. Found this:

[WRN 03:11:51.698] [KSPCF:ModuleIndexingMismatch] Part "strutCube" configuration has changed. Synchronizing persisted modules...
[LOG 03:11:51.698] [TweakScale] WARNING: Upgrading ScaleType! Craft 4283071424 had the part strutCube:FFE2A390 scaling changed from (TweakScale: default=100.000, current=100.000) to (stack: default=0.313, current=0.313)

The entry for KSPCF is telling us that this part had the order of the Modules different from expected, and then KSPCF reordered it. This is not a problem for TweakScale (as long there's only one MODULE section for TweakScale on the part, and this is the reason TweakScale freaks out when it finds more then one).

The second line is telling me that the original craft file had different scalings from what is defined on the TweakScale patches. From the ConfigCache, I got:

UrlConfig
{
        parentUrl = Squad/Parts/Structural/strutCubicOcto/strutCubicOcto.cfg
        PART
        {
                name = strutCube
                module = Part
<....>
                MODULE
                {
                        name = TweakScale
                        type = stack
                        defaultScale = 0.3125
                }
  

So this confirms that your patching is good, it's the same I get here on my rig. But your log is saying that TS had migrated the patching from a 100/100 to stack 0.3125/0.3125 - what makes sense, as some time ago TweakScale had the patches revamped and I wrote a migrating code to avoid screwing up people like it happened to you.

So perhaps the migration code became broken somehow? 

So I created a test craft consisting of a Drone Core and an strutCube. The strutCube TweakScale section is:

        MODULE
        {
                name = TweakScale
                isEnabled = True
                active = True
                available = True
                currentScale = 0.3125
                defaultScale = 0.3125
                defaultTransformScale = (0, 0, 0)

So I changed it to:

        MODULE
        {
                name = TweakScale
                isEnabled = True
                active = True
                available = True
                currentScale = 100
                defaultScale = 100
                defaultTransformScale = (0, 0, 0)

To match what I think it's yours, and fired up my KSP.

I got the same log entry as yours, and when I loaded the craft on Editor…. Yeah. The strutCube got gigantic. (sigh).

Ok,  confirmed.

But now I have a problem - when I wrote that code, it worked. It was intended to survive issue #87 .  I spent the whole year (Dec 2019 to Dec 2020) fixing things slowly to avoid breakage, and - damn - I had tested the damn thing.

I don't know what changed (yet), but I'm working on it. https://github.com/net-lisias-ksp/TweakScale/issues/285

I already know exactly the code that it's borking, but I don't now yet why. Working on it right now.

— — POST EDIT — — 

It worths to mention that on March, 2022 I made TweakScale to behave from migrating users from All Tweak.

All Tweak is a hack to add a minimalistic patch to anything that is not patched with TweakScale by blindly adding "free" scaling on them. All Tweak was a head ache at that time as when someone writes proper patchings, parts that were using All Tweak misbehave exactly as this issue.

Well, at least I know where to start to look for what changed from March 2022 to nowadays. Now I have a benchmark.

 

Is All Tweak still needed?

[Lisias]

4 hours ago, dan1ell1ma said:

Is All Tweak still needed?

It will always be kinda needed if you are laissez-faire with your patchings. I build patches for some of the most used add'ons on the TweakScale Companion Program, and some few authors support themselves TweakScale on their add'ons - for all the rest you would need to write your own patchings, ask me to do such (what I usually do as time allows) or just go brute force with All Tweak, that works for the most parts.  

However, make no mistake - this problem we are handling now is not All Tweak's fault, it's mine somehow - 90% of the problems I receive here are from 3rd parties somehow, but this one is on that others 10% - so please don't blame All Tweak for this one.

(to tell you the true, there's a chance this one is also from a 3rd party, a library I use - that happens to be made by me too, but from the TweakScale's point of view, it's still a 3rd party).

— — POST EDIT — — 

I may be innocent after all! See this post for details.

Edited February 2, 2023 by Lisias
POST EDIT

[starfall22]

13 hours ago, Lisias said:

It gets descaled to default settings! This can be quite entertaining on flying crafts...

Backup everything and give TweakScale 2.5 Beta a shot. It appears to be your best option right now.

— — — POST EDIT — — — 

@starfall22, the problems started at 2.4.6.19 .

Download and install 2.4.6.18 and you should be right - at least, on my test bed, the problem didn't happened.

It would seem like the 2.4.6.19 works, the things are the size they should be. However, messing around with the mods has made Kerbin atmosphere... umm, blue. Im not playing with kerbals anymore, im playing with smurfs  I dont know what caused that nor how to fix it. A pity  but at least my stuff dont explode upon loading them  Also, i was wondering, is there a mod that eases physics during loading, kind of like the position tool from the cheat menu. It has ease physics option, but when i load a game that has a craft that is close to a planet and is moving, it goes all crazy and hits the ground at the speed of orbit around the sun. Its not tweakscale issue, but i was wondering if you know anything about that.
It would be really awesome if i could actually load my autosaves without the risk of things exploding due to the games weird physics handling.

[Lisias]

METAR

There's an unknown problem right now interfering with TweakScale's functionalities that migrate outdated ScaleTypes from crafts and savegames being loaded.

It's proven that this is not a patch problem from 3rd parties, but it's also proven that this is not a TwekScale problem neither.

Users affected by the problem, as @AlonzoTG and @starfall22are exempted of fault on the problem, there's nothing they could had do or had not done that would trigger this krap. 3rd Party patches are also exempted of fault, as this thing was working on a recent past, and so mangling patches was declared safe and so, anything messing around the patches was doing something declared supported by TweakScale.

The trigger of the problem was nailed down to the presence of some specific KSPe.Light.TweakScale versions. I want to emphasise presence, not use. I recompiled TweakScale 2.4.6.21 to use the latest KSPe (full) on my rig, and the problem had gone way. However, by installing any KSPe.Light.TweakScale que was distributed from TS 2.4.6.0 until the latest 2.4.6.21, we have this problem happening on the test bed - even without anything on the rig using it. The mere presence of the DLL is triggering this weird misbehaviour.

Since I ruled out TweakScale as the source of the problem, I moved the issue into the current probable trigger (as it's proven that the damned thing is not causing it neither - at least, on ideal conditions of temperature and pressure).

https://github.com/net-lisias-ksp/KSPe/issues/46

However, being a problem affecting TweakScale's users, it's obvious that I'm still working on it.

Since I have nailed down exactly the point in which things started to go south deterministically, I have (hopefully) enough information to keep pursuing exactly what's triggering the problem and, with a bit of luck, also determine what's being triggered after all.

The current best workaround on this issue is to Install TweakScale 2.5 Beta (and the respective KSPe, see the link on the download page) to load and save back all your savegames and crafts using deprecated or non stock ScaleTypes, and then you can revert back to TS 2.4.6.21 to keep playing. You are encouraged to uninstall the 000_KSPe directory too after the job. Ok, it's proven to be working flawless until this moment, but I strongly discourage the installation of anything you are not going to use, and really few people needs KSPe (full) installed right now.

Make backups of everything, just in case.

Edited February 2, 2023 by Lisias
Better phrasing.