[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[N3N]

14 hours ago, Lisias said:

Hey… "The Helpful Grumpy". Another good name for a Rock Band!  

 

  Hide contents

Let's talk on a spoiler then.  

Give that guys some slack. Language Barrier is A Sun on a Beach  and more than once I got… "liquided" on a guy due it. Some usual wording on English sounds aggressive when transliterated to my mother language, and vice versa, and now and then I got into some mess too.

And give you some slack too, by the way. You will probably bork on English again, so just accept this as something that you have to handle now and then. Don't let some yellow liquid  get into the way of your gaming.

Scale safe!  

THANK YOU!

[asaurus1]

Recently started up my KSP after installing the "Tweakscale Configs for Making History" mod from CKAN (because I thought, "Oh, maybe I need these to use Tweakscale for MH parts") and was confronted by the "FATAL ERROR" warning at the menu screen. I am guessing this "configs for making history" is an out-dated mod and was somehow overwriting TweakScale's built-in changes. I removed the "Configs for making history" mod and all is well again.

 

 

[Tsani]

8 hours ago, Lisias said:

 

Do you know someone selling time at affordable prices? I'm buying!

No, but how about a cup of coffee, a donut and good thoughts?

[Dizor]

@Lisias thank you for supporting this mod. But I'm here to report a bug.

Some parts are not scalable because of this:

I have checked this and replaced tabs with spaces. Part became scalable.

[Lisias]

On 9/2/2019 at 6:47 PM, Dizor said:

@Lisias thank you for supporting this mod. But I'm here to report a bug.

Some parts are not scalable because of this:

https://i.vgy.me/OTyrLj.png

I have checked this and replaced tabs with spaces. Part became scalable.

Humm… Interesting.

[LOG 13:31:06.328] Config(@PART[Size3to2Adapter_v2]) TweakScale/patches/Squad/Squad_Tanks/@PART[Size3to2Adapter_v2]

This is the only mention for a patch on my test installment for this part. It should exists a new line with "Applying", but none was found. Also, on the ConfigCache, there's no Module TweakScale for this part.

So, yeah. You found a bug on Module Manager! Congrats!

It's a Module Manager bug (and not TweakScale) because, well, MM is the one applying the patches - every single config file from Squad on my installment use TABs!

Moreover, they have the BOM (Unicode's Byte Order Marker) char on the start of the file. On the example below, is BF BB BF. So, this is the standard followed by Squad, so we should make sure we can read these files alright.

However, and you have a point, by getting rid of the TABs I can make things to work now. And every other entry on that file is using spaces, so besides technically correct, that entry is out of the line for that file. (and I will make tests with TABs only files too).

I will workaround on this Module Manager bug on the next release. Thanks for pinpoint it.

This should render a bug report on Module Manager. Do you want to do it yourself?
 

— — POST EDIT — — 
Things are worst than you reported and I thought. On my machine, this part Size3to2Adapter_v2 is not being patched at all. I tried converting everything to spaces, then everything to TABs, changed the EoL to UNIX and then to Windows and different combinations.

You got a problem, it's real. But your diagnosing is wrong. It's not related to TAB vs Space, it's something else (perhaps including the TABs vs Space). I don't have a clue about the reasons that this worked for you. In a way or another, I will not commit any change on TAB vs Space until I figure this out - I can ending up getting something else broken too.

 

— — POST POST EDIT — — 
Well, it's a problem, but not a TweakScale's patch problem apparently.  Something is not happening while the MM patching. Using a verbose debug release for TweakScale. I got this on the log:

[LOG 01:31:51.806] [TweakScale] TRACE: Found part named Size3to2Adapter ; title Kerbodyne ADTP-2-3:
[LOG 01:31:51.806] [TweakScale] TRACE:  Part Size3to2Adapter has module TweakScale
[LOG 01:31:51.806] [TweakScale] TRACE: Checking Sanity for Size3to2Adapter at Squad/Parts/Structural/Size3To2Adapter/part/Size3to2Adapter
[LOG 01:31:51.806] [TweakScale] TRACE: Checking Issue Overrule for Size3to2Adapter at Squad/Parts/Structural/Size3To2Adapter/part/Size3to2Adapter
[LOG 01:31:51.806] [TweakScale] TRACE: Checking Hotfixes for Size3to2Adapter at Squad/Parts/Structural/Size3To2Adapter/part/Size3to2Adapter
[LOG 01:31:51.806] [TweakScale] TRACE: Checking ShowStopper for Size3to2Adapter at Squad/Parts/Structural/Size3To2Adapter/part/Size3to2Adapter
[LOG 01:31:51.806] [TweakScale] TRACE:  Module TweakScale
[LOG 01:31:51.806] [TweakScale] TRACE:          name = TweakScale
[LOG 01:31:51.806] [TweakScale] TRACE:          type = stack_square
[LOG 01:31:51.806] [TweakScale] TRACE:          defaultScale = 3.75
[LOG 01:31:51.806] [TweakScale] TRACE: Part Size3to2Adapter (Kerbodyne ADTP-2-3) has drycost 2600 with ignoreResourcesForCost False
[LOG 01:31:51.806] [TweakScale] TRACE: The part named Size3To2Adapter.v2 ; title Kerbodyne ADTP-2-3 doesn't supports TweakScale. Skipping.
[LOG 01:31:51.807] [TweakScale] TRACE: Found part named radialEngineBody ; title Engine Pre-cooler:

Observe that Size3to2Adapter is being inspected as expected (it was patched after all), but Size3to2Adapter.v2 is being listed as not having support for TweakScale - what's right, that thing wasn't patched after all.

The interesting bit is the ".v2" thingy. It's "_v2" everywhere on the log file, but on this specific log entry, it's ".v2"

This happens because KSP converts "_" to "." on runtime. Ok, perhaps a problem on MM on the "_"->"." conversion? Nope. Other parts are being patched alright:

[LOG 01:31:51.838] [TweakScale] TRACE: Found part named RCSBlock.v2 ; title RV-105 RCS Thruster Block:
[LOG 01:31:51.838] [TweakScale] TRACE:  Part RCSBlock.v2 has module ModuleRCSFX
[LOG 01:31:51.838] [TweakScale] TRACE:  Part RCSBlock.v2 has module FXModuleAnimateRCS
[LOG 01:31:51.838] [TweakScale] TRACE:  Part RCSBlock.v2 has module TweakScale
[LOG 01:31:51.838] [TweakScale] TRACE: Checking Sanity for RCSBlock.v2 at Squad/Parts/Utility/rcsBlockRV-105_v2/rcsBlockRV-105/RCSBlock_v2
[LOG 01:31:51.838] [TweakScale] TRACE: Checking Issue Overrule for RCSBlock.v2 at Squad/Parts/Utility/rcsBlockRV-105_v2/rcsBlockRV-105/RCSBlock_v2
[LOG 01:31:51.838] [TweakScale] TRACE: Checking Hotfixes for RCSBlock.v2 at Squad/Parts/Utility/rcsBlockRV-105_v2/rcsBlockRV-105/RCSBlock_v2
[LOG 01:31:51.838] [TweakScale] TRACE: Checking ShowStopper for RCSBlock.v2 at Squad/Parts/Utility/rcsBlockRV-105_v2/rcsBlockRV-105/RCSBlock_v2
[LOG 01:31:51.838] [TweakScale] TRACE:  Module TweakScale
[LOG 01:31:51.838] [TweakScale] TRACE:          name = TweakScale
[LOG 01:31:51.838] [TweakScale] TRACE:          type = free
[LOG 01:31:51.838] [TweakScale] TRACE: Part RCSBlock.v2 (RV-105 RCS Thruster Block) has drycost 45 with ignoreResourcesForCost False

Just for the lulz, I changed the patch to use ".v2" on the name. Obviously, it didn't worked - but I had to be sure, as we are handling a probable misbehaviour somewhere . 

I tried this stunt downto Module Manager 3.1.3, no dice. Removing both the DLCs makes no difference,  it's not related to a DLC.

Dude, I need your KSP.log and ModuleManager.ConfigCache. Please delete the cache and gererate a new one, and then publish it to me together the KSP.log.

Edited September 3, 2019 by Lisias
yeah. right. more one anecdote to tell on a bar with my friends!

[Dizor]

Wow! Such a deep investigation! The situation is really strange.

13 hours ago, Lisias said:

Dude, I need your KSP.log and ModuleManager.ConfigCache.

Ok, i can send you this in 3 hours or so.

[Dizor]

@Lisias logs and updated cfg: https://drive.google.com/file/d/16to6UZ7irp4Fy49I195PmR1I2pb5HmDt/view?usp=sharing

When I deleted the ModuleManager.ConfigCache and ModuleManager.ConfigSHA I was unable to get Size3To2Adapter_v2 resizable even with Squad_Tanks.cfg modified.

But eventually I managed to get this part resizable. If I remember correctly my steps were:

1. Remove TweakScale and __LOCAL folders from GameData.

2. Remove ModuleManager.ConfigCache and ModuleManager.ConfigSHA. Clear KSP log files.

3. Download latest TweakScale and unpack GameData and Extras to KSP folder. Remove old MM dll.

4. Modify GameData\TweakScale\patches\Squad\Squad_Tanks.cfg - replace tabs with 4 spaces, remove 1 empty extra line (line 390).

5. Run game. Result is:

KSP 1.7.3 with no DLCs

GameData content:

__LOCAL\
000_ClickThroughBlocker\
000_TexturesUnlimited\
000_Toolbar\
001_ToolbarControl\
Squad\
TweakScale\
ModuleManager.ConfigCache
ModuleManager.ConfigSHA
ModuleManager.Physics
ModuleManager.TechTree
ModuleManager.4.0.2.dll
toolbar-settings.dat
unBlur.0.5.0.dll

 

Edited September 3, 2019 by Dizor

[Lisias]

1 hour ago, Dizor said:

@Lisias logs and updated cfg: https://drive.google.com/file/d/16to6UZ7irp4Fy49I195PmR1I2pb5HmDt/view?usp=sharing

When I deleted the ModuleManager.ConfigCache and ModuleManager.ConfigSHA I was unable to get Size3To2Adapter_v2 resizable even with Squad_Tanks.cfg modified.

But eventually I managed to get this part resizable. If I remember correctly my steps were:

<CUT by me>

Thanks. I will check again by night. The interesting thing is that MM apparently is going fine with patches using TABs and Spaces, at least on my tests. So I find somewhat hard to believe that the TAB->Space stunt is the root cause, but only a trigger or symptom.

Your procedure (starting from scratch) appears to corroborate my thesis, but hey… Now we have a procedure! If I manage to reproduce this, I can diff everything on the folder to hunt differences and then, with a bit of luck, this can hint the root cause of the mess.

Thanks for the report and the procedure!  

[Dizor]

@Lisias I think I found the root cause:

I remembered that in addition I tried to compare the part name with name from file GameData\Squad\Parts\Structural\Size3To2Adapter_v2\Size2to3_v2.cfg. Just in case.

Notepad++ was saying that the name is the same (because NP++ is case insensitive by default). I didn't noticed this and left the name Size3To2Adapter_v2 like in the file Size2to3_v2.cfg

[linuxgurugamer]

11 minutes ago, Dizor said:

(because NP++ is case insensitive by default).

LOL and this is why I like GVIM, because by default it is case sensitive.  Of course, lots of editors, and I suppose that NP++ can be configured to be case sensitive by default

[Lisias]

4 hours ago, Dizor said:

@Lisias I think I found the root cause:

Notepad++ was saying that the name is the same (because NP++ is case insensitive by default). I didn't noticed this and left the name Size3To2Adapter_v2 like in the file Size2to3_v2.cfg

Looking on the bright side - this is a mistake that both of us will never commit again.  

As soon as I manage to stop laughing my ass out (and assuming I will survive the event), I will fix the thing and publish a new release.  

Damn. I will open an issue just to be sure to get this remembered.  [edit: Issue #71]

 

4 hours ago, linuxgurugamer said:

LOL and this is why I like GVIM, because by default it is case sensitive.  Of course, lots of editors, and I suppose that NP++ can be configured to be case sensitive by default

And this explains a weird thing happening with GREP - it was not extracting the lines with the part name, just this patch. Incredibly, this didn't ringed a bell last night. (and this is the time in which I could use a nice #facepalm emoticon!!!)

(and yeah, I'm still laughing)

 

— POST EDIT --

In our defense, @Dizor, on Squad/Parts/Structural/Size3To2Adapter/part.cfg the part name is Size3to2Adapter . With small "T".

On Squad/Parts/Structural/Size3To2Adapter_v2/Size2to3_v2.cfg the part is named Size3To2Adapter_v2 . With big "T".

Both of them are Structural parts on the Squad's book, while they ended up on the Tanks file on TweakScale - but this is something that I will leave as is. 

This is a text book example for why a bad standard is better than no standard at all.  (if anyone use this on a class lecture, please send me a beer!).  

 

 

Edited September 4, 2019 by Lisias
:D

[Dizor]

10 hours ago, Lisias said:

I will fix the thing and publish a new release.

It would be good to have something like unit test to check whether all patches are formatted properly and stock parts names match the names from patches.

[Lisias]

11 hours ago, Dizor said:

It would be good to have something like unit test to check whether all patches are formatted properly and stock parts names match the names from patches.

The problem with unit tests is that they are software the same way the main product.

They suffer from bit rot too, and they need to be tested and maintained. And updated and the whole cycle redone on every changed feature.

Exactly as documentation. But au contraire of documentations, that usually can be carried out by non programmers, you need programmers to maintain the thing. And every hour spent maintaining a unit test is an hour not used for development.

So, the worst part is to find time and mood to spend on something that doesn't necessarily adds value to the product.

The second worst part is fixing a broken feature with an unit test - you have twice the work to do. And this work need to be done by a scarce human resource, the developer.

Creating Standards and following them is also a way to reach the same goal on this situation.

I once worked on an Agile Company. The Web 2.0 was still a thing, everything old was shining new again, and we did Scrum by the book.

And we didn't improved our product. After some months, every mistake or bug had to be worked twice: we had to rewrite the unit test, check it, double check it, and then work on the issue. So we just stopped adding features, because we could not add new features without fixing what's broken, and we didn't have the time to rewrite the tests and the features for everything. Our metric was 1 to 1: half the product code base were tests.

Yeah. You know already. We had drown ourselves on technical debts. And the product ultimately failed. And failed on something that had a unit test for the damned thing. The company closed 3 months after I had leaved, so bad was the problem.

In order to write a unit test that adds value to the product, we need to weight the damage a mistake will do, the complexity of the code that would check it, the incidence of the problem on the field, and how hard is to eye ball the thing instead. [And how often the thing is expected to change on its life cycle!]

— — — POST EDIT — — — 

Do you know what would be really handful? A patch lint tool. Something that could be run by anyone against an installment, from end users to developers, and even added to the building cycle as an acceptance test. That would help everybody, and not only one or two devs. 

Welcome to McLisias AntiKraken. Now, if at least I didn't had a day job and could work all my time on these things pro bono…  

Edited September 4, 2019 by Lisias
Less entertaining grammars :P

[Lisias]

Hey, TweakScale 3.4.3.4 (I'm finishing the smoke tests before officially releasing it) just found this:

[LOG 22:05:43.641] [TweakScale] WARNING: NULL ConfigNode for Squad/Parts/Engine/liquidEngineLV-1_v2/liquidEngineLV-1R _v2/radialEngineMini_v2 (unholy characters on the name?). Trying partConfig instead!

Confirmed downto KSP 1.7.0. Hey, Squad! We are Brothers in Typos!

Yeah… We really need that patch lint tool.

Everybody borks.
Gregory Kerman

[kcs123]

13 hours ago, Lisias said:

Confirmed downto KSP 1.7.0. Hey, Squad! We are Brothers in Typos!

Another confirmation that even proffesionals and veterans are not immune to mistakes .

[Lisias]

6 hours ago, kcs123 said:

Another confirmation that even proffesionals and veterans are not immune to mistakes .

There's only one way to do not make mistakes - doing nothing.  

And that's the reason we work on Standards, lint tools, testings, etc. So we can detect the mistakes and fix them before they do some damage on the field. Some will always leak, it's the human nature. But the less of them, the better.

And some mistakes are really easy to automate a check and prevent them.

Edited September 5, 2019 by Lisias
this time was the auto-complete!!

[SpaceN00b]

Ok so i am getting a fatal error from tweak scale and the warning message told me to come here

KSP log: https://drive.google.com/open?id=1u2SdUfEQdUSeadOReodyHILj2UF-ihRD

[Lisias]

1 hour ago, SpaceN00b said:

Ok so i am getting a fatal error from tweak scale and the warning message told me to come here

KSP log: https://drive.google.com/open?id=1u2SdUfEQdUSeadOReodyHILj2UF-ihRD

Go it. I'm pending permission to access the log. I sent a request, I will be back to it later!

[SpaceN00b]

3 hours ago, Lisias said:

Go it. I'm pending permission to access the log. I sent a request, I will be back to it later!

ok i gave you permission

[Lisias]

6 hours ago, SpaceN00b said:

Ok so i am getting a fatal error from tweak scale and the warning message told me to come here

KSP log: https://drive.google.com/open?id=1u2SdUfEQdUSeadOReodyHILj2UF-ihRD

Well… To tell you the true,  you have 8 of them:

[LOG 14:11:16.366] [TweakScale] WARNING: **FATAL** Found a showstopper problem on M2X.Endcap (Mk2 Airlock Adapter Endcap).
[LOG 14:11:16.962] [TweakScale] WARNING: **FATAL** Found a showstopper problem on MEMLander (Munar Excursion Module (M.E.M.)).
[LOG 14:11:16.976] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTInlineAirIntake (XM-600 1.25m Air Intake).
[LOG 14:11:16.977] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingSmall (Mk0B Small Modular Wing).
[LOG 14:11:16.977] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingLarge (FAT-460 Super-Lift Aeroplane Main Wing).
[LOG 14:11:16.987] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsaulNoseCockpitAn225 (Kn-225 "Osaul Payload" Cockpit).
[LOG 14:11:16.988] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsualRadCockpit (Mk.P-Yavka Radial Cockpit).
[LOG 14:11:17.011] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTtruckbox (Truck Box).

The M2X.Endcap is an already known issue, it is/was a glitch on Mk2 Expansion. My pull request was closed and the fixes applied. The 1.8.6. release has the fixes. Please update Mk2 Expansion.

The next 7 FATALities are also about glitches already fixed. Please update SXT, the latest release has these fixed. For some months already.  

Scale Safe!!  (I think I need to pay a beer to Scott Manly for this!)

[sturmhauke]

9 hours ago, Lisias said:

There's only one way to do not make mistakes - doing nothing.  

...And some mistakes are really easy to automate a check and prevent them.

Automated testing is one aspect of what I like to call strategic laziness. The less drudgery you have to do, the more time you have for more interesting problems. Of course, you have to take care not to slip into plain old nonproductive laziness...

[SpaceN00b]

3 hours ago, Lisias said:

Well… To tell you the true,  you have 8 of them:

[LOG 14:11:16.366] [TweakScale] WARNING: **FATAL** Found a showstopper problem on M2X.Endcap (Mk2 Airlock Adapter Endcap).
[LOG 14:11:16.962] [TweakScale] WARNING: **FATAL** Found a showstopper problem on MEMLander (Munar Excursion Module (M.E.M.)).
[LOG 14:11:16.976] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTInlineAirIntake (XM-600 1.25m Air Intake).
[LOG 14:11:16.977] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingSmall (Mk0B Small Modular Wing).
[LOG 14:11:16.977] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTWingLarge (FAT-460 Super-Lift Aeroplane Main Wing).
[LOG 14:11:16.987] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsaulNoseCockpitAn225 (Kn-225 "Osaul Payload" Cockpit).
[LOG 14:11:16.988] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsualRadCockpit (Mk.P-Yavka Radial Cockpit).
[LOG 14:11:17.011] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTtruckbox (Truck Box).

The M2X.Endcap is an already known issue, it is/was a glitch on Mk2 Expansion. My pull request was closed and the fixes applied. The 1.8.6. release has the fixes. Please update Mk2 Expansion.

The next 7 FATALities are also about glitches already fixed. Please update SXT, the latest release has these fixed. For some months already.  

Scale Safe!!  (I think I need to pay a beer to Scott Manly for this!)

Hmm i had installed everything from ckan so i guess something on the mk2 and sxt ckan entries aren't up to date but that's ok and i got it fixed. Thanks for helping me out!!

[Lisias]

12 hours ago, sturmhauke said:

Automated testing is one aspect of what I like to call strategic laziness. The less drudgery you have to do, the more time you have for more interesting problems. Of course, you have to take care not to slip into plain old nonproductive laziness...

Yep. It's about the ending result and the costs you incur to get there.

How many times the thingy will change? How hard/costly is to automate a test? How hard/costly is to manually inspect it instead? How bad is the damage done when it happens? How many people are affected?

Every single automated test will steal development time to be created and maintained. You do too much of them, you end up stalling your development.

Using this very mistake of mine: every single new V2 part has the very same name of the original, but one. I borked on that one, because I assumed that every part would follow that pattern - what was a very sensible assumption, by the way.

A fellow Kerbonaut detect the symptom, and both of us 'wasted' a couple hours each on the final diagnosing. (I spent a bit more chasing my tail, but this is already standard procedure! )

Now, what's the most productive measure to cope with this problem? Well... Nothing!

Once Squad adds a new part, that part is not renamed. Ever. So this will never happen again. At least on TweakScale.

An automated tool to prevent this mistake to happen again will cost a lot of efforts, as I need not only to code a solution, but I have to 'teach it' when a patch is good, when it's not, what's a part name, how to understand to which part a patch is related too, to whom belongs each partname... A lot of metadata. And then all of this will need to be revised every new KSP version, because some stablished pattern can change again.

All of this at the expenses of my free time, free time that could be used improving TweakScale or helping someone here to diagnose a rogue patching.

Alternatively, had the developer followed the pattern (just add '_V2' on an existing partname), this could be had prevented. And a lint to check if every '_V2' part has a equivalent older partname is absolutely way easier to implement and maintain than what I had proposed above.

"Fail early, fail often".

— — — 

That said, this doesn't means that I will ignore the issue from now. I already have an artifact to detect new parts between KSP versions (a UNIX find with grep on both installments followed by a diff). What will happens is that I will pay more attention on the casing of the name, since I lost confidence on the (lack of) Standards on the product.

And this is not about the mistakes (that happens all the time), it's about they are not being detected and fixed when possible.

People borks, don't fails. Process fails.

Who watches the Watchers?

Edited September 6, 2019 by Lisias
Kraken damned Autocompletes

[FreeThinker]

@Lisias I just noticed that tweakscale does not scale power consumption on ModuleActiveRadiator, is this an oversight?

[Lisias]

19 minutes ago, FreeThinker said:

@Lisias I just noticed that tweakscale does not scale power consumption on ModuleActiveRadiator, is this an oversight?

No. A Work In Progress. Beta testers are welcome - detecting and fixing problems on user's installment to prevent them from crashing had eaten most of my free time in the last months.