Lisias

[1.3.1 <= KSP <= 1.7.3] TweakScale - Under Lisias' Management - 2.4.3.8 - 2019-1018

Recommended Posts

9 hours ago, ConnieCommie said:

Hi, i really like tweakscale, it's a godsend when i build planes, but lately it's been throwing me the log... curiously enough a lot of what's listed seem to be vanilla parts.

Here's the log; i'd like to fix it so i can get on with buildin planes

Thanks in advance!

There's something absolutely weird on your installment! TweakScale is being loaded TWICE!

[LOG 00:07:39.922] AssemblyLoader: Loading assembly at D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\GameData\TweakScale\Plugins\Scale.dll
[LOG 00:07:39.923] AssemblyLoader: KSPAssembly 'Scale' V2.4.0
...
[LOG 00:07:40.073] AssemblyLoader: Loading assembly at D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\TweakScale\Plugins\Scale.dll
[LOG 00:07:40.098] AssemblyLoader: KSPAssembly 'Scale' V2.4.0

Delete "D:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\GameData\" from your rig. Are you using CKAN?

In a way or another, that "[LOG 00:15:34.199] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with issues overruled ; 575 Show Stoppers found; 7 Sanity Check failed;" message fits the diagnose. With two sets of TweakScale patches on your installment, TweakScale patches will be applied twice. :( 

 

Share this post


Link to post
Share on other sites

Hi, I'm also getting the Houston error. I have one fatal error associated with the Z-200 battery pack. Here's my KSP.log

Thanks for any help!

Share this post


Link to post
Share on other sites

Well i'm an idiot - apparently there was another, incorrectly-installed tweakscale in another folder. Thank you for helping, tho... trusting twitch was a mistake.

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, astro88 said:

Hi, I'm also getting the Houston error. I have one fatal error associated with the Z-200 battery pack. Here's my KSP.log

Thanks for any help!

Yep. Got it:

[LOG 18:17:15.639] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with issues overruled ; 1 Show Stoppers found; 21 Sanity Check failed;
[LOG 18:17:15.604] [TweakScale] WARNING: **FATAL** Found a showstopper problem on batteryBankMini (Z-200 Rechargeable Battery Bank).
[LOG 18:17:15.604] [TweakScale] ERROR: **FATAL** Part batteryBankMini (Z-200 Rechargeable Battery Bank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

On the bright side, it's only one serious issue. The batteryBankMini is borking due a patch on ROs, see this post about how to fix. There's a lot of potential problems on the RO's patch, and unfortunately I lack the time to proper support TweakScale and also propose fixes for RO's patches, so I kindly ask you to reach RO's maintainers about the issue, pinpointing this post as a source of information. [yup. copy&paste ! :) ]

On a not that bright side, you have about 12 "non RO - *** Cryogenic Fuel Tank" parts that had TweakScale withdrawn due some incompatibility between Third Parties Add'Ons. Not a TweakScale issue, but on that situation trying to scale that parts leads to disasters. I can give you a proper report so you can reach the Add'On maintainers for a solution if you can post the ModuleManager.ConfigCache file (on your GameData) by crossing the log file to the cache and checking exactly the Add'Ons involved on the mess. They are not a problem right now, you just can't scale them.

—— addendum — — 

TL;DR : you need to edit RO patches to make sure the look like this:

@PART<yadda yadda yadda>
	@MODULE[TweakScale]:NEEDS[TweakScale]
	{
		%type = RealismOverhaulStackSolid
	}

— — — — — — — — — 

The 9 remaining parts (basically engine plates) are parts that TweskScale doesn't know (yet) how to scale (but you can use them alright). This will be fixed on the 2.4.4 series.

Edited by Lisias
addendum

Share this post


Link to post
Share on other sites

hello, I just started up KSP on my new laptop after copying over my game data files and got a message saying tweakscale found some corrupt files. I've attempted to update all installed mods but some keep saying out of date no matter what. I've attached my log file below, hope you can help me out! 

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

Share this post


Link to post
Share on other sites
22 hours ago, Lisias said:

You can use them without worries. TweakScale is telling you that these parts cannot be scaled by lack of proper support, but they are alright to be used.

Warnings and advises are just informative. These are yellow or white, and means that things are not perfect (yet), but are not bad either.

The nasty things are informed in red, and these gets in the way preventing you to proceed until you dismiss them.

About that 9 parts, version 2.4.4 will have them supported. 

Thank you- I sure appreciate all the help and advice you give me and others on this forum!

Share this post


Link to post
Share on other sites
1 hour ago, Starman17 said:

hello, I just started up KSP on my new laptop after copying over my game data files and got a message saying tweakscale found some corrupt files. I've attempted to update all installed mods but some keep saying out of date no matter what. I've attached my log file below, hope you can help me out! 

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

Got it!

[LOG 18:46:30.095] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with issues overruled ; 2 Show Stoppers found; 21 Sanity Check failed;

I checked that 21 "insane" :P parts. By some reason, someone tried to shove TweakScake on the kerbalEVA* parts and on a flag :confused: (5 parts) due the Issue #30. There're a lot of Add'Ons mangling the kerbalEVA* parts, this will take some time to sort out - but I will do it on the weekend.

Well, these are not scalable anyway. I don't think Valentina would do well as a "50 foot Kerbalette" :) 

The other ones are parts from Making History (MODULEPARTVARIANT with mass) and Firespitter (FSBuyoancy) that are not supported (yet) by TweakScale. You can use them too, but they don't scale (yet).

The other two are a new! (or I having memory issues again? :P )

[LOG 18:46:29.056] [TweakScale] WARNING: **FATAL** Found a showstopper problem on bluedog.CXA.APAS.A.L04F (CADS 0.9375m Docking Port (Active)).
[LOG 18:46:29.056] [TweakScale] ERROR: **FATAL** Part bluedog.CXA.APAS.A.L04F (CADS 0.9375m Docking Port (Active)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 18:46:29.056] [TweakScale] WARNING: **FATAL** Found a showstopper problem on bluedog.CXA.APAS.P (CADS 0.9375m Docking System (Passive)).
[LOG 18:46:29.057] [TweakScale] ERROR: **FATAL** Part bluedog.CXA.APAS.P (CADS 0.9375m Docking System (Passive)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

Let's check one of them:

[LOG 18:37:31.864] Config(@PART[bluedog_CXA_APAS_P]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ConnectedLivingSpace]) Bluedog_DB/Compatibility/ConnectedLivingSpace/CLSBluedogDB/@PART[bluedog_CXA_APAS_P]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ConnectedLivingSpace]
[LOG 18:37:31.872] Config(@PART[bluedog_CXA_APAS_P]:NEEDS[TweakScale]) Bluedog_DB/Compatibility/Tweakscale/tweakscale_APAS/@PART[bluedog_CXA_APAS_P]:NEEDS[TweakScale]
[LOG 18:37:31.880] Config(PART) Bluedog_DB/Parts/APAS/CXA_APAS_P/bluedog_CXA_APAS_P
[LOG 2019-08-07 18:33:54.994] Deleting root node in file Bluedog_DB/Compatibility/ConnectedLivingSpace/CLSBluedogDB node: @PART[bluedog_CXA_APAS_P]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ConnectedLivingSpace] as it can't satisfy its NEEDS
[LOG 2019-08-07 18:34:02.289] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_APAS/@PART[bluedog_CXA_APAS_P]:NEEDS[TweakScale] to Bluedog_DB/Parts/APAS/CXA_APAS_P.cfg/PART

Well, I got the part source on this file, Bluedog-Design-Bureau/Gamedata/Bluedog_DB/Compatibility/Tweakscale/tweakscale_APAS.cfg:

@PART[bluedog_CXA_APAS_P]:NEEDS[TweakScale] // CADS 0.9375m Docking System (Passive)
{
    %MODULE[TweakScale]
    {
        type = BluedogStack
        defaultScale = 0.9375
    }
}

Since this is a bluedog part, I would add ":FOR[Bluedog_DB]" on the PART thingy, but this is not the source of the problem! (but perhaps it would help to prevent it?) It's something else mangling with this part, together this patch. Problem is…. NO ONE ELSE did it (explicitly) on the log! 

Can you please post the "ModuleMaager.ConfigCache"? By looking on the part there, I can have a hint about who is the another guy patching it!

Share this post


Link to post
Share on other sites
Posted (edited)
12 hours ago, Starman17 said:

So I found the ModuleManager.ConfigCache but I'm not sure how you're gonna access this.

https://www.dropbox.com/s/kj99i31mtsdouef/ModuleManager.ConfigCache?dl=0

The nice thing on KSP is that it's all text files. Any Text Editor allows you so see (and change) these files. :)  This is what I got:

UrlConfig
{
        parentUrl = Bluedog_DB/Parts/APAS/CXA_APAS_P
        PART
        {
                name = bluedog_CXA_APAS_P
                module = Part
                <cut>
                MODULE
                {
                        name = TweakScale
                        type = BluedogStack
                        defaultScale = 0.9375
                        type = free
                }
		<cut>
}

UrlConfig
{
        parentUrl = Bluedog_DB/Parts/APAS/CXA_APAS_A_L04F
        PART
        {
                name = bluedog_CXA_APAS_A_L04F
                module = Part
                <cut>
                MODULE
                {
                        name = TweakScale
                        type = BluedogStack
                        defaultScale = 0.9375
                        type = free
                }
         <cut>
}

You see that two "type' thingies? This is the nasty stuff. Bluedog's Author meant to use the BluedogStack, but something else shove a new "type" without  deleting the other one, and now things are confused. Until the moment, KSP uses the latest value when a duplicated entry happens (unless you want to read it as an array - but it's not the case here). Problem is - nobody knows from where came that "free", and so nobody knows when that "free" can goes away (by adding, deleting or updating an Add''On , changing the order in which things happens and sometimes not applying the offending patch). And then your crafts goes kaput. :( 

This time I didn't got lucky, that "free" thing is pretty common. So I will need to check it the hard way: patch by patch, after downloading everything. At least I already ruled out one or two Add'Ons, as I know they don't use "free" on their patches. :)

I'll get back to you as soon as possible.

Edited by Lisias
Kraken damned auto-completes. :(

Share this post


Link to post
Share on other sites
On 8/2/2019 at 7:37 PM, Lisias said:

MODULE { name = TweakScale type = stack defaultScale = 0.625 type = RealismOverhaulStackSolid

I'm not seeing this line anywhere under the batter bank mini in the ModuleManager.ConfigCache file. Am I looking in the right file? Sorry, I'm a complete noob when it comes to this.

Share this post


Link to post
Share on other sites
1 hour ago, astro88 said:

I'm not seeing this line anywhere under the batter bank mini in the ModuleManager.ConfigCache file. Am I looking in the right file? 

Well… That was unexpected :)

Post the ModuleManager.ConfigCache so I can look on it.

 

1 hour ago, astro88 said:

Sorry, I'm a complete noob when it comes to this.

I was too, one year ago. :) It's somewhat messy at first glance, but once you start to understand how these things work things just snaps on your head. Knowing how to code helps, but everything I learnt about patches was reading people's posts about. ;) (and borking a lot on my installment, I didn't learnt to fix KSP just because… hehehe)

Share this post


Link to post
Share on other sites
Posted (edited)
On 8/9/2019 at 9:11 PM, ChivalryCode said:

I love using Tweakscale for my planes and rovers, big love for keeping this train rolling. 

Do you want to test drive what one day will be TweakScake 2.5? I added proper Wheels scaling - they know get stronger by scaling up, but also weaker by scaling it down!

Spoiler

Test it only on disposable savegames, things can change on every build as the whole thing is a test bed for new features!

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

 

Got it. Ugh, 69 show stoppers! :(

[LOG 18:54:42.487] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with issues overruled ; 69 Show Stoppers found; 0 Sanity Check failed;

They are all related to SMX and M3X however, so I think we can walk away by checking only one of each. Lets try it:

[LOG 18:52:59.445] Config(PART) MiningExpansion/Parts/Mk2ISRUDrill/Drill/SMX_InlineDrill
[LOG 18:52:59.446] Config(@PART[SMX_InlineDrill]:NEEDS[Workshop]) MiningExpansion/Patch/SME_OSE/@PART[SMX_InlineDrill]:NEEDS[Workshop]
[LOG 18:52:59.446] Config(@PART[SMX_InlineDrill]:NEEDS[TweakScale]) MiningExpansion/Patch/SME_Tweakscale/@PART[SMX_InlineDrill]:NEEDS[TweakScale]
[LOG 18:52:59.516] Config(@PART[SMX_InlineDrill]) TweakScale/patches/MiningEx_Tweakscale/@PART[SMX_InlineDrill]
[LOG 17:59:39.860] Deleting root node in file MiningExpansion/Patch/SME_OSE node: @PART[SMX_InlineDrill]:NEEDS[Workshop] as it can't satisfy its NEEDS
[LOG 17:59:40.750] Applying update MiningExpansion/Patch/SME_Tweakscale/@PART[SMX_InlineDrill]:NEEDS[TweakScale] to MiningExpansion/Parts/Mk2ISRUDrill/Drill.cfg/PART[SMX_InlineDrill]
[LOG 17:59:48.051] Applying update TweakScale/patches/MiningEx_Tweakscale/@PART[SMX_InlineDrill] to MiningExpansion/Parts/Mk2ISRUDrill/Drill.cfg/PART[SMX_InlineDrill]
[LOG 17:59:57.520] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to MiningExpansion/Parts/Mk2ISRUDrill/Drill.cfg/PART[SMX_InlineDrill]
[LOG 18:53:07.299] PartLoader: Compiling Part 'MiningExpansion/Parts/Mk2ISRUDrill/Drill/SMX_InlineDrill'
[LOG 18:54:42.408] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SMX.InlineDrill ('Prospector' Aerospace Mining Excavator).
[LOG 18:54:42.408] [TweakScale] ERROR: **FATAL** Part SMX.InlineDrill ('Prospector' Aerospace Mining Excavator) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).


-- -- -- 

[LOG 18:52:59.453] Config(PART) Mk3Expansion/Parts/Engines/HeavyProp/part/M3X_Heavyprop
[LOG 18:52:59.456] Config(@PART[M3X_Heavyprop]:NEEDS[TweakScale]) Mk3Expansion/Patches/M3X_Tweakscale/@PART[M3X_Heavyprop]:NEEDS[TweakScale]
[LOG 18:52:59.517] Config(@PART[M3X_Heavyprop]) TweakScale/patches/Mk3X_Tweakscale/@PART[M3X_Heavyprop]
[LOG 17:59:41.402] Applying update Mk2Expansion/Patches/Mk2X_AtmIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake],@RESOURCE[IntakeAir],!RESOURCE[IntakeAtm]]:NEEDS[!WarpPlugin,!GTI] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 17:59:42.120] Applying update Mk3Expansion/Patches/M3X_Tweakscale/@PART[M3X_Heavyprop]:NEEDS[TweakScale] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 17:59:48.310] Applying update TweakScale/patches/Mk3X_Tweakscale/@PART[M3X_Heavyprop] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 17:59:57.531] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop]
[LOG 18:53:12.466] PartLoader: Compiling Part 'Mk3Expansion/Parts/Engines/HeavyProp/part/M3X_Heavyprop'
[LOG 18:54:42.429] [TweakScale] WARNING: **FATAL** Found a showstopper problem on M3X.Heavyprop (F-12 "Hurricane" Turboprop Engine).
[LOG 18:54:42.429] [TweakScale] ERROR: **FATAL** Part M3X.Heavyprop (F-12 "Hurricane" Turboprop Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

 

The SMX parts are being double patched by TweakScale itself and Mining Expansion. Checking that Add'On, I found:

@PART[SMX_StackLeg]:NEEDS[TweakScale]:FINAL
{
    %MODULE[TweakScale]
    {
        %type = stack
        %defaultScale = 1.25
    }
}

 

[TL;DR : I misread the Log and jumped into conclusions. Module Manager is doing right, as it appears - the :FINAL thingy was added recently!!]]

Spoiler

What appears to be a well behaving patch. It should not be doing this. The :FINAL thingy should instruct Module Manager to apply these patches by last, after TweakScale! From the docs:

Quote

Patches are applied in the following order:

  1. Nodes with no operator ('insert') are loaded by the KSP GameDatabase first.
  2. Patches for modname values in NEEDS, BEFORE, AFTER that don't exist are removed.
  3. All patches with :FIRST are applied.
  4. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied.
  5. For each item in the Unicode-sorted list of modname values:
  6. All patches with :BEFORE are applied
  7. All patches with :FOR are applied
  8. All patches with :AFTER are applied
  9. All patches with :FINAL are applied

 

Follows TweakScale default patch:


@PART[SMX_StackLeg] //J-7 Superheavy Duty Landing leg
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
}

"My" patches have a flaw, they don't use ":FOR" yet - This will reach mainstream only on TweakScale 2.5 because when I shoved the ":FOR" on them, I got literally 172 Fatal Problems on my "RPG" KSP installment. But in a way or another, since TweakScale are using the "legacy" ordering (i.e., no ordering :P ) my understanding is that TweakScale patches should be being applied on the Step 1.

M3X patches are exactly the same.

 

Checking the Add'On' repositories, I found this:

Quote

If using TweakScale, delete the GameData/TweakScale/patches/Mk3X_TweakScale.cfg; it is out of date and may conflict with the patch included with M3X.

Source:https://github.com/SuicidalInsanity/Mk3Expansion/tree/master/Mk3Expansion

So the fix is pretty obvious(c)2018 Elon Musk, delete the following lines from TweakScale folders:

  • GameData/TweakScale/patches/MiningEx_Tweakscale.cfg
  • GameData/TweakScale/patches/Mk3X_Tweakscale.cfg

HOWEVER… The Add'On maintainer is not wrong - "my" patches are pretty dated, and the guy made better patches - what means different. If you do "the right thing" and delete my patches, any savegame with flying crafts with M3X and SMX parts may get corrupted! See the pictures below for what I expect to happen to them:

So… My best advise to you is to install S.A.V.E. (really!), try doing the "right thing" first (deleting my patches) and see if all your crafts survives.

Anything going wrong, reinstall TweakScale, but delete the Add'On' ones. Frankly, this is the "wrong thing" to do, but you probably would want to keep playing your savegames, right?

  • GameData/MiningExpansion/Patch/SME_Tweakscale.cfg
  • GameData/Mk3Expansion/Patches/M3X_Tweakscale.cfg

And, of course, create a new installment "doing the right thing" for new savegames. I will withdraw my patches from de distribution, they should be considered deprecated now. To tell you the true, they are deprecated for 8 months already, but nobody told me so - this would had prevented your problems, I'm sorry.

Let me know if I can help on anything else.

— — — POST EDIT — — — 

The latest release for M3X fixes the problem, you are using older versions! :) 

https://github.com/SuicidalInsanity/Mk3Expansion/releases

https://github.com/SuicidalInsanity/Stockalike-Mining-Extension/releases

Edited by Lisias
MM is doing right.

Share this post


Link to post
Share on other sites

Is there anything I can do to fix my KSP files or does my tweak scale code need to checked piece by piece

Share this post


Link to post
Share on other sites
Posted (edited)
9 hours ago, ChivalryCode said:

After applying those fixes I'm left with one more fatal error on the M2X.endcap

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

This I recognized. :)

[LOG 09:55:40.666] Applying update Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_Endcap]:NEEDS[TweakScale] to Mk2Expansion/Parts/Structural/Endcap/part.cfg/PART[M2X_Endcap]
[LOG 09:55:40.814] Applying update Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_Endcap]:NEEDS[TweakScale] to Mk2Expansion/Parts/Structural/Endcap/part.cfg/PART[M2X_Endcap]

Mk2Expansion has a problem on its patches. It was fixed on this pull request, waiting approval (and yeah, this time I remembered to tell the guy! :D) . Download this file (click on raw) and replace the current one for now.

 

8 hours ago, Starman17 said:

Is there anything I can do to fix my KSP files or does my tweak scale code need to checked piece by piece

Usually, fixing the rogue patches solves the problem. Now and then the fix borks flying crafts, and then you must decide if you would apply a OVERRULE patch to "break it again" (but on a safe way), or to try to fix the craft by hand, editing the savegame. It's possible, besides worksome.

Unless we find a new kind of problem, TweakScale sanity checks now does the heavy lifting for you (detecting the problems). Fire up KSP and check the logs - as long you don't load any savegames, no harm will be done if the worst happens.

POST-EDIT: @Starman17 -  I misread your post. I had promised you to give a new look on your problem once you published your ConfigCache. Sorry. I will do it tomorrow morning.

Edited by Lisias
Whoopsy

Share this post


Link to post
Share on other sites

Ok thanks, I really don't want to have to start a new savegame and lose all of my builds in orbit.

 

Share this post


Link to post
Share on other sites
Posted (edited)
On 8/12/2019 at 5:57 PM, Starman17 said:

Ok thanks, I really don't want to have to start a new savegame and lose all of my builds in orbit.

Neither do I. I know perfectly how is to lose months of game play. I know people that runs the same one for years.

It's the reason I try hard to prevent the breakage, and once I fail on that (being my fault or not), I try harder to make patches to keep things going.

That said, I'm sorry for not being able to respond faster - to you or anyone else, including on GitHub. Old Farts like me have old fart's problems, and sometimes all of them decide to gather up and pay a visit at the same time! :P

oh well. Don't be shy to kick me here or in PVT if you think I forgot you. It will eventually be true! :sticktongue: .

Need to go now. Still at work! :)

— — back from the dungeons — — :sticktongue:

@Starman17 - I did a second analysis on your KSP.log and realized I missed some details. I found the problem.

[LOG 2019-08-07 18:35:01.895] Applying update CxAerospace/Station Parts/MM_configs/CXA_TweakScale/@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace] to Bluedog_DB/Parts/APAS/CXA_APAS_A_L04F.cfg/PART

It's CxAerospace. The double patching is happening for sure:

@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace]
{
        %MODULE[TweakScale]
        {
                type = free
        }
}

Do you see the "type = free" thingy? There's no "%" in it. So the "type" is being added (instead of edited) to any part that has "cxg2827" as the author and does not have ModuleComand. Guess what? The parts in Bluedog that where double patched has "cxg2827" on the author and does not have ModuleCommand. :/

This patch is somewhat insecure as it appears. It doesn't even check for the TweakScale being available (:NEEDS[TweakScale]) before applying the patch. It probably had worked at that time, but nowadays things changed - there are more than one Add'On using "cxg2827" in the author, this should not be used anymore as criteria.

From the Add'On's thread, I learnt that CxAerospace was discontinued, is unmaintained and the license is ARR. Well, there's nothing I can do fix the problem directly, as one could call me in copyright infringement by distributing a derivative - I checked the package, and the config files were not exempted from the copyright claim or double licensed. It was mentioned that the Author decided to give the assets to some other Add'On authors to be used at their discretion, so perhaps this is the reason Bluedog was caught in the crossfire.

So, I advise to you:

  • Check if your flying crafts are using CxAerospace . If not, delete this Add'On. I say this with a broken heart, this is a very nice looking Add'On, sir - perhaps the Author would accept fixes for a new release? No strings attached.
  • Reach Bluedog's Author and ask him to help on the matter. He's using cx2827 parts, so perhaps he is one of the guys mentioned above, and so authorized to act on it.

In the mean time, I'm cooking a OVERRULE HOTFIX patch that will fix your installment by brute force. Keep in mind that this patch is good only for your current installment. I don't foresee problems if you install or delete some Add'Ons from your installment (except Bluedog_DB, of course), but yet… Don't thrust it too much, use S.A.V.E.. :) .

— — Hot Fix — — 

@Starman17, I have a (hopefully) temporary workaround for you. Analysing  the patches, I'm sufficiently sure that I know how the intended ending results. So I cooked a brute force patch that will shove the correct results on the offended parts. This will keep your KSP installment sane while a proper fix is not applied on the right place.

Download and install TweakScale 2.4.3.3 (see OP), and then copy the following file(s) from the distribution package:

Extras/TweakScale/HotFixes/CxAerospace--Bluedog_DB.cfg

into your GameData. I strongly advise to use the following directory (create it if needed):

Quote

GameData/__LOCAL/TweakScale/HotFixes

 So the patches will survive updates and will be easily found when the time to delete them come.

I tried to make the patch the more safe I could, but as always, I recommend to use S.A.V.E.

 

Edited by Lisias
Adding Hot Fix.

Share this post


Link to post
Share on other sites
On 8/12/2019 at 5:39 PM, Lisias said:

Neither do I. I know perfectly how is to lose months of game play. I know people that runs the same one for years.

It's the reason I try hard to prevent the breakage, and once I fail on that (being my fault or not), I try harder to make patches to keep things going.

That said, I'm sorry for not being able to respond faster - to you or anyone else, including on GitHub. Old Farts like me have old fart's problems, and sometimes all of them decide to gather up and pay a visit at the same time! :P

oh well. Don't be shy to kick me here or in PVT if you think I forgot you. It will eventually be true! :sticktongue: .

Need to go now. Still at work! :)

— — back from the dungeons — — :sticktongue:

@Starman17 - I did a second analysis on your KSP.log and realized I missed some details. I found the problem.


[LOG 2019-08-07 18:35:01.895] Applying update CxAerospace/Station Parts/MM_configs/CXA_TweakScale/@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace] to Bluedog_DB/Parts/APAS/CXA_APAS_A_L04F.cfg/PART

It's CxAerospace. The double patching is happening for sure:


@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace]
{
        %MODULE[TweakScale]
        {
                type = free
        }
}

Do you see the "type = free" thingy? There's no "%" in it. Do the type is being applied to any part that has "cxg2827" as the author and does not have ModuleComand. Guess what? The parts in Bluedog what where double patched has "cxg2827" on the author and does not have ModuleCommand. :/

This patch is somewhat insecure as it appears. It doesn't even check for the TweakScale being available (:NEEDS[TweakScale]) before applying the patch. It probably had worked at that time, but nowadays things changed - there are more than one Add'On using "cxg2827" in the author, this should not be used anymore as criteria.

From the Add'On's thread, I learnt that CxAerospace was discontinued, is unmaintained and the license is ARR. Well, there's nothing I can do fix the problem directly, as one could call me in copyright infringement by distributing a derivative - I checked the package, and the config files were not exempted from the copyright claim or double licensed. It was mentioned that the Author decided to give the assets to some other Add'On authors to be used at their discretion, so perhaps this is the reason Bluedog was caught in the crossfire.

So, I advise to you:

  • Check if your flying crafts are using CxAerospace . If not, delete this Add'On. I say this with a broken heart, this is a very nice looking Add'On, sir - perhaps the Author would accept fixes for a new release? No strings attached.
  • Reach Bluedog's Author and ask him to help on the matter. He's using cx2827 parts, so perhaps he is one of the guys mentioned above, and so is authorized to act on it.

In the mean time, I'm cooking a OVERRULE patch that will fix your installment by brute force. Keep in mind that this patch is good only for your current installment. I don't foresee problems if you install or delete some Add'Ons from your installment (except Bluedog_DB, of course), but yet… Don't thrust it too much, use S.A.V.E.. :) . I'll edit this post when the patch is available.

 

Thank you so much for your help, KSP life saver lol

Share this post


Link to post
Share on other sites
Posted (edited)

Announce.

Minor Release 2.4.3.3 is on the wild. Just some typos fixed and added support for the new Cryo Engines from Nertea's.

  • 2019-0814: 2.4.3.3 (Lisias) for KSP >= 1.4.1
    • Added support for hot-fixes - handcrafted patches to brute force a correct path when the normal way is not possible - as when an unmaintained ARR Add'On is involved on the mess.

Links on the OP.  CurseForce and Spacedock will be updated on the Weekend.

— — News — — 

TweakScale 2.4.3.3 know recognizes and keep track of HOT FIXES.

A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don't break compatibility with sane installments, so you can start new savegames and share your crafts without worries.

However, a Hot Fix is highly specialized to a given situation, and there're no guarantees that it will behave correctly as the affected Add'Ons are updated by the maintainers. So, a pesky Advise will popup when Hot Fixes are detected to prevent you from forgetting a old Hot Fix on your installments.

In an ideal World, Overrules and HotFixes would not be necessary. These are temporary workarounds to keep KSP installments sane enough to keep going.

Apply Hot-Fixes or Overrules only when recommended by me, LisiasT. It's ok to reach me asking about if you think it will help you, but please confirm with me first. These things can cause as much damage as they can fix them.

Each Hot Fix will have an URL associated pinpointing to the Post where the problem were detected and fixed for traceability.

Edited by Lisias
News from the front

Share this post


Link to post
Share on other sites

@Lisias, thank you for your great work! Tweakscale is one of my absolute favorite mods.

When AVC just gave me the great news, I went straight to GitHub. I'm sure you are well aware that, as of just now, you had only released the source code there, and that you were just about to release the binary.
But just in case there was an (entirely understandable and human) oversight, I thought I'd report this "issue".

Share this post


Link to post
Share on other sites
Posted (edited)
4 hours ago, DerGolgo said:

@Lisias, thank you for your great work! Tweakscale is one of my absolute favorite mods.

When AVC just gave me the great news, I went straight to GitHub. I'm sure you are well aware that, as of just now, you had only released the source code there, and that you were just about to release the binary.
But just in case there was an (entirely understandable and human) oversight, I thought I'd report this "issue".

Thanks for the heads up! I just fixed it.

But this time, I'm innocent! Bitbucket had problems last night with GIT LFS, that is something not too unrelated to github's way of storing attachments. I wonder if something similar happened to github? I clearly remember **NOT CLOSING** the page while uploading (yeah, learnt it the hard way).

Interestingly, imgur had just failed on me too. The damned thing unlogged me after posting this image and it's refusing my logins. :( [edit: And then I asked for a new password, got the email, clicked on the link and imgur page's appaers WITH ME LOOGED. Whatahell???]

Well… one more step on the check list - be sure the github download is okey. :)

ZU7jtZL.png

https://imgur.com/a/Px4d19o

Edited by Lisias
Don't ask. I don't know either

Share this post


Link to post
Share on other sites
2 hours ago, Lisias said:

But this time, I'm innocent! Bitbucket had problems last night with GIT LFS, that is something not too unrelated to github's way of storing attachments. I wonder if something similar happened to github? I clearly remember **NOT CLOSING** the page while uploading (yeah, learnt it the hard way).

Interestingly, imgur had just failed on me too. The damned thing unlogged me after posting this image and it's refusing my logins. :( [edit: And then I asked for a new password, got the email, clicked on the link and imgur page's appaers WITH ME LOOGED. Whatahell???]

Again, thank you. For the mod, and for your fortitude in traversing these obstacles, surely placed there by some angry Database God. Sometimes, I do think "MySQL" is not so much a technical term as an explanation, not unlike "My Lord!".

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.