[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

[Lisias]

2 hours ago, MKSheppard said:

I'm trying to fix some of the exponents used in tweakscale to be more accurate.

Be careful. This will change the scaling rules of all already living crafts on the game at loading, and once this happens, it's essentially impossible to fix.

Be absolutely sure to follow the TweakScale Companions protocol about changing things from Default TweakScale configs, use a :FOR for your patches to mark their existence for MM (so people can detect it to adapt).

 

2 hours ago, MKSheppard said:

But I'm hitting a rock in trying to fix engine mass scaling:

//this fixes mass scaling for engines.
@TWEAKSCALEEXPONENTS[Part]:HAS[#category[Engine]]
{
%mass = 2 //original was set to 3
}

Doesn't work. Has anyone made a custom CFG that adjusts ONLY engine mass scaling?

You had already nailed it, the use of the "type" defines the exponent to be used.

 

2 hours ago, MKSheppard said:

EDIT: If you want liquid engines to scale correctly; you must use:

type = stack_square

This correctly scales their mass without the need for a patch

KSP is primarily a game, with some concessions made to being a simulator. It's not the aim of KSP (at least 1) to mimic real life rockets and technological limitations.

Some artistic compromises need to be made to keep the game enjoyable at first place, not realistic - this is not Orbiter. And this is the reason I refrain myself from changing already stablished patches even when it would make sense (as yours, apparently) - they were created after a lot of trial and error and ended up becoming canon - changing these values will break all current savegames on the planet (not to mention all the crafts published on Kerbal-X using TweakScale). Doesn't worths the cost.

On the other hand, there's Realism Overhaul where the aim is to be the most realistic possible. I think they are your audience for these changes.

-- -- -- post edit -- -- -- 

Going back to your idea, I have the following suggestion: create a new scaleType called "stack_realistic" or something, and then use it on the parts you want. This would satisfy your desires without breaking canon.

Just remember that, once you decide to publish it, to follow the TweakScale Companion protocols to avoid stomping everybody else's toes.

Edited June 26, 2020 by Lisias
post edit

[Dovahkiin2132]

Hey guys i'm having issues with the Aerospike engines from Kerbal Atomics. Namely,i can't seem to upscale them. Any ideas how to fix that?

[dat_boy9001]

I am getting a fatal/showstopper error and it suggested I post here. 

Below is the relevant part of the KSP.log (I think?) and here is my gamedata folder.  I've redownloaded and reinstalled the tweakscale with no effect. I only copied in the folders in /gamedata, not in the /extras folder. Prior to this I was getting errors about multiple watchdog/module managers, so I suspect my efforts to clean that up may have broken it somehow. 

Thank you for your help, I'm a bit of a newbie!

[LOG 11:58:09.122] [KSP_Recall] INFO: SanityCheck Concluded : 902 parts found ; 896 parts using Resourceful ; 0 show stoppers detected .
[LOG 11:58:09.122] [BDArmory] unloading bundle
[LOG 11:58:09.141] [TweakScale] WARNING: **FATAL** Found a showstopper problem on bdWarheadSmall (#loc_BDArmory_part_bdWarheadSmall_title).
[LOG 11:58:09.142] [TweakScale] ERROR: **FATAL** Part bdWarheadSmall (#loc_BDArmory_part_bdWarheadSmall_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
 

[Lisias]

1 hour ago, Dovahkiin2132 said:

Hey guys i'm having issues with the Aerospike engines from Kerbal Atomics. Namely,i can't seem to upscale them. Any ideas how to fix that?

Because there's no patch available to it yet.

Follow the TweakScale Companion Program thread. New patches are being published there - since there's already interest on it, I will kick Kerbal Atomics ahead on the queue.

 

46 minutes ago, dat_boy9001 said:

I am getting a fatal/showstopper error and it suggested I post here. 
 

Hi. I need the full KSP.log, otherwise I can't help. The information I need to check what's happening is there.

See this post about how to publish the needed files.

Edited June 28, 2020 by Lisias
Brute force post merging.

[dat_boy9001]

5 hours ago, Lisias said:

Because there's no patch available to it yet.

Follow the TweakScale Companion Program thread. New patches are being published there - since there's already interest on it, I will kick Kerbal Atomics ahead on the queue.

 

Hi. I need the full KSP.log, otherwise I can't help. The information I need to check what's happening is there.

See this post about how to publish the needed files.

Sorry about that!

Logs are here:

https://1drv.ms/u/s!AlhkI1XuoNm6jgoeM1YLSH3Af3mY?e=FNsfNb

[Lisias]

2 hours ago, dat_boy9001 said:

Sorry about that!

Logs are here:

https://1drv.ms/u/s!AlhkI1XuoNm6jgoeM1YLSH3Af3mY?e=FNsfNb

Hey, excellent material. You followed the instructions to the letter, thank you!

Now let's crack this nut:

[LOG 11:58:09.201] [TweakScale] INFO: WriteDryCost Concluded : 902 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 1 Show Stoppers found; 9 Sanity Check failed; 410 unscalable parts.

 

Not that bad, only one FATALity:

[LOG 11:58:09.142] [TweakScale] ERROR: **FATAL** Part bdWarheadSmall (#loc_BDArmory_part_bdWarheadSmall_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

There's a rogue patch somewhere double patching this part. Since TweakScale is not smart enough to tell weird things from bad weird things, it yells on anything weird. Let's the the patching:

[LOG 2020-06-28 11:55:57.689] Applying update BDArmory/MMPatches/BDArmory_TweakScale /@PART[bdWarheadSmall] to BDArmory/Parts/smallWarhead/part.cfg/PART
[LOG 2020-06-28 11:55:57.689] Applying update BDArmory/MMPatches/BDA_TweakScale/@PART[bdWarheadSmall] to BDArmory/Parts/smallWarhead/part.cfg/PART
[LOG 2020-06-28 11:56:01.194] Applying update BDArmory/Localization/part_deformatter/@PART[bdWarheadSmall]:FINAL to BDArmory/Parts/smallWarhead/part.cfg/PART

And a rogue patching we have.

There's two possibilities:

• the BDArmory maintainers forgot to delete an oldie or moved patch and ended up publishing the patch twice.
• they renamed the file and when you installed the new revision over the older, you ended up with two copies to that file (the current, and an oldie).
  • This happened on TweakScale 2.4.3.11 too, by the way (with the KIS patches). It's usually a best practice to completely delete the older install of the Add'On before installing the new version, but some Add'Ons saves user configurations and other customisations there and by doing that, you end up losing them - so It's best to check with the BDArmory guys how the best procedures for it.

For TweakScale, you can delete the older version without thinking twice.

I'm assuming you are using the latest BDArmory and checked the github repo to see if I find any oldie there (and so, saving some time for everybody on the diagnosing),  and no, there's not trace of the file BDArmory_TweakScale.cfg there.

So I think it's the second option.

Delete BDArmory/MMPatches/BDArmory_TweakScale.cfg and you will be fine.

Cheers!

[renejant]

is the "tweakscalerogueduplicate" problem solved yet? because i am still getting this error... read the part on the thread where it is being disscussed but i can't see any updates on the file about it... maybe i am overlooking it?

i am using tweakscale version 2.4.3.15 dated from 23-6-2020

[majNUN]

Quote

[TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container1 (SC-62 Portable Container).
 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Portable Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container2 (ILC-18k Container).
 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container3 (ISC-6K Container).
 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

[TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
 
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

Here are my fatalities.

[Lisias]

13 hours ago, renejant said:

is the "tweakscalerogueduplicate" problem solved yet? because i am still getting this error... read the part on the thread where it is being disscussed but i can't see any updates on the file about it... maybe i am overlooking it?

It's not a problem on TweakScale. You have a rogue patch somewhere shoving twice the whole TweakScale config section. TweakScale detects this situation, and once it's deterministic that only the first one is used, the dupes are marked as such to prevent breakage later.

Publish the full KSP.log and a craft file with the rogueduplicate and I will locate the rogue patch for you. With that information, you can reach the Add'On maintainer or, if he/she is not reachable, we can try a HOTFIX.

 

1 hour ago, majNUN said:

Here are my fatalities.

Usually, the full KSP.log is needed for diagnosis. But on this case, I already know what's happening - you unzipped the new TweakScale version over an old one, with an old file that was deprecated still there. Completely delete the TweakScale folder and install the latest again and you will be fine!

[TranceaddicT]

21 minutes ago, Lisias said:

It's not a problem on TweakScale. You have a rogue patch somewhere shoving twice the whole TweakScale config section. TweakScale detects this situation, and once it's deterministic that only the first one is used, the dupes are marked as such to prevent breakage later.

Publish the full KSP.log and a craft file with the rogueduplicate and I will locate the rogue patch for you. With that information, you can reach the Add'On maintainer or, if he/she is not reachable, we can try a HOTFIX.

 

Usually, the full KSP.log is needed for diagnosis. But on this case, I already know what's happening - you unzipped the new TweakScale version over an old one, with an old file that was deprecated still there. Completely delete the TweakScale folder and install the latest again and you will be fine!

I do enjoy when you do these deep dives.  They teach me what to look for.

[Azic Minar]

From following this thread and a few others, like @JadeOfMaar and @OhioBob, I've learned a good bit about how KSP works. Enough to understand half of my problems and be dangerous to my own save. Though I still need to ask for help from time to time!

[renejant]

11 hours ago, Lisias said:

It's not a problem on TweakScale. You have a rogue patch somewhere shoving twice the whole TweakScale config section. TweakScale detects this situation, and once it's deterministic that only the first one is used, the dupes are marked as such to prevent breakage later.

Publish the full KSP.log and a craft file with the rogueduplicate and I will locate the rogue patch for you. With that information, you can reach the Add'On maintainer or, if he/she is not reachable, we can try a HOTFIX.

Here is the link to my ksp log and craft file:

https://renejant36.porton.nl:7001/sharing/p76fUquQj

[Lisias]

14 hours ago, renejant said:

Here is the link to my ksp log and craft file:

https://renejant36.porton.nl:7001/sharing/p76fUquQj

Whoa.... Your craft have 144 Rogue TweakScale sections! (from the 752 Parts used). Gosh. 

First, the good news: this is annoying, but right now is not dangerous. Nothing bad will happens.

BUT

Your kind of rogue patching is the dangerous one, both sections have different receipts! Look what I have for SYdecouplerRadial1_4290221204 :

        MODULE
        {
                name = TweakScale
                isEnabled = True
                currentScale = 2
                defaultScale = 1
                defaultTransformScale = (1, 1, 1)
                DryCost = 7104
                stagingEnabled = True
                EVENTS
                {
                }
                ACTIONS
                {
                }
                UPGRADESAPPLIED
                {
                }
        }

        MODULE
        {
                name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section.
                isEnabled = True
                currentScale = 1
                defaultScale = 1
                defaultTransformScale = (0, 0, 0)
                DryCost = 888
                stagingEnabled = True
                EVENTS
                {
                }
                ACTIONS
                {
                }
                UPGRADESAPPLIED
                {
                }
        }

currentScale , defaultTransformScale and DryCost are different between the the used and the rogue section.

This means that if we 'fix" the patch that patched it first (let's suppose a toe stomping patch from an Add'On those name starts with "S" - they are patched earlier than TweakScake ones on the LEGACY pathing phase), all your crafts and savegame will be corrupted, like this:

Do you see why I code these pesky warnings now?

On the bright side, after running a report on your log file, it ends up that only two parts are, effectively, being rogue patched - so it just happened that you used that parts a lot.

macmini62:1 lisias$ cat KSP.log | grep -oP "Duplicate TweakScale .+\[(.+)\]" | sort -u
Duplicate TweakScale module on part [SYdecouplerRadial1]
Duplicate TweakScale module on part [SYejectatron]

This make things way easier.

This is the patching for the SYdecouplerRadial1 :

[LOG 23:15:54.232] Applying update ModRocketSys/Patches/MRS_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:15:54.564] Applying update SpaceY-Lifters/Patches/0_TechTree/@PART[SY*]:NEEDS[!CommunityTechTree&!HPTechTree] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:15:54.612] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:16:02.889] Applying update 999_KSP-Recall/patches/resourceful/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:16:02.983] Applying update BetterBurnTime/SRBurnTime/@PART[*]:HAS[@RESOURCE[SolidFuel],@MODULE[ModuleEngines]:HAS[@PROPELLANT[SolidFuel]]]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:16:03.180] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]

From this report, I learn that SYdecouplerRadial1 is a part from SpaceY Lifters. And that this fine Add'On has its own TweakScale patches (there're no embedded support for them on TweakScale). However, the ModRocketSys Add'On also patches this part - and this is where things get hairy as they are being applied before the canonical ones from the SpaceY. Messy.

Since no one of the involved Add'Ons have git public repositories, I will need to download them to eyeball the patches - what I cannot do right now on working time. I will go back to this issue later, don't worry.

Right now, DO NOTHING. I will code a custom HOTFIX to you in order to have this sorted out for you, and then I will see what can be done to solve the problem for everybody on the Add'On themselves.

Stay tuned!

@renejant, here is your HotFix.

• Download this file (click on the Raw button!)
  • or copy and paste the contents of this box into notepad or some other text editor:

  • @PART[SYdecouplerRadial1,SYejectatron]:NEEDS[SpaceY-Lifters,ModRocketSysLite]:FINAL // Space-Y Radial Decoupler, regular
    {
    	-MODULE[TweakScale],* { }
    	%MODULE[TweakScale]:NEEDS[TweakScale]
    	{
    		type = surface
    		HOTFIX = https%3A%2F%2Fforum.kerbalspaceprogram.com%2Findex.php%3F%2Ftopic%2F179030-ksp-141-tweakscale-under-lisias-management-24315-2020-0622%2F%26do%3DfindComment%26comment%3D3812504
    	}
    }

     

• Save the file on somewhere inside your GamData
  • I strongly suggest GameData/__LOCAL/TweakScale/HotFixes , so it's easy to keep track of any hotfixes and to get rid of them when needed.

Essentially, this patch deletes any TweakScale support from the affected parts and install a fresh copy, based on the SpaceY-Lifters (identical to the rogue patch on ModRocketSysLite).

This will fix your issue, but there's one caveat: if anyone else repatches that part, even by following every good practice, this patch will obliterate any change and brute force that one instead. Ideally, this should be removed from your instalment as soon as ModRocktSysLite is fixed so you don't have to keep remembering about it.

Cheers!

 

Edited July 2, 2020 by Lisias
Added the HotFix

[Lisias]

NOTAM

I did a very minimalist smoke test on KSP 1.10 and TweakScale 2.4.3.15 (clicking on Cancel on the Houston).

Apparently TweakScale 2.4.3.15 is working fine, and KSP-Recall appears to be not needed on 1.10.

In a way or another, this was a preliminary test - there're a lot of things I want to test first before lifting the Houston for KSP 1.10 - if you decide to try it, please, pretty please, make backups of everything!

My findings on the matter will be published on TweakScale's Issue #115: https://github.com/net-lisias-ksp/TweakScale/issues/115

-- -- -- post edit -- -- --

Clicking ok Ok closes the game by design. It's not a bug. I did this way because people usually just clicks on OK without reading, and Houstons were made to prevent people from running a potentially problematic game without being aware of the problem.

 

Edited July 1, 2020 by Lisias
post edit

[renejant]

6 hours ago, Lisias said:

Whoa.... Your craft have 144 Rogue TweakScale sections! (from the 752 Parts used). Gosh. 

First, the good news: this is annoying, but right now is not dangerous. Nothing bad will happens.

BUT

Your kind of rogue patching is the dangerous one, both sections have different receipts! Look what I have for SYdecouplerRadial1_4290221204 :

        MODULE
        {
                name = TweakScale
                isEnabled = True
                currentScale = 2
                defaultScale = 1
                defaultTransformScale = (1, 1, 1)
                DryCost = 7104
                stagingEnabled = True
                EVENTS
                {
                }
                ACTIONS
                {
                }
                UPGRADESAPPLIED
                {
                }
        }

        MODULE
        {
                name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section.
                isEnabled = True
                currentScale = 1
                defaultScale = 1
                defaultTransformScale = (0, 0, 0)
                DryCost = 888
                stagingEnabled = True
                EVENTS
                {
                }
                ACTIONS
                {
                }
                UPGRADESAPPLIED
                {
                }
        }

currentScale , defaultTransformScale and DryCost are different between the the used and the rogue section.

This means that if we 'fix" the patch that patched it first (let's suppose a toe stomping patch from an Add'On those name starts with "S" - they are patched earlier than TweakScake ones on the LEGACY pathing phase), all your crafts and savegame will be corrupted, like this:

 

Do you see why I code these pesky warnings now?

On the bright side, after running a report on your log file, it ends up that only two parts are, effectively, being rogue patched - so it just happened that you used that parts a lot.

macmini62:1 lisias$ cat KSP.log | grep -oP "Duplicate TweakScale .+\[(.+)\]" | sort -u
Duplicate TweakScale module on part [SYdecouplerRadial1]
Duplicate TweakScale module on part [SYejectatron]

This make things way easier.

This is the patching for the SYdecouplerRadial1 :

[LOG 23:15:54.232] Applying update ModRocketSys/Patches/MRS_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:15:54.564] Applying update SpaceY-Lifters/Patches/0_TechTree/@PART[SY*]:NEEDS[!CommunityTechTree&!HPTechTree] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:15:54.612] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:16:02.889] Applying update 999_KSP-Recall/patches/resourceful/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:16:02.983] Applying update BetterBurnTime/SRBurnTime/@PART[*]:HAS[@RESOURCE[SolidFuel],@MODULE[ModuleEngines]:HAS[@PROPELLANT[SolidFuel]]]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]
[LOG 23:16:03.180] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1]

From this report, I learn that SYdecouplerRadial1 is a part from SpaceY Lifters. And that this fine Add'On has its own TweakScale patches (there're no embedded support for them on TweakScale). However, the ModRocketSys Add'On also patches this part - and this is where things get hairy as they are being applied before the canonical ones from the SpaceY. Messy.

Since no one of the involved Add'Ons have git public repositories, I will need to download them to eyeball the patches - what I cannot do right now on working time. I will go back to this issue later, don't worry.

Right now, DO NOTHING. I will code a custom HOTFIX to you in order to have this sorted out for you, and then I will see what can be done to solve the problem for everybody on the Add'On themselves.

Stay tuned!

 

Thanks alot Lisias!  I see what you mean now... i was trying to search for the problem myself, but couldn't see it... (still alot is abacadabra for me)...  And yes, i do use those parts alot because i find them the best parts there are. compared to the standard ones ingame...  I can still play with those pesky warnings but it gets annoying after some time, when you see it everytime you try to load a ship into the VAB... 

I will wait patiently for your custom hotfix... Thanks for clearing this up and providing a hotfix!

Edited July 1, 2020 by renejant

[Lisias]

4 hours ago, renejant said:

Thanks alot Lisias!  I see what you mean now... i was trying to search for the problem myself, but couldn't see it... (still alot is abacadabra for me)...  And yes, i do use those parts alot because i find them the best parts there are. compared to the standard ones ingame... 

Welcome! It's not that hard, after some months working on it. The hard part is the start, but once you find yourself on that jungle, things snap in on your head and everything become easier.

 

4 hours ago, renejant said:

 I can still play with those pesky warnings but it gets annoying after some time, when you see it everytime you try to load a ship into the VAB... 

It's annoying, but that's all. (Potentially) Bad things fires up a "Houston". There's a colour code on TweakScale warnings:

• Red (the "Houstons"): dude, you may have problems. Cry for help here, TweakScale will prompt you to close KSP (but you can override it).
• Yellow : things that you are not going to like, but it's harmless (as unsupported parts having TweakScale uninstalled).
• White : things you need to remember.

Every time Module Manager redoes the patch's cache, the Yellow and White ones will be issued while loading KSP until the cache is 1 hour old, and then they will not bother you anymore - until you change something and Module Manager redo the cache again.

 

4 hours ago, renejant said:

I will wait patiently for your custom hotfix... Thanks for clearing this up and providing a hotfix!

Done! I wrote it on the post above to keep the explanation and the solution on a single post (useful to people that finds it using the Search function - as me, as I usually forgot things and need to search my own thread for information!! ).

Cheers!

Edited July 2, 2020 by Lisias
Eternal Typos from the Englishless Mind.

[renejant]

Thanks m8! applying the hotfix now as im writing this...!

[renejant]

@Lisias I am sorry to say this to you but your "hotfix" was a failure... After i had implemented it, i loaded up the game, tried to load a craft. But the main problem still existed! Then i looked at your "fix" and then i saw it, you had made a little mistake in naming the directory in your fix.

Quote

@PART[SYdecouplerRadial1,SYejectatron]:NEEDS[SpaceY-Lifters,ModRocketSysLite]:FINAL // Space-Y Radial Decoupler, regular
{
	-MODULE[TweakScale],* { }
	%MODULE[TweakScale]:NEEDS[TweakScale]
	{
		type = surface
		HOTFIX = https%3A%2F%2Fforum.kerbalspaceprogram.com%2Findex.php%3F%2Ftopic%2F179030-ksp-141-tweakscale-under-lisias-management-24315-2020-0622%2F%26do%3DfindComment%26comment%3D3812504
	}
}

@PART[SYdecouplerRadial1,SYejectatron]:NEEDS[SpaceY-Lifters,ModRocketSysLite]:FINAL // Space-Y Radial Decoupler, regular {

 In the above code i have removed the "Lite" part, after that, i reloaded the game and then i got a message saying there were 2 hotfixes detected, so i resumed the game and then when i loaded the craft, same problem still came up and even worse, all the textures of the desired parts (decoupler & ejectatron)  were "blown" up to epic proportions... So i quited the game right after that, removed your fix and everything was back to its previous state when i reloaded the game after that.

After this conclusion, i was thinking, what if, i say what if:

I removed one of those patches in the Spacey Lifter part or the Modrocketsys directory? Will it help? Or do i make it worse??? Just thinking along here...

Edited July 3, 2020 by renejant
specifiying the part

[Lisias]

4 hours ago, renejant said:

@Lisias I am sorry to say this to you but your "hotfix" was a failure...

Humm. Interesting. I tested it before publishing the stunt...

 

4 hours ago, renejant said:

After i had implemented it, i loaded up the game, tried to load a craft. But the main problem still existed! Then i looked at your "fix" and then i saw it, you had made a little mistake in naming the directory in your fix.

@PART[SYdecouplerRadial1,SYejectatron]:NEEDS[SpaceY-Lifters,ModRocketSysLite]:FINAL // Space-Y Radial Decoupler, regular {

 In the above code i have removed the "Lite" part, after that, i reloaded the game and then i got a message saying there were 2 hotfixes detected,

Humm... I think I downloaded the wrong Add'On then? You see, there's an Add"On called ModRocketSysLite and it is double patching the very same parts...

(hacking into your KSP log)

Yeah. Working late night can be dangerous, by plain lack of luck, Google should had given me ModRocketSysLite when I typed ModRocketSys and I just didn't paid enough attention. Found it here.

Oh well... Look on the bright side: you are learning your way on patching : you detected and fixed a mistake of mine!

 

4 hours ago, renejant said:

i reloaded the game and then i got a message saying there were 2 hotfixes detected, so i resumed the game and then when i loaded the craft, same problem still came up

Yes, it worked. I forgot to mention that you will still get the TweakScaleRogue stunt on crafts and savegames already saved, but once you save them again the HotFix will prevent the new crafts to have the Rogue TweakScale section, and by then the problem is solved.

 

4 hours ago, renejant said:

and even worse, all the textures of the desired parts (decoupler & ejectatron)  were "blown" up to epic proportions... So i quited the game right after that, removed your fix and everything was back to its previous state when i reloaded the game after that.

However... THAT is something new... I just removed a deactivated copy of the TweakScale section on the GameDatabase - and so, TweakScale didn't found anymore a second copy of it on the part, and so it didn't deactivated it by brute force on saving crafts and savegames.

I made this way because, as you probably is getting aware, if someone install a new Add'On those name come first on the alphabetical order, and this Add'On rogue patches an already in use part, then the SECOND COPY of TweakScale would be the one that should be preserved. Doing the way I did at least allows me to manually fix a savegame by removing the first copy and reactivating the second one (and this is just one more reason to use S.A.V.E.!).

However... What you describes is something completely... Awkward. Removing all copies TweakScale support and then shoving back the first one (that is the one your game was using) should not cause this breakage - unless there's something else changing it and I didn't caught it - it was late night, and I already missed an detail, so I can be did missed another one.

 

4 hours ago, renejant said:

After this conclusion, i was thinking, what if, i say what if:

I removed one of those patches in the Spacey Lifter part or the Modrocketsys directory? Will it help? Or do i make it worse??? Just thinking along here...

You would accomplish by "hardware" what the HotFix does by "software". Essentially:

1. ModRocketSys (Lite or not) applies a 'hard' patch for TweakScale on two parts from SpaceY
2. SpaceY correctly applies a 'hard patch' on these two parts again
   1. Correctly because it owns that parts - the owner applies a 'hard' patch, everybody else applies 'soft' patches.
3. The HotFix deletes the previous two patches, and reapply a hard patch mimicking the one ModRocketSys applied

And the aftermath is that you have a "sane" GameDatabase where the "rogue patch infection" is not spreaded anymore on crafts and savegames - what would be the exact result you will get by manually deleting one of the copies of the patches. The HotFix aims to allow you a sane GameDatabase without having to edit third parties patches (what would be nullified on each Add'On update).

Of course, it worths a try (really, make backups of everything). But I can foresee two possible results:

1. you edit the patch, things explodes the same, and we end up confused about the reason of the explosion
2. you edit the patch, things work fine, and we ended up confused about the reason the HotFix (allegedly) caused the explosion
   1. Allegedly because something else could had happened by coincidence (or by side effect), and perhaps we have a new problem do diagnose!

In a way or another, I'm giving a second look on your case. I'm puzzled about it, there's something else happening where I can't see.

-- -- -- POST EDIT -- -- -- 

I think I found something....

This is the patch for SYejectatron on Space-Y:

@PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron
{
        MODULE
        {
                name = TweakScale
                type = surface
        }
}

And this is the patch for it on ModRocketSys (Lite or not):

@PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
        MODULE
        {
                name = TweakScale
                type = surface
        }
}

And that behaviour changes something - only the mass exponent, but changes something. It still doesn't explains the textures being blown up, however. I updated the hotfix to cope with that, by the way.

I'm still working on it.

Edited July 3, 2020 by Lisias
post edit

[renejant]

Quote

I think I found something....

This is the patch for SYejectatron on Space-Y:

@PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron
{
        MODULE
        {
                name = TweakScale
                type = surface
        }
}

And this is the patch for it on ModRocketSys (Lite or not):

@PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
        MODULE
        {
                name = TweakScale
                type = surface
        }
}

And that behaviour changes something - only the mass exponent, but changes something. It still doesn't explains the textures being blown up, however. I updated the hotfix to cope with that, by the way.

I'm still working on it.

Applied your new *fix*, still the same result, textures blown up... but then i tried removing one of those patches mentioned in the Spacey / Modrocketsys directory, still same result...

After that i tried moving the whole ModrocketSys directory out of the game, then the textures where blown up again... But if i let the 2 coexist with eachother, everything is back to "normal" (except the TweakScaleRogueDuplicate problem)

So this got me thinking, is there some other mod trying to modify those parts?

I have to say  that this confuses me alot!

[Lisias]

6 hours ago, renejant said:

Applied your new *fix*, still the same result, textures blown up... but then i tried removing one of those patches mentioned in the Spacey / Modrocketsys directory, still same result...

After that i tried moving the whole ModrocketSys directory out of the game, then the textures where blown up again... But if i let the 2 coexist with eachother, everything is back to "normal" (except the TweakScaleRogueDuplicate problem)

Oukey, this calms me down. A problem I understand is a problem I can fix. The previous situation, on the other hand, was baffling me. =P

 

6 hours ago, renejant said:

So this got me thinking, is there some other mod trying to modify those parts?

Right now, it's the only remaining option. Publish your current KSP.log and I will try to hunt it. Also, install ModRocketSysLite just to see what happens.

 

6 hours ago, renejant said:

I have to say  that this confuses me alot!

Welcome to the KSP Modding Club. Take a nice chair, you are going to stay around for some time.

[xD-FireStriker]

2 hours ago, Lisias said:

9 hours ago, renejant said:

I have to say  that this confuses me alot!

Welcome to the KSP Modding Club. Take a nice chair, you are going to stay around for some time.

I have been playing KSP since 2014 and started to get into modding this year cause of the free time. Boi when you finish writing a patch only to have nothing work you step back and ask your self what the heck did I miss. I’m currently trying to fix the syntax on a FS Fuel Swap patch and comparing it to the guides it shouldn’t even be erroring.

KSP modding is very confusing but rewarding, I enjoy writing patches.

I found Darkmode N++ and a somewhat working KSP language so I am now officially in it for the long hawl.

Edited July 3, 2020 by xD-FireStriker
Autocorrect needs to die

[Lisias]

2 hours ago, Souptime said:

Wait im using interstellar fuel switch? hmmm...

well @Lisias thanks! imma go try it EDIT: nope, still dont work

Now I need you new KSP.log to try to understand what's happening.

I moved the conversation to TweakScale's thread to avoid cluttering Kopernicus one.

(original post here).

 

1 hour ago, xD-FireStriker said:

Autocorrect needs to die

I second that!

[Souptime]

ight

https://drive.google.com/file/d/16unb5dQwmb1QCR1a1hl5qy0hFcoByaxq/view?usp=sharing

@Lisias

[Souptime]

AFK 15-ish minutes

ssshshhhhhhhhIIIIIIIIIIIIIIIDDDDDDDDDDDDDDDD IT WORKIN NOW OY HAAAAAAAAAA

sometyimes mods just dont work on the first few tries i dunno

thanks for yalls help!