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

[Lisias]

8 hours ago, falcoon said:

@Lisias Remember my question about exploding ship ?

Just for the sake of completude, this is the video where the problem happens:

Spoiler

 

This is remarkably similar to the very first really nasty bug that had bitten me. Some time after the craft exploding, nearby statics exploded too!

Spoiler

https://forum.kerbalspaceprogram.com/index.php?/topic/178301-contos-de-kerbol/&do=findComment&comment=3470909

 

You are using S.A.V.E. - GOOD!

What I found on your KSP.log was a Toe Stomping Fest between TweakScale and IFS. I can't say who is the stomper, as it's usual that an additional Add'On is the one getting in the way - in a way or another, is not a fail on an Add'On, there's no culprit on this. It's a failing on collaborating to each other, a collective bork.

The easiest way to check this is uninstalling IFS or TweakScaling so we could confirm at least two of the Screaming Victims - but tha would probably render your test bed useless.

There's another way, and it is to check for the collateral effects on the logs. Please fire up your KSP and reproduce the problem on a backup savegame, finish KSP and then publish KSP.log and output_log.txt from Unity's. This time I need both.

You will find the instructions on this thread, but I will reproduce the interesting bits below:

Quote

• Windows: KSP_win\KSP_Data\output_log.txt (32bit) or KSP_win64\KSP_x64_Data\output_log.txt (64bit) or %USERPROFILE%\AppData\LocalLow\Squad\Kerbal Space Program\output_log.txt
• Mac OS X: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log )
• Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

 

[falcoon]

25 minutes ago, Lisias said:

There's another way, and it is to check for the collateral effects on the logs. Please fire up your KSP and reproduce the problem on a backup savegame, finish KSP and then publish KSP.log and output_log.txt from Unity's. This time I need both.

Should I run it with your beta tweakscale or with regular one?

Edit:

nvm, i run it with beta version as had it already installed

ksp log

output log

@Lisias

Edited July 7, 2019 by falcoon

[Lisias]

9 hours ago, falcoon said:

nvm, i run it with beta version as had it already installed

Interesting. The output_log is clean. It shows you pausing the game and other unrelated actions, absolutely nothing abnormal. Well, the good news is that we are not injecting garbage into the Physics Engine as I was fearing.

I found this, however:

[WRN 18:06:04.403] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 1.
Node 'TweakScale' found in loaded data, but 'InterstellarFuelSwitch' is defined in prefab.
Looking for TweakScale in other indices...
[WRN 18:06:04.403] ...TweakScale module found at index 10.
[WRN 18:06:04.405] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 2.
Node 'InterstellarFuelSwitch' found in loaded data, but 'IFSCryostat' is defined in prefab.
Looking for InterstellarFuelSwitch in other indices...
[WRN 18:06:04.405] ...InterstellarFuelSwitch module found at index 1.
[WRN 18:06:04.405] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 9.
Node 'IFSCryostat' found in loaded data, but 'ModuleFuelJettison' is defined in prefab.
Looking for IFSCryostat in other indices...
[WRN 18:06:04.405] ...IFSCryostat module found at index 2.
[WRN 18:06:04.405] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 10.
Node 'ModuleFuelJettison' found in loaded data, but 'TweakScale' is defined in prefab.
Looking for ModuleFuelJettison in other indices...
[WRN 18:06:04.405] ...ModuleFuelJettison module found at index 9.

It appears to be the aftermath of a Toe Stomping Fest. This is happening for fuelTank.long and adapterSize2-Size1 too.

I also found:

[WRN 18:06:03.612] [TweakScale Warning] No valid member found for mass in TweakScale
TweakScale.Tools:LogWf(String, Object[])
TweakScale.MemberUpdater:Create(Object, String)
TweakScale.ScaleExponents:UpdateFields(Object, Object, ScalingFactor, Part)
TweakScale.ScaleExponents:UpdateObject(Part, Part, Dictionary`2, ScalingFactor)
TweakScale.TSGenericUpdater:OnRescale(ScalingFactor)
TweakScale.TweakScale:CallUpdaters()
TweakScale.TweakScale:Setup()
TweakScale.TweakScale:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ProtoPartModuleSnapshot:Load(Part, Int32&)
ProtoPartSnapshot:Load(Vessel, Boolean)
ProtoVessel:LoadObjects()
Vessel:Load()
Vessel:Update()

What hints me that something is, indeed, wrong while initializing things. This message doesn't tells me the part, however. I need to fix that log. I need the part's name in order to know where to look for problems.   Mass is a very important thing on Physics Engine. I think something would be logged on the output_log if anything gone wrong on that level, but things change between KSP versions, logging included, so I will not rule this out for now.

There're no conclusions on the problem yet. I need to spend some more time doing tests, but at least I have a start point.

Did you used Size1p5.Tank.01, fuelTank.long and adapterSize2-Size1 on any of the vessels on that flight?

— — — POST EDIT — — — 

[Forget everything below. I detected the problem, and it's a very stupid one!  It's a problem to me, however, as I still need to check the integrity of every part]

Spoiler

I didn't dug enough. Found this on the TweakScale's initialization phase :

[ERR 18:00:40.471] [TweakScale] part=IfsWrapperTank96 (Wrapper Droptank (Large)) Exception on Sanity Checks: System.NullReferenceException:
  at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0

There are some Toe Stomping Fest for sure. Point.

It can be or not related to your problem, but this should be handled nevertheless.

— — — POST - POST - EDIT — — — 

IFS is the Screaming Victim on this. There's nothing on the source code or the patches that could remotely stomp on anyone's toes. Au contraire, the thing is almost bullet proof and self-sufficient.

Something else is getting into the way.

— — — POST - POST - POST - EDIT — — — 

IfsWrapperTank96 is borking on my installment too. But it's borking while checking for ShowStoppers, not on the SanityChecks. In a way or another, I have something more solid to work now!]

 

Edited July 8, 2019 by Lisias
Uh… Yep, I chase ghosts again. =P

[falcoon]

8 hours ago, Lisias said:

Did you used Size1p5.Tank.01, fuelTank.long and adapterSize2-Size1 on any of the vessels on that flight?

Can't say 100% sure, because these are not in-game names, but I'm 99% sure all 3 were in use.
 

[Lisias]

17 hours ago, falcoon said:

Can't say 100% sure, because these are not in-game names, but I'm 99% sure all 3 were in use.

Yet a one more small enhancements to the Logs. Add the part's Title.

The U.I. name for the mentioned parts are:

• Size1p5.Tank.01 : FL-TX220 Fuel Tank (Making History)
• fuelTank.long : FL-T800 Fuel Tank (Stock)
• adapterSize2-Size1 : C7 Brand Adapter - 2.5m to 1.25m (Stock)

[viperwolf]

I was reading threw some post trying to find the conversation about the tweakscale with the new robotics parts. I cannot remember where it was, If i remember correctly, the only problem was the strengths did not scale right? Example: If you made the robotic hinge smaller, it would still carry the stock strength? If that was the only problem, how do you apply tweakscale to the robotics parts?  Or did i miss something major?

[Lisias]

3 hours ago, viperwolf said:

I was reading threw some post trying to find the conversation about the tweakscale with the new robotics parts. I cannot remember where it was, If i remember correctly, the only problem was the strengths did not scale right? Example: If you made the robotic hinge smaller, it would still carry the stock strength? If that was the only problem, how do you apply tweakscale to the robotics parts?  Or did i miss something major?

From that time to nowadays I further improved the concept. I documented my current thoughts on this issue:

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

The good news on this is that Robotics doesn't uses mass on the MODULEPARTVARIANT, so this is not a blocker to implement TweakScale patches to the Robotics parts.

Keep in mind that all of this is pure Research at the moment. So things can plain go through the tubes without previous warning. There're a lot to be learnt about it yet.

Edited July 9, 2019 by Lisias
got too bold on a statement :P

[Annastasya]

First off let me say thank you @Lisias for taking things over and all of your dedication to upgrade TS as well as assist with fixing other Mod's patches that aren't following the most up-to-date rule set for MM and TS.

 

* * * EDIT: MK2SE Has updated and fixed the issue by making their patch play by the rules. Please feel free to ignore the following ramble unless you just need a good laugh at a newb! * * *

For some reason CKAN didn't actually download the new update when I told it to. And yes, I am one of those people!

Yesterday I spent a depressingly long amount of time updating mods. (My mod count is roughly twice "way too many" so please know that I have no intentions on dropping error logs at your doorstep!) Once KSP finally loaded up, (it takes quite a while sadly...) I almost fell out of my chair when TS warned me of 60+ "Fatal" errors! All of which appear to be the #34 issue and all but 1 of which are from MK3 Stockalike Expansion, the 1 other is from MK2 Stockalike Expansion. I've read through the 23 pages of this forum for TS and I think I understand a good chunk of it but I'm not entirely sure how to completely fix the issues I am seeing. (For now I have removed the MK3SE though it saddens me.)

From what I've seen here it looks like two issues, 1) Those mods have there own version of TS they call for. This problem is negated however since I trim out outdated included sub-mods. Personally I also think it is bad form to include someone else's mod work with your own unless expressly permitted by the other mod creator and only when absolutely necessary, which in this case doesn't seem to be the case in regard to the necessity. and 2) The issue seems to be from both TS and the other mods attempting to apply TS to the problematic parts. That being said it appears there may be a few solutions I can implement on my part...if I can figure out the best way to do it without summoning the Kraken.

I was able to track down the mods and the actual parts causing the issue but I'm not quite sure of the correct implementation to resolve it. For example in MK2SE the offending part is "MX2_Endcap" (or "MX2.Endcap" as reported in the log, which I read earlier here that MM changes "_" to "." for some reason or another.) The config file for TS in MK2SE for that part is as follows:

Spoiler

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

From what I have read here it seems there could be a few ways for me to tackle it such as removing this section from the M2XTweakscale.cfg file and letting TS do what it needs without interference, maybe changing ":NEEDS" to ":FOR" or maybe making a change and putting it with TS's patches itself. I don't really know if any of these will work and if they do, which is the better route to go.

Any advice would be greatly appreciated!

Edited July 9, 2019 by Annastasya
Issue has been resolved!

[Annastasya]

I did also post a comment on GitHub - Mk4 System Patch (duplicate) #58. I didn't want to start a new issue since it is already partially addressed. Even after your changes to MarkIVSystem_TweakScale.cfg I am still seeing 3 Fatal errors reported by TS from the Shoulder parts listed at the bottom of the file. (mk4cockpit-shoulder-1, mk4cockpit-shoulder-2, mk4cockpit-shoulder-3) Following your edit on GitHub I changed line 241 to: 

Spoiler

@PART[mk4cockpit-shoulder-1,mk4cockpit-shoulder-2,mk4cockpit-shoulder-3] //

This change removed the 3 fatal errors that I was seeing. I hope this helps make bug smushing easier!

[Lisias]

Thanks, @Annastasya! I will give a look on your fixes on the WeekEnd!  

(And to think they told me this week would be easy… hehe… I was trying to read your posts for the last 18 hours!  )

— post edit --

In some other weekend, as it appears.  But I will look on it.

Edited July 17, 2019 by Lisias
post edit.

[Lisias]

On 6/11/2019 at 4:34 PM, FreeThinker said:

@Lisias Its a new part which contains the following

	MODULE
	{
		name = ModuleGenerator

        	isAlwaysActive = false
        	requiresAllInputs = true
        	startEventGUIName = Start Power Conversion
        	endEventGUIName = Stop Power Conversion

		INPUT_RESOURCE
		{
			name = Megajoules
			rate = 0.025
		}
		OUTPUT_RESOURCE
		{
			name = ElectricCharge
			rate = 25
		}
	}

When unscalled it correctly convert Megajoules in ElectricChange but when scalled up, the input remains the same while the output scaled up with cube

Edet: I tried to modify the tweakscale into

TWEAKSCALEEXPONENTS
{
    name = ModuleGenerator        // Stock RTG

    inputResources
    {
       rate = 3
    }

    outputResources
    {
       rate = 3
    }
}

but it doesn't work

I finally got myself together on this issue.

What's happening is that Module Generator doesn't consume resources. It generates them from nothing, and that's it.  You can check this on the only two stock parts that use it:

• ./Squad/Parts/Electrical/RTG/RTG.cfg
• ./Squad/Parts/Utility/launchClamp1/launchClamp1.cfg

What you need to to appears to be doable using ModuleResourceConverter. Check ./Squad/Parts/Resources/FuelCell/FuelCell.cfg for an example.

 

 

[Lisias]

On 7/9/2019 at 7:30 AM, Annastasya said:

<cut by me>

* * * EDIT: MK2SE Has updated and fixed the issue by making their patch play by the rules. Please feel free to ignore the following ramble unless you just need a good laugh at a newb! * * *

< cut by me>

I almost fell out of my chair when TS warned me of 60+ "Fatal" errors! All of which appear to be the #34 issue and all but 1 of which are from MK3 Stockalike Expansion, the 1 other is from MK2 Stockalike Expansion.

Dude, my career savegame had 182.  I managed to drop it to 172, and I'm still fighting

 

On 7/9/2019 at 7:30 AM, Annastasya said:

I've read through the 23 pages of this forum for TS and I think I understand a good chunk of it but I'm not entirely sure how to completely fix the issues I am seeing. (For now I have removed the MK3SE though it saddens me.)

Sometimes, it's a third party Add'On that messes up, and we end up solving the problem by "fixing" the Screaming Victim and not the perpetrator. Since I'm using MK3SE on my gaming, and I think I have this too there, I will pursue this for sure in the near (hopefully) future.

 

On 7/9/2019 at 7:30 AM, Annastasya said:

From what I've seen here it looks like two issues, 1) Those mods have there own version of TS they call for. This problem is negated however since I trim out outdated included sub-mods. Personally I also think it is bad form to include someone else's mod work with your own unless expressly permitted by the other mod creator and only when absolutely necessary, which in this case doesn't seem to be the case in regard to the necessity. and 2) The issue seems to be from both TS and the other mods attempting to apply TS to the problematic parts. That being said it appears there may be a few solutions I can implement on my part...if I can figure out the best way to do it without summoning the Kraken.

<cut by me>

From what I have read here it seems there could be a few ways for me to tackle it such as removing this section from the M2XTweakscale.cfg file and letting TS do what it needs without interference, maybe changing ":NEEDS" to ":FOR" or maybe making a change and putting it with TS's patches itself. I don't really know if any of these will work and if they do, which is the better route to go.

Any advice would be greatly appreciated!

1) Some Add'Ons choose to pack the dependencies on the distribution ZIP to make things easier to manual installers. As long as they have a .version file pinpointing to the correct place where updates are published, I don't see really a problem. I can't talk for any other Add'On Author, but I stick to the License - if the License allows, the permission is already granted.

Things get hairy only when the Add'On being packed is tampered somehow (with local fixes on the patches or code). While some Licenses allow it (and, so, such permission is already granted), the Packager must state clearly that such Add'On was modified, and should support him/herself the thing - otherwise, people would file bugs to the original Add'On Author/Maintainer, what's inconvenient to say the least.

2) Exactly, you nailed it. But TweakScale is not always involved, there're third-party patches (most of them somewhat aged already) that apply patches for parts that TweakScale does't supports, and then that older patches change some Add'On part that got TweakScale support from the Author on a later date. And then we have a Kraken Feast.  

3) :FOR is to be used to the "Canonical" Maintainer of the Add'On/Patch. Since TweakScale directly support some Add'ons itself, I'l use ":FOR" on these parts soon. :NEEDs, so, is to be used by everybody else.

Check the Orthodox Development Branch - you can check the Beta Releases Issue for the most recent Betas if you want to take some risks and help me on the testing! I didn't releases these new patches yet due a somewhat numerous quantity of Add'Ons that would break with then, and this is precisely the reason I'm implementing the Sanity Checks and Warnings et all before doing it. I need to pave a way out of the mess, or people's savegames will be broken...

[FreeThinker]

7 hours ago, Lisias said:

I finally got myself together on this issue.

What's happening is that Module Generator doesn't consume resources. It generates them from nothing, and that's it. 

No, it is currently used that way by stock parts, but it is capable of consumption.

[Lisias]

6 hours ago, FreeThinker said:

No, it is currently used that way by stock parts, but it is capable of consumption.

That caught me with my pants down. I don't see a need for a ModuleGenerator that consumes resources with ModuleResourceConverter available - but things are what things are. I'm surely out of context anyway.

I have a concern about stablished behaviour. If the module is able to consume, so it's a fact that TweakScale needs to scale the behaviour. But since it never has scaled it before, and since Stock doesn't use it (and then most people follow suit on it), changing this now on a minor revision is unwise, as a lot of people suddenly will have their resources being consumed way faster then before.

What about a new TWEAKSCALEBEHAVIOR? A "ModuleGeneratorExtended" for the ones willing to use it this way, but without affecting people that never had to cope with this before?

Edited July 20, 2019 by Lisias
tyop! Surprised?

[FreeThinker]

2 hours ago, Lisias said:

That caught me with my pants down. I don't see a need for a ModuleGenerator that consumes resources with ModuleResourceConverter available - but things are what things are. I'm surely out of context anyway.

I have a concern about stablished behaviour. If the module is able to consume, so it's a fact that TweakScale needs to scale the behaviour. But since it never has scaled it before, and since Stock doesn't use it (and then most people follow suit on it), changing this now on a minor revision is unwise, as a lot of people suddenly will have their resources being consumed way faster then before.

What about a new TWEAKSCALEBEHAVIOR? A "ModuleGeneratorExtended" for the ones willing to use it this way, but without affecting people that never had to cope with this before?

I don't understand your reasoning.  It might not be used by stock but there are mods that do use it but most of the time don't support tweakscale. However when a tweakscale configuration is added, it doesn't function correctly when scalled where is consumes too much or too little. Often times this is goed unnoticed, but with life support mods it can becomes a major problem where Kerbals can die. Another  reason why I use this partmodule rather then resource converter is because it  is support by many mods that do some kind of power management. So I think you can add tweakscale support for input  resources without any risk. So please save the lives of Kerbals by fixing it.

Edited July 20, 2019 by FreeThinker

[Lisias]

14 hours ago, FreeThinker said:

I don't understand your reasoning.  It might not be used by stock but there are mods that do use it but most of the time don't support tweakscale. However when a tweakscale configuration is added, it doesn't function correctly when scalled where is consumes too much or too little. Often times this is goed unnoticed, but with life support mods it can becomes a major problem where Kerbals can die. Another  reason why I use this partmodule rather then resource converter is because it  is support by many mods that do some kind of power management. So I think you can add tweakscale support for input  resources without any risk. So please save the lives of Kerbals by fixing it.

By plain changing an already stablished behaviour, things that is being unnoticed will start to be noticed, while things that is already noticed will be silently fixed.

Historically, unnoticed things starting to be noticed cause nasty consequences that are hard and cumbersome to handle while potentially breaking currently played savegames. I already have my hands full of those that need to change to prevent KSP to crash, so I'm reticent to introduce a new one when another solution is available - even if less convenient for some people (including me).

Add'Ons that doesn't support TweakScale needs support for TweakScale instead of blindly adding new behaviours that can break savegames that use Add'Ons that support TweakScale with the current set of rules. I agree with you that perhaps it would be better if it had be implemented from the beginning, but since Stock parts never used this feature, this passed through and now things are how they are.

That said, I'm not expecting that Add'On Authors will do the job for me. Please list to me the set of Add'Ons that need this and I will gladly add a patch myself, or propose a Pull Request for the ones that already have it and need this change.

The new behaviour is currently implemented and tested on this issue. Third Party Add'Ons that need my intervention will be tacked down on this one.

Edited July 21, 2019 by Lisias
adding issue links

[Critter79606]

@Lisias  Coming back to KSP from a break from playing.  I've updated to ksp 1.7.3, and put the latest tweakscale from github on. 

I got several fatal errors here, and the popup said to post in this forum.

[ERR 20:14:11.915] [TweakScale] **FATAL** Part B9.Structure.HX1.S.HS has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.942] [TweakScale] **FATAL** Part mk4cockpit-shoulder-1 has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.942] [TweakScale] **FATAL** Part mk4cockpit-shoulder-2 has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.942] [TweakScale] **FATAL** Part mk4cockpit-shoulder-3 has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.954] [TweakScale] **FATAL** Part MI.Radial.Wedge.LG.M has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.954] [TweakScale] **FATAL** Part MI.Radial.Wedge.LG.ML has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.954] [TweakScale] **FATAL** Part MI.Radial.Wedge.LG.S has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.
[ERR 20:14:11.954] [TweakScale] **FATAL** Part MI.Radial.Wedge.LG.T has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34.

I've got the ksp log zipped up here https://drive.google.com/uc?export=view&id=1K1J5S1GZaVh8_4QdSsMzKeoUj1Fg-J_9

Is this the right place to put this still?  Is there something in the cfg files I should be looking for to find the duplicates?

Thanks!

[Lisias]

14 minutes ago, Critter79606 said:

@Lisias  Coming back to KSP from a break from playing.  I've updated to ksp 1.7.3, and put the latest tweakscale from github on. 

I got several fatal errors here, and the popup said to post in this forum.

<cut by me>

Is this the right place to put this still?  Is there something in the cfg files I should be looking for to find the duplicates?

Yes, this is the right place. And my apologies for that mandatory "go here" button. I added a Cancel button on the next release.

I'm sorry that you was caught on the Kraken Feast, but unfortunately you are on the risk group: users of classic Add'Ons.

The B9 and MarkIV problems were my fault, and these are fixed already on the Github, pending a release -I'm working on it right now, by the way. Unfortunately, the Munar Industrie's Modular Fuel Tank Expansion was not tackled down yet. Since you are the second one to get hit by this issue this week, I raised the priority on the backlog.

What's happening is that we kinda lose control on patching. There're more than one guy patching the same parts, and not everybody is following the best practices on it. The net result is parts with damaged TweakScale data. Such damage tamper your craft and savegames in a way that when things got straight (or damaged further by another patch), your flying crafts suddenly rescales on the fly - with very nasty consequences. This is the reason I declared this problem a **FATAL** and got a bit pushy on inducing people to complain here.

Right now, your best line of action is to:

1. Replace the following TweakScale files:
   1. GameData/TweakScale/patches/B9_HX.cfg with this file. Click in "Raw" then download the artifact and replace the offending file with it.
   2. GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg with this one. Same thing
2. Delete the following file:
   1. GameData/MunarIndustries/MFTX_TweakScale.cfg

This will keep you safe while I cook the 2.4.3.1 release, to be published in a day or two.

You are somewhat crazy, you can use the 2.5.x Beta Release series - but be advised that there's a chance that these Beta thingies be even worse than the current problems by now.  The good fixes are being back ported (2.3.4.1 will have some), others are not tested enough - keep an eye on this thread for the next hours.

In a way or another, I strongly recommend using S.A.V.E. This would had saved my sorry SAS some months ago when I realized this set of problems on my own career game.  

 

[Lisias]

Fellow Kerbonauts,

TweakScale Beta 2.5.0.7 TEST RELEASE available on the Issue #42 pn the Github. I'm kindly asking for any brave and crazy kerbonaut to help looking for new issues due the changes on the default patchs (the :FOR thingy). And yes, I'm asking twice.  

This new release has all the fixes I'd be working on since the last one, plus some others - including correctly scaling wheels. Now the Rover Max is usable even at 400% scale.  Be aware that crafts with scaled wheels built with this release will probably not behave correctly on any other version of TweakScale (downscaling the wheels will be a problem, as they will be weaker now).

Any information needed for the testing is (or will be as I realize I forgot things) on the issue itself. Binaries will be posted on the Issue too (and in no other place).

Thank you!

WARNING

This can break your KSP, ruin your Windows, kill your pet, offend your mom and poison your kids.  

By the Holy Kerbol that enlighten us, please use this only under my instructions, and only if I ask you to do so! Twice.

TweakScale strongly advises you to use S.A.V.E..

Edited October 10, 2019 by Lisias
Updating beta to 2.5.0.7

[Critter79606]

1 hour ago, Lisias said:

Right now, your best line of action is to:

1. Replace the following TweakScale files:
   1. GameData/TweakScale/patches/B9_HX.cfg with this file. Click in "Raw" then download the artifact and replace the offending file with it.
   2. GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg with this one. Same thing
2. Delete the following file:
   1. GameData/MunarIndustries/MFTX_TweakScale.cfg

 

@Lisias  Thanks for getting back with me so quick!  Did the above, and no more red window

I'll try to make time after work tomorrow to spawn a copy of my kerbal install and get the 2.5.0.3 on it and see how it goes.  I'm about to call it a night.  Should I restore the MunarIndustries.cfg before starting?  I have a 80 kph rover I can test those re-scaled rover wheels with!

Edited July 22, 2019 by Critter79606

[Lisias]

15 hours ago, Critter79606 said:

Nice craft!

 

15 hours ago, Critter79606 said:

Should I restore the MunarIndustries.cfg before starting?  I have a 80 kph rover I can test those re-scaled rover wheels with!

The problem with Munar Industries is that I don't know what the problem is. Yet.

It an be something bad on my own set of patches (some mishaps got through, and I'm fixing as I find them). But there can be also happening on a third-party Add'On (they bork too! ) and then Munar Industries would be the Screaming Victim and not the Perpetrator - and then this stand-up guy us still lingering on your installment waiting for the victim to get back!  

In a way or another, I need to get my filthy claws on the problem. i will do it ASAP.

But you can try - as long you don't start a savegame (new or old), nothing bad happens. With some luck, the new Sanity Checks would get something interesting and help me on the process.

— — POST EDIT — — 

@Critter79606 , I found the problem, fixed it, and proposed a pull request to the maintainer.

In the mean time, you can download this file and replace the current one (if not deleted yet) on installment. Click on 'Raw" to download it.

"Safety First, CASE, remember!"

Edited July 22, 2019 by Lisias
Detected and fixed the problem!!

[Critter79606]

11 hours ago, Lisias said:

 

@Critter79606 , I found the problem, fixed it, and proposed a pull request to the maintainer.

In the mean time, you can download this file and replace the current one (if not deleted yet) on installment. Click on 'Raw" to download it.

"Safety First, CASE, remember!"

@Lisias  Grabbed that file, and it appears to fix it.  I went from 31811 patches applied to 31807, so it obviously eliminated some dupe entries 

Thanks for the quick turn around!

[Machine Maker]

So I updated TweakScale and loaded KSP to play in a save I last played a few months ago and got that "Houston, We have a problem" message. Here is my KSP.log in a gist. Any help either fixing this or making sure this doesn't corrupt my save.

[Lisias]

4 hours ago, Machine Maker said:

So I updated TweakScale and loaded KSP to play in a save I last played a few months ago and got that "Houston, We have a problem" message. Here is my KSP.log in a gist. Any help either fixing this or making sure this doesn't corrupt my save.

Use S.A.V.E. just in the mean time. I'm working on it.

[Machine Maker]

Just now, Lisias said:

Use S.A.V.E. just in the mean time. I'm working on it.

Ok, will do.