Lisias

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

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.

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

There're no such things as "lose ends". They are hooks to expand the story on a later opportunity!

A friend posted this today. I have some nice memories listening to this.

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…

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] 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!).

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!

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.

The most recent revision of the Contares patch is working on my machine. The Fuel Switches I will try to tackle down by the week. Reproducing installments to test things needs some time. I think I have a way to removing just the Fuel Switch part of B9PartSwitch, by the way, so we could use MFT on a B9 part and still have the other features. Do you know someone selling time at affordable prices? I'm buying!

I would do it a bit different: @PART[light_aviation] // aviation light { %MODULE[TweakScale]:NEEDS[TweakScale] { %type = free } } The :NEEDS would apply the patch only when TweakScale is installed, otherwise the patch is ignored. This avoids cluttering the GameDatabase with useless information. Also, it's better to use "%" on the value name you are editing. If by some reason someone else has patched this part and you add a value without the "%", a new entry with the same value name is added and you will have a double entry, and this will triggers a "Houston" on the TweakScale Sanity Checks. Alternatively, if @MOARdV decides to add the patch on his Add'On as default, I would do what follows instead: @PART[light_aviation]:FOR[AviationLights] // aviation light { %MODULE[TweakScale]:NEEDS[TweakScale] { type = free } } Now, doesn't matter too much using the "%" on the value name. When you use :FOR you are saying "This patch belongs to AviationLights, and it's a default patch for it". Now it's up to everybody else to prevent double patching the part, as MOARDV had defined what he thinks is the standard for this part. Technically, this is all I have to say about the patch. What follows below is not a TweakScale "official" recommendation. From a personal point of view, I find "free scaling" cumbersome for some parts, as I end using them most of the time on a very strict set of sizes. So perhaps a SCALETYPE would be a better way? You are not locked into a preset value from the Scale Type, you can select intermediary scales the same way - but you would also have some most commonly used presets to make your life easier on the day to day building. Also note that "type = free" make no change on the luminosity. You would need a new TWEAKSCALEBEHAVIOUR to teach TweakScale to make the light stronger or dimmer while scaling - not to mention the Electrical Power consumption.

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

Remembered this one today.

Well, let's check it. Congrats, no real problems on your installment: But that 63, that means that a part could not be safely scaled and so TweakScale withdrew itself from them, can be divided into the following classes: Rogue patching KerbalEVAs are not scalable. But yet some patch is shoving an empty TweakScale module on it. There´re too much people mangling it on your installment, I counted 80 patches acting on kerbalEVAFemale. Of course, (probably) just one of them are doing the mistake. It's too much for me to checking every one of them, and the problem was mitigated anyway, so I suggest to ignore this for now. Multiple Fuel Switches on the same part. You have 25 parts with two Fuel Switches. I choose one of them and checked it: It's a wild guess, but I think you should check "Jenyaza/SmallTweaks/FSFuelSwitch" patches. Unsupported parts You have 17 parts using FSbuoyancy. This will tacked down soon (see the ROAD MAP). You have 14 parts with ModulePartVariant that has mass. Ditto. These ones you can ignore for now. Next releases will support tem gradually. I also found a lot of logs like this one: [LOG 21:22:52.541] [TweakScale] WARNING: NULL ConfigNode for Workshop/Parts/duct_tape/part/Duct Tape (unholy characters on the name?). Trying partConfig instead! You can ignore them, besides being good to know this is happening. Pathnames with spaces and some unholly chars ended up being stored slightly differently, and I'm still trying to cope with it (it's not hard, and I think I already know hot to do it, but I just don't have the time to handle this now). As a fallback measure, I check it using an alternative way. The (very) good news is that this is completely unrelated to that nasty Toe Stomping Fest I get sometimes on the Main Menu Scene. In what KSP version you are experiencing this? If this is happening on a KSP >= 1.4 with current TweakScale, you can had found a new situation that I can prevent on the Sanity Checks.

You have a very inspiring name! !! De nada, bicho. Qualquer coisa, tamos aí! [local informal slang for "welcome").

Thanks and welcome. Yep. RO. The good news is that this is already old news. In a nutshell: Scale safe!

Recently, I explained about Overrules and HotFixes. Today I want to explain exactly what are the problems that were affecting TweakScale in the past (or still are), and that ended up motivating the Warnings, Alerts, Overrules and HotFixes. Mass Zero mass is evil. Negative mass too. And these affect every part that has mass, i.e., everything and the kitchen's sink. Including the Modules. And this is not exclusive for TweakScale, every single Add'On that mangles with the mass are prone to this glitch (as Fuel Switches). This is not a problem, but a fact: we can't have parts with negative or zero mass. So we must be careful to avoid such situations (at least, by accident), or we end up injecting divisions by zero into the Physics Engine. And divisions by zero are bad, really bad. It injects NaNs on everything, and the games goes crazy. Really crazy. Negative mass inverts the forces on that part - specially thrust. This is the reason some crafts get "stuck" in the launchpad . You apply the thrust on a part, this part "pushes" the next, but that next part has negative mass and the force vector is negated and then it pushes back the first part. If we are talking a heavy fuel tank, that pushing back is enough to over stress everything and so things goes to space in the most unpleasant and undesirable way. Zero mass zero the forces, so the part became unmovable. Same thing. Since TweakScale, when scaling a part, obviously scales the mass, TweakScale is the preferential victim of the problems I will describe below. But make no mistake, TweakScale can be the preferential victim, but it's not the only one. Gravity appears to be affected too, as the statics around the launch pad start to explode by itself if you leave the craft lingering time enough on the launchpad - even with engines off. Related issues: https://github.com/pellinor0/TweakScale/issues/83 Every single problem below can, eventually, end up with Zero or Negative mass. And that's the reason I need to tackle down them before doing any further development. So, in a nutshell: don't blame the Screaming Victim. Unsupported Parts New parts, new code. This is on me. Real Life and that pesky Toe Stomping Fests I will describe below prevented me to carry on these tasks, so I decided to withdraw, in runtime, TweakScale from that parts to prevent breakage. Any part (stock or not) that has ModuleVarianPart with mass. Issue #13. Well, scaling parts with Variant is working - except for mass. The (clever) algorithm that applies the exponents to the datuns doesn`t knows (yet) about ModulePartPariant that have mass. And so, applies the exponent only on the root part and ignore the Variant. It happens that on some parts, the root mass is negative or zero, and the mass on the selected Variant is applied to it to get the final mass of the part. Well, if I scale the negative mass enough, the Variant mass would no be enough to make the total mass above zero (or can make it equals zero). Any part with B9PartSwitch and Modular Fuel Tanks. Issues #54 and #56. Patching a part with more than one fuel switch is bad enough. Instead of play cat-and-mouse with problems with Fuel Switches, is more sensible to do not patch a part with more than one Fuel Switch! Any part with FSBuoyancy. Issue #9. Don't have a clue yet about what's happening. These are things that I want to solve, but not before getting patches right. It's nuts to fight a two front war. The present iteration, TweakScale 2.4.3.x , is finishing with that patch problems. The next iteration, 2.4.4.x will have these (and more, as Serenity) parts supported. Rogue Patching This is, easy, the worst problem at the moment. And this is not on me, as TweakScale depends of correctly written patches in order to correctly do its job. Rogue patching happens when one or more patches apply the same (or slightly different) patch on the same part by accident; by something that changed somewhere, sometime; or by plain disregarding anything else. I'm pretty sure these patches worked fine on that time on the developer's machine - but we need to have these patches working fine now and on the users' machine, otherwise things may go kaput. Of course some of the default TweakScale patches were also defective. The detected ones are already fixed, and besides I had eye balling all of them by now, some of the default patches relates to Add'Ons I don't find for downloading anymore. So, yeah, these will be deprecated on the 2.4.4.0 release, but they will be available on the Extras folder on the distribution ZIP - just in case. These patches renders any Add'On using bad or unintended rules for doing the job. Worse, since rogue patching usually is unintended, it's not controlled and so you can have the GameDatabase mangled into a bad configuration without notice, and once you load Crafts and Savegames using that ruined GameDatabase, you have corrupted Crafts and Savegames in your installment. The really nasty side effect of this is that, sometimes, by fixing the GameDatabase you ruin your Savegames that became "addicted" to the ruined one. Besides affecting any Add'On, TweakScale by its nature and popularity ends up being the most usual Screaming Victim of these rogue patches -TweakScale need correct rules in order to scale things, including mass - and as I explained above, making errors on handling the mass of a part is ruinous. Of course, not every rogue patching ends in disaster. Some of them are just annoyances. But it's easier (and more feasible) to detect any rogue patching and fix them, than to try to workaround in code every single possibility of bad patching in order to overcome the effects - not to mention that this would be a fool's errand, as it's not possible to automatically guess the right patching with accuracy except on the most simple mistakes. The following issues are related to this problem: Issue #12. Issue #15. Issue #20. Issue #24. Issue #30. Issue #34. Issue #45. Issue #49. Issue #56. Issue #58. Issue #60. Issue #62. Issue #63. Issue #67. Issue #69. Issue #70. And the list is growing. Please note that not a single one of that issues is related to the TweakScale (the Module). None of this is TweakScale's fault, but it happens that since TweakScale is injected on every Add'On on an installment, and are somewhat popular, TweakScale has a huge exposition to the problem, and so, it's the most usual Screaming Victim of these problems. And, boy, TweakScale is screaming nowadays. Unholy Interactions Between Modules This one, thanks Krakens, are not that usual nowadays. But when it happens… What happens is that some Modules, besides working fine by themselves, now and then borks (or make bork) with a second Add'On. The most interesting case is about a Fuel Switch that, when have his toes stomped by a second Fuel Switch, injects Zero Mass into TweakScale computing. This one was somewhat… interesting… to isolate and detect - besides being simple to workaround. However, not always these problems are due mistakes or flaws. One very hard to get rid nowadays is this one: some Add'Ons (TweakScale between them) uses the Main Menu scene to trigger a lot of initialization procedures, what nowadays happens concurrently (since 1.4.0, I think). Some of them (including TweakScale) needs to read the GameDatabase. But others (including TweakScale) needs to write something into the GameDatabase. And when you have more than one Add'On writing into the GameDatabase at the same time and without controlling the concurrency, we have a Toe Stomping Fest. By some reason (and I don't know if the one that can explain this is Squad or Unity), when an Add'On overwrites something into the GameDatabase, any other guy trying to read that same data at the same time gets an NRE. It's a wild, wide guess, but I think that when you iterate over the GameDatabase, you iterate over a copy of pointers to the data structures. And when someone writes a new version of a data structure, the old version is deallocated and any previous copy of that collection of pointers now have some invalid pointers - and we bork relentlessly on a Null Reference Exception while trying to read that pointer. In a way or another, I managed to mitigate the problem by delaying my turn on the GameDatabase using some heuristics that I managed to make to work most of the time, but not always. Again, this is a fool's errand : every single time a new Add'On decides it needs to configure something on the GameDatabase when the game starts, it's risking stomping the TweakScale's toes. To tell you the true, I think that TweakScale must not be the only one being stomped, but anyway - TweakScale needs to be the last one to check the GameDatabase in order to detect any problems and to setup some needed data before the user loads a savegame - since TweakScale fixes things on the GameDatabase, these fixes need to be applied before any savegame is loaded! Related issues: Issue #2. Issue #15. Issue #31. Issue #36. Issue #37. In a nutshell - if the Add'On has this decorator [KSPAddon(KSPAddon.Startup.MainMenu, <a_boolean_value>)] on a MonoBehaviour and access the GameDabase on its event handlers, this dude is a serious candidate to be a victim, a perpetuator or both on this problem. Again, I want to stress that this is not exactly TweakScale's fault. And it's not a third part Add'On's fault neither - every single one of them work fine by themselves. But yet we need some way to manage the access to the GameDatabase in order to prevent this Toe Stomping Fest, and this is not something that any Add'On Author can do by him/herself - we depend on each other on this. This is the reason I proposed a new feature on Module Manager, by the way: https://forum.kerbalspaceprogram.com/index.php?/topic/50533-140-17x-module-manager-403-august-9th-2019-right-to-ludicrous-speed/page/260/&tab=comments#comment-3611228 Conclusions We, as a Community, have some work to do. In the mean time, I'm writing workarounds. Link to my site where this essay will be updated now and then http://ksp.lisias.net/blogs/tech-support/TweakScale/Issues-that-can-plague-TweakScale

@Tsani, I didn't managed to reproduce all the problems I detected on your LOG. That HotFixes for the Fuel Switches appears to be not necessary, I'm presuming that newer versions for the Add'Ons had fixed the root cause. But I detected a glitch on the Contares HotFix, I forgot a part (or perhaps a new one was issued on the latest release and caught on my machine), so please update the HotFix on your installment this version of the file (remember to click "Raw"). Cheers!

Got it. And yeah. It's indeed what I was fearing - I reopened Issue #31 due your report. I will need your help while cooking the workaround, as replicating this problem on my machine can be more work than I have time to. Do you mind moving the conversation to the Issue? A lot of files and logs will be exchanged and Github is way better for this task!

UUUgh. Apparently Toe Stomping Fest. I have a hunch about the reason, but I need the full KSP.log in order to diagnose it. — post edit -- Your TSError.zip only have the output_log.txt, with little to no information about patches and other KSP stuff I need to check in order to confirm my hypothesis.

Not tested myself yet, but I heard of this: https://github.com/JarredAllen/ksp-StopBreakingGroundNotificationSpam

Free time.

Yep. But being nice and cooperative is not necessarily the Right Thing to be done. So, we can conclude that Laika didn't did the Right Thing - as a poor dog could be expected to do such decisions. But yet… Yes, it's a very nice example. Couldn't said better. We endure the consequences from what we do, no matter being right or wrong.

The mdb and the pdb are the databases used for debugging the DLLs and they are somewhat useless without the debugger - that by its turn is only really useful when you use it on DLLs compiled in debug mode. Something that, ideally, we should avoid on deliverables. I have terrible memories from MFC on this. So, unless you are debugging things, I'm prone to advise to get rid of *.mdb and *.pdb from your installment. My rationale is that if you are in need of debugging the thing, you should do it using the IDE and the get the source files to be compiled on your rig. On deliverables without the source code available, that files would make some sense on the distribution - but such Add'On is not allowed here under Forum rules. And yet, they can be available on a separate download intended to the small fraction of users in need to use them instead of spamming the files for everybody. As a example, the current firespitter DLL has a size of 232.448. The mdb (access data file? ) has 112.726 and the PDB 433.664 . The debugging info are somewhat twice the size of the DLL itself. So only 1/3 of that payload is, effectively, needed and useful for the end users.

By Kraken's sake, say yes.