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

[DarkNounours]

On 12/23/2019 at 2:28 PM, Lisias said:

Should? Not. Can? Yes.

It doesn't needs to be internalised by the Add'On being patched (as I did with KAX), an "Add'On in the Middle" is also a good idea - an Add-On maintained outside TweakScale, being hard dependent from TweakScale and the Add'On being patched.

For example, the Near Future *** patches will be moved to an Add'On called "TweakScale Near Future *** Support" (maintained by me, at least initially) on TweakScale 2.5 (or a bit later, depends on how I push some needed changes first).

So, that "TweakScale NF*` netkan will state TweakScale and NF *** as hard dependency.

The thing I'm still working on is how to make this transparent to the CKAN user: I can't just move out a patch to a "Companion Pack" without breaking users that would not be aware of the move. Moving the patches to the patched Add'On (as I did with KAX) is seamless on CKAN, the next update will have all sorted out automatically, mainly if doing the way I did on KAX, making sure it's patched after TweakScale and deleting the "old" patches before applying the new ones, then on a next TweakScale version that patches "vanishes" and then would be nothing to be deleted, but the new official patches would be still there.

Hi Lisias. I've been a bit busy with family things these last few days so this is why I took some time to reply.

Do you make a difference between what you call Add'On and what players call mod ?
I think, from a CKAN user point of view, getting a TS patch one by one this way could be just what an end user could expect.

By the way, have you already worked on NF patches ? Because this is something I intented to do  
 

[Lisias]

18 minutes ago, DarkNounours said:

Hi Lisias. I've been a bit busy with family things these last few days so this is why I took some time to reply.

Me too.   Not exactly on the most pleasant way, however.  

 

19 minutes ago, DarkNounours said:

Do you make a difference between what you call Add'On and what players call mod ?

Yes. An "Add-On" (as it WAS used on the Forum's menu until the last update) is... a Add On.  It's the correct term, IMHO. And if you check the Forum Sections, whoever created them thinks like me:

https://forum.kerbalspaceprogram.com/index.php?/forum/4-add-ons/

Around here, using "Mod" is problematic. A lot of people call the Moderatos as "Mods" too, and this is absolutely terrible on a product (and a hell of a source of confusion for me on my first months here!).

Each thing needs to have only one name, and each name must be associated to only one thing. But, apparently, this Forum is moving towards making confusion official.

Well.. It's their job, not mine!  I can only hope they know better than me.

 

25 minutes ago, DarkNounours said:

I think, from a CKAN user point of view, getting a TS patch one by one this way could be just what an end user could expect.

Yep, it's what I think too. However, the transition will be a hell of a trauma.

Using NF as example: as soon as I deprecate the NF patches from TweakScale, everybody that uses NF add'ons will suddenly have all they crafts files unescaled. Worst, the living ones on the savegame too.

The ideal solution would be CKAN having "conditional dependences", ie, if you have Add-On "A" and Add-On "B" installed, so CKAN will install "C" automatically. That would solve my problem for good, but there's nothing like this as far as I know. So all I can do is to "recommend" or "suggest" Add'Ons, but even that is not conditional - and would not make sense to recommend or suggest the NF Patches to people that doesn't have NF installed.

Currently, I'm toying with the idea of creating a mini package system for TweakScale - something that would known about the existing (homologated) patches somehow and then would stop KSP from running if something is missing, indicating the place to download/install the missing patches. But all of this is terribly brainstoming yet, I didn't even create an Issue for it yet.

 

35 minutes ago, DarkNounours said:

By the way, have you already worked on NF patches ? Because this is something I intented to do  

Nope. I used NF as an example because they are, currently, one of the most "problematic" ones to be externalised due popularity and fragmentation. I solve the problem for NF add'ons, I solve the problem for everybody else.

Good to know you plan to support them. This is the reason I plan to create these "Add'On Add'Ons" thingy (meta-recursion, yeah!)

[kcs123]

48 minutes ago, Lisias said:

The ideal solution would be CKAN having "conditional dependences", ie, if you have Add-On "A" and Add-On "B" installed, so CKAN will install "C" automatically. That would solve my problem for good, but there's nothing like this as far as I know. So all I can do is to "recommend" or "suggest" Add'Ons, but even that is not conditional - and would not make sense to recommend or suggest the NF Patches to people that doesn't have NF installed.

Non ideal but similar solution already exist in CKAN. Trough recommeded or optional(suggests) mod install. For example, look at "Automated Screenshots & Saves 0.8.4.3" in CKAN on Relationships tab page. That add-on or mod have hard dependency(can't work without it) on ToolbarController and Click TroughBlocker mods. There is also recommended mod "The Janitor's Closet 0.3.5.1". Automated Screenshots & Saves mod will work just fine without it. However, if you choose to install The Janitor's Closet, it is also hard depended on Click TroughBlocker (can also be any other mod) and CKAN will install it if it is not installed previously by any other mod. The Janitor's Closet again recommed additional mods and it's possible dependencies.

So, in case of NF patches, solution would be to create separate mod or add-on archive to download and in CKAN metadata files such mod need to have hard dependency on tweakscale mod and NF mod. Therefore it can be installed as standalone mod trough CKAN. At the same time some changes have to be made on NF metadata too, to include new NF tweakscale patches as recommended mod. People who use CKAN for installs would most likely also install offered recommended additions, so possible "damage" on ongoing saved games will be minimal.

Just have to coordinate separation of NF patches from TS with main NF mod metadata files. CKAN staff will most likely help you with all this stunts and recommend best option how to do it. I thing that it might be even possible to separate NF patches in that way even before removing those from main TS install if new NF patches go to same folder as it is now, but have to ask someone of CKAN maintainers about details.

[Lisias]

1 minute ago, kcs123 said:

 However, if you choose to install The Janitor's Closet, it is also hard depended on Click TroughBlocker (can also be any other mod) and CKAN will install it if it is not installed previously by any other mod.

And that's the problem. The user needs to know he/she have to choose them. He/she fails to do so, and the savegame is corrupted on the next load.

 

2 minutes ago, kcs123 said:

So, in case of NF patches, solution would be to create separate mod or add-on archive to download and in CKAN metadata files such mod need to have hard dependency on tweakscale mod and NF mod. Therefore it can be installed as standalone mod trough CKAN. At the same time some changes have to be made on NF metadata too, to include new NF tweakscale patches as recommended mod.

There's yet a new possibility... An CKAN Plugin. I need to study who this stunt works, however.

 

3 minutes ago, kcs123 said:

People who use CKAN for installs would most likely also install offered recommended additions, so possible "damage" on ongoing saved games will be minimal.

I don't share your optimism.  

CKAN itself is also a source of glitches, and it's convenient to avoid creating new ones.

The problem is exposition: TweakScale has a huge user base. 1% of failure on a small user base can be acceptable, but 1% on a huge user base would render me handling an absolute number of problems way bigger than is manageable (or acceptable).

And, looking above, you will see that I already need to promote some hurt to get things tight around here. I need to minimize the pain, otherwise people ends up giving me the finger!!!  

Allowing savegames to be broken is a sin around here, we need to remember that people runs the same savegame for years sometimes. They invest a huge amount of their free time (a very expensive resource for them, due scarcity) on that savegames. We screw their savegames, they screw us sooner or later.

[kcs123]

5 minutes ago, Lisias said:

And that's the problem. The user needs to know he/she have to choose them. He/she fails to do so, and the savegame is corrupted on the next load.

It is not a problem because CKAN would not allow user to install such mod if it is not already installed or it force installing dependency mod prior to installing desired mod. Of course, it is always possible that user mess things with manula installs, but it is less likely if he use only CKAN installs.

10 minutes ago, Lisias said:

I don't share your optimism.  

CKAN itself is also a source of glitches, and it's convenient to avoid creating new ones.

The problem is exposition: TweakScale has a huge user base. 1% of failure on a small user base can be acceptable, but 1% on a huge user base would render me handling an absolute number of problems way bigger than is manageable (or acceptable).

Well, on current state of KSP development and add-on development (all always moving target) it is impossible to create everything to be completely foolproof. At some point of development you have to draw a line somewhere, how much time you possible can to spend on working on something, you can't postpone some decisions forever. Otherwise you will burn yourself out very quickly.

But, with some colaboration between CKAN staff and other developers of add-ons (both, main developer and developer of TS patches for such mod), possible damage can be minimised. You can also start showing warning messages trough TS plugin that patches for other mods will be removed soon, so user can know what will going to happen in near future and be prepared for it.

[Lisias]

20 hours ago, kcs123 said:

It is not a problem because CKAN would not allow user to install such mod if it is not already installed or it force installing dependency mod prior to installing desired mod. Of course, it is always possible that user mess things with manula installs, but it is less likely if he use only CKAN installs.

It's the other way around! The problem is the current instalments!

Joe Kerbal has NFA and TweakScale 3.4.3.10 . I (think) will issue 2.5 with NFA on its own Plugin, under a new CKAN netKan file. Suddenly, TweakScale is not patching NFA anymore, Joe Kerbal needs to download and install a new Add'on - otherwise his savegames will be kaput on load.

Manual installers will download the file by reading my announce here, or by using KSP-AVC where I added the option to show the CHANGES where the need to install TweakScale Companion for NFA (or something like that) will be advised. And I advertise S.A.V.E. on almost every post of mine (and I just did it again!) - so I have the manual installers already covered.

CKAN users, on the other hand, rarely are aware of an update, CKAN does everything automatically. This guy is the one that will be caught with his pants down on the transition.

 

20 hours ago, kcs123 said:

Well, on current state of KSP development and add-on development (all always moving target) it is impossible to create everything to be completely foolproof. At some point of development you have to draw a line somewhere, how much time you possible can to spend on working on something, you can't postpone some decisions forever. Otherwise you will burn yourself out very quickly.

That's my secret, Captain! I'm already burnt!  

I AM one of these guys that had their savegame tampered by this mess I'm trying to prevent. More than once. I'm still trying to fix my career I started on 1.4.3, as half the Add'Ons I was using were broken, half of them broke something else when fixed, and the remaining ones don't works on newer KSPs .

So I'm focusing again on 1.7.3, fixing and backporting fixes to be run on 1.7.3 so I can finish my god damned career!!! 

I have a personal moral guidance: I don't do to people what I don't like it's done to me. I don't like my savegames being corrupted, neither updates that breaks things fortuitously and/or without warning. So I try to my best effort to avoid doing that to people.

I have a slight advantage on some authors around here - I don't get any money on this. So, I'm not compelled to break my rules to prevent any loss of "revenue", being it patronage or plain donations. So I don't have strings attached, and I'm free to do what's right.

And keeping long date, faithful gamers happy, paving the way for them keeping their savegames healthy and working until the day they feel comfortable enough to update KSP (or not, you can bet your mouse TweakScale will support again 1.3.1 and 1.2.2!), is the right thing to be done. So I will do it.  

We loose users faster and easier than we gain new ones, sir. We do better than the "competition", or users flee.

 

20 hours ago, kcs123 said:

But, with some colaboration between CKAN staff and other developers of add-ons (both, main developer and developer of TS patches for such mod), possible damage can be minimised. You can also start showing warning messages trough TS plugin that patches for other mods will be removed soon, so user can know what will going to happen in near future and be prepared for it.

That's the magic word: collaboration.  Unfortunately, things are not better enough to expect it - but, granted, nowadays they're better enough to hope for it.

But, yet, this is a problem related to TweakScale only - so it's kind of unfair to expect other people to solve it for me. Before asking for help, it's wise to have a proposed solution for it first - and then allow the fellow Kerbonauts to work on it to make it better if needed. Otherwise, I would ending up being forced to accept half-baked solutions that would only delay a proper solution for my problem - what's, frankly, I think it was the usual way in the past.

Edited December 31, 2019 by Lisias
got bitten by the auto-complete. again.

[Arco123]

I'm wondering if the small white box is a error of 1.8. I'm thinking of updating to 1.8.1. But is it a bug of tweakscale in 1.8 or just a install oops.

[Lisias]

2 hours ago, Arco123 said:

I'm wondering if the small white box is a error of 1.8. I'm thinking of updating to 1.8.1. But is it a bug of tweakscale in 1.8 or just a install oops.

It's a bug on the prefab on KSP 1.8.0 . Nothing bad happens, other than making your life a misery while trying to use the controls.

Please upgrade to KSP 1.8.1. Not only the UI widgets, but some other annoying glitches were also fixed:

Quote

+++ Bugfixes
* Fix game settings being reset every time game is started.
* Fix Linux mousewheel scroll direction.
* Fix bug with interstage fairings not occluding everything within.
* Fix the mk3 shuttle cockpit lights.
* Fix duplicating module info on part extended tooltips in editor and RnD scenes.
* Fix shroud shading on disconnected sub-assemblies in editor scene.
* Fix FloatEdit and ScaleEdit UI prefabs.
* Fix KSC vessel markers becoming too persistent and not leaving the game when switching between buildings at the KSC until game is restarted.
* Fix NREs in Portrait Gallery when kerbals die in flight.
* Fix T-100 fuel tank clipping on surface attach node.
* Fix kerbal helmet/heads becoming unclickable when on ladders.
* Move the CB cast shadows game setting to the graphics section of settings where it should have been.
* Fix Easter eggs, monoliths, randoliths not receiving CB shadows.
* Fix parts still being considered shielded from airstream after deploying a fairing in some use cases.
* Fix Action groups icon not appearing in Editor scene when switching between facilities with different upgrade level.
* Fix Altimeter and Staging tumblers disappearing at some scale values.
* Fix walk paths around Level 3 R&D building. This includes texture artifacts for the Linux version.
* Fix material artifacts in level1 and level 2 grass tiles.
* Fix error when pressing undo while holding a radial symmetry part.
* Fix Ocean on Eve.
* Fix DragCube generation discrepancies in partdatabase - was affecting drag and thermals.
* Fix NRE in editor scenes when reverting from flight and using transform gizmos.

+++ Mods
* FloatEdit and ScaleEdit PAW prefabs fixed.

Making History 1.8.1

+++ Bugfixes
* Fix unable to select "Create new mission" button on Mission play dialog the very first time.

+++ Missions
* Fix mission "Meet Me in Zero G" does not complete in certain conditions when landing back on Kerbin.
* Fix Manufacturer name on engine plates and tubes.

Breaking Ground 1.3.1

+++ Bugfixes
* Fix items in PAW switching positions in a group depending on state of fields.
* Fix generation of free Electric Charge for robotic parts if stopped with the PAW closed.
* Fix setting robotic part motors to disengaged in editor and then persisting that way when vessel is launched.
* Fix bug related to being able to delete endpoints on KAL-1000 tracks by disabling ability to delete them.
* Fix bug when removing parts from vessel and they have multiple actions mapped in KAL.

source: KSP 1.8.1 Release Notes.

 

[Arco123]

2 hours ago, Lisias said:

It's a bug on the prefab on KSP 1.8.0 . Nothing bad happens, other than making your life a misery while trying to use the controls.

Please upgrade to KSP 1.8.1. Not only the UI widgets, but some other annoying glitches were also fixed:

 

I assume reinstall the latest version of ksp and then install tweakscale right?

[Lisias]

2 minutes ago, Arco123 said:

I assume reinstall the latest version of ksp and then install tweakscale right?

Yep!

One thing I like to do is just copy & paste the KSP dir into a backup, and then after updating, copy everything (but Squad/ and SquadExpansion/ !) from the backup's GameData to the new instalment (as well the saves/ too!). Be sure to copy and not to move (hit ALT, so you can see a "+" signs on the icons being dragged).

Of course, if you use CKAN, just let the tool do it for you.

Scale Safe!!
(had I mentioned today that I strongly advise to use S.A.V.E.  ?)

 

[Arco123]

I have a better way of doing that

Delete the old then download the new then go to recycling bin, grab it, then merge with new folder and click x. It does the job just as well. (ie: new folder files overwrite old ones if both are present.)

Also thank you for this wonderful mod. It's great for making cinematics lol and it saves part counts to the max...

[dave1904]

I am getting a warning on start up.  If you want logs to help you fix issues I can upload but otherwise I can wait for a future version. 

Edited January 9, 2020 by dave1904

[kcs123]

4 hours ago, dave1904 said:

I am getting a warning on start up.  If you want logs to help you fix issues I can upload but otherwise I can wait for a future version. 

It may be harmless or already known issue. But it can also be something entirely new. It is hard to tell you good advice until exact content of warning message is known.
So, sending full log would not hurt and it will definitely help to know what is going on, to help you resolve any doubts and issue sooner, rather than later.

[Lisias]

9 hours ago, dave1904 said:

I am getting a warning on start up.  If you want logs to help you fix issues I can upload but otherwise I can wait for a future version. 

As a rule of thumb, if the Warning is a "yellow" one, it's an annoyance - nothing will break, as the glitch was detected and the affected part had TweakScale withdrawn from it. You cannot scale it, but by trying to scale it the game would break or crash, so you are not loosing anything (but headaches).

The red ones (the "Houston"s), however, demands immediate action. If you are "houston'd", cry for help here on the spot and don't proceed with the game - at least, without using S.A.V.E. first. Most of the time nothing bad will happen [nowadays] , but sometimes the savegame can be corrupted (and this is the reason I created that Houston stunt). There's a screenshot of one of these here if you are curious.

 

4 hours ago, kcs123 said:

It may be harmless or already known issue. But it can also be something entirely new. It is hard to tell you good advice until exact content of warning message is known.
So, sending full log would not hurt and it will definitely help to know what is going on, to help you resolve any doubts and issue sooner, rather than later.

New parts using current unsupported modules will earn an "Yellow". So not necessarily a "new problem", only a new issue from the same old problem.

My main debits on the matter nowadays are the buoyancy module from FireSpitter and the MODULE PART VARIANT that some Stock parts uses. As soon as I get time  (and the mood - boy, I'm still recovering...) to analise these things, most of the warnings will just disappear for good.

Edited January 9, 2020 by Lisias
added a small fix on the argument, in italics and between braces.

[dave1904]

8 hours ago, Lisias said:

The red ones (the "Houston"s), however, demands immediate action. If you are "houston'd", cry for help here on the spot and don't proceed with the game - at least, without using S.A.V.E. first. Most of the time nothing bad will happen [nowadays] , but sometimes the savegame can be corrupted (and this is the reason I created that Houston stunt). There's a screenshot of one of these here if you are curious.

 

I got this man and did not have the balls to start. I am curious now. What do you need?

[Lisias]

41 minutes ago, dave1904 said:

I got this man and did not have the balls to start. I am curious now. What do you need?

Full KSP.log published on some file sharing service. More than less the Module Manager Cache files are also useful (mainly to cook fixes), so doesn't hurt to include them. It's better to delete the caches, launch KSP until you see the Houston, close KSP (extremely important if you use Hyperspace.dll) and then shove KSP.log and the MM caches (put them all and call it a day) on a zip file and upload it to dropbox or something.

[dave1904]

17 minutes ago, Lisias said:

Full KSP.log published on some file sharing service. More than less the Module Manager Cache files are also useful (mainly to cook fixes), so doesn't hurt to include them. It's better to delete the caches, launch KSP until you see the Houston, close KSP (extremely important if you use Hyperspace.dll) and then shove KSP.log and the MM caches (put them all and call it a day) on a zip file and upload it to dropbox or something.

https://drive.google.com/open?id=1QVdV1PaYEHdB9JtaUGIEwj8ZTEpJ0Oln

Did not include the Extra or Local folder. I do not think it matters but you should know everything. 

Edit: I also did not use the version of module manager included since I am using ModuleManager.4.1.3 

Edited January 10, 2020 by dave1904

[Lisias]

4 minutes ago, dave1904 said:

https://drive.google.com/open?id=1QVdV1PaYEHdB9JtaUGIEwj8ZTEpJ0Oln

Did not include the Extra or Local folder. I do not think it matters but you should know everything. 

Got it! Let's crack this nut:

[LOG 02:57:01.800] [TweakScale] INFO: WriteDryCost Concluded : 2737 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 2 Show Stoppers found; 9 Sanity Check failed; 1165 unscalable parts.

Yep. 2 Fatalities.That 9 "Sanity Checks" are what I talked about on that "yellow" thingy. You also have 1165 unscalable parts, what means parts that no one had written patches for, so TweakScale can't scale them.

About that two casualties:

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

I think I had handled this already, let me check the ^Knowledge Base"  (hitting the search button, being warned by forum I need some seconds between searches, hitting the search again a bit too early, bring warned again… ok, you got the drill.  ).

Here:

Spoiler

 

Unfortunately, it's a bug on CxAerospace (that I confirmed you are using). It have a rogue patch messing up a bit with Bluedog's ones.

The real problem is that CxAerospace is restrictive - I can't fix the thing myself, as the copyright forbids me to redistribute the fixes. And the original Author is not available anymore to submit patches (at least, it wasn't the last time I checked - I think on November last year?

However, TweakScale is not only about scaring messages, we provide some solutions (most of them without providing you with new problems bundled!  ). Do as follow:

Quote

Locate the distribution file on your Downloads (or download the latest version again), and then copy the following file(s) from the distribution package:

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

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

GameData/__LOCAL/TweakScale/HotFixes

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

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

(for my control: source post).

This should fix the parts so you can use them safely!

[dave1904]

35 minutes ago, Lisias said:

This should fix the parts so you can use them safely!

Working now with yellow "warnings" 

BTW I am only using the docking ports and pressurized mating adapter an from CX aerospace.(I delete any parts from mods that I do not need since it makes the install cleaner and faster) Could delete the tweakscale config in Cx Aero anyway since it only seems to patch module command.

 

Should I delete CXA_TweakScale.cfg or just leave it? I like to delete unnecessary patches anyway. 

Spoiler

 

// TweakScale patch for CxAerospace Station Parts Pack

// Created by KSP forum user VenomousRequiem.

SCALETYPE
{
    name = crewfree
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 100, 150, 200,  300, 400
    incrementSlide =  1,  1,   2,    5
}

@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace]
{
    %MODULE[TweakScale]
    {
        type = free
    }
}
@PART[*]:HAS[#author[cxg2827]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[<1]]]]:AFTER[CxAerospace]
{
    %MODULE[TweakScale]
    {
        type = free
    }
}
@PART[*]:HAS[#author[cxg2827]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[>0]]]]:AFTER[CxAerospace]
{
    %MODULE[TweakScale]
    {
        type = crewfree
    }
}

 

 

Edited January 10, 2020 by dave1904

[Lisias]

1 hour ago, dave1904 said:

Should I delete CXA_TweakScale.cfg or just leave it? I like to delete unnecessary patches anyway. 

You can safely delete it - but then you must remember to delete it again when you update TweakScale. In a way or another, this is one more reason to "split" the current distribution between TweakScale + stock patches, and "TweakScale Companions" for supporting third parties.

(this is not happening on the near future, lots of things should be done first!)

Probably a more convenient solution would be a custom patch to be shoved on the __LOCAL folder deleting all the patches you don't want - so you can just forget about deleting things manually on updates, as __LOCAL is a place where nobody else touches (ideally).

Try this (source):

@PART[victim1,victim2,etc]:FINAL
{
	-MODULE[TweakScale],* { }
}

On a file somewhere in the __LOCAL (I like GameData/__LOCAL/TweakScale/hacks).

 

1 hour ago, dave1904 said:

Working now with yellow "warnings" 

Same thing. On your case (looking into your KSP.log):

@PART[EnginePlate1p5,EnginePlate2,EnginePlate3,EnginePlate4,Tube1,Tube1p5,Tube2,Tube3,Tube4]:FINAL
{
	-MODULE[TweakScale],* { }
}

on GameData/__LOCAL/TweakScale/hacks/no-more-warnings.cfg (or something like that).

Until something else is installed that would trigger an "Yellow", this stunt will prevent the current Warnings to be issued on your instalment. The side effect will be not scaling them when I finally pay my technical debits on this, but since I will probably make a hell of a fuss about it, you may be aware of it at that time.  

[dave1904]

1 hour ago, Lisias said:

You can safely delete it - but then you must remember to delete it again when you update TweakScale. In a way or another, this is one more reason to "split" the current distribution between TweakScale + stock patches, and "TweakScale Companions" for supporting third parties

Cheers man, thanks alot! 

[tinygrox]

How can I contribute?

[Lisias]

4 hours ago, tinygrox said:

How can I contribute?

Dude, thanks!

There're two main ways of contributing to TweakScale: bug reporting and bug hunting.

Right now, I have a hell of a problem to hunt: some parts are being scaled wrongly, because they were patched with the wrong defaultScale!

A defaultScale is how we tell TweakScale how it should handle "100%" on a part - a Mk1 cabin at 100% is 1.25, but a Rockomax tank is 3.75 (if the memory serves me well). So when you say "scale this thing to 1.5 radial size", TweakScale knows what to do and keep things proportional.

However… I found at least one part on TweakScale that have this defaultScale thing set wrong. And this is a pain in the SAS (to say the least), because forces you to scale such parts differently from the other parts, and exceptions are bad: it forces you to remember things unnecessarily - instead of thinking "every Ml3 parts scales from a 3.75 base", now every body has to remember that the Engine Plate scales com 2. Sounds silly, but a lot of nasty bugs can happen when you forget these exceptions, and this is the cause you must do all we can to keep them at the base minimum necessary, and not a single one more.

This is what happens when you scale something with that problem:

Every Mk3 parts on this thing was scaled to the same radial value, but the engine plate was scaled wrongly - because currently, it has the wrong defaultScale of 2 and not 3.75 as it should .

Right now, the best thing in which can help me is to check every single Stock (and DLC) parts with TweakScale on your gaming rig to verify if they have the correct defaultScale. You can check it looking directly on the patch file:

@PART[adapterSize2-Size1Slant]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 2.5
    }
}
@PART[adapterEngines] // Mk3 Engine Mount
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 2.5
    }
}

@PART[Size3LargeTank] // Kerbodyne S3-14400 Tank
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 3.75
    }
}

The kerbodyne S3-14400 and that adapter has correct defaultScales (3.75 and 2, respectively). But the Mk3 Engine Mount is wrong, as it's a 3.75 but the patch thinks it's 2 - and so, things goes down trough the tubes on scaling.

Alternatively, you can fire KSP, shove a bunch of parts, scale them all to 1.5 (or lower) and check for visual differences. Then scale them to 5 (or bigger) and do the same - you should get something as the image above when you find something wrong.

Please report any findings on https://github.com/net-lisias-ksp/TweakScale/issues/87 .

[Lisias]

Retaking the line of though due a idea I had for a new stunt!

On 12/30/2019 at 1:39 PM, kcs123 said:

Well, on current state of KSP development and add-on development (all always moving target) it is impossible to create everything to be completely foolproof.

It's true. However, I just realized something… KSP 1.8.2 is a moving target, KSP 1.8.1 and older are not, they are stationary targets - they will not change no matter what. So they are solid cornerstones to build artifacts even by being buggy, once you learn how to cope with the bugs (I'm trying to "fix" the UI for KSP 1.8 on KSPe, just to build a proof of concept on the thing… not to mention some fellow Kerbonauts already patching KSP 1.8.x for preventing a craft conversion bug..).

So we don't have a problem on moving targets, we have a migration problem! I don't need to know how KSP 1.8.2 will behave as long as I have how to migrate to it without breaking things that are working on KSP 1.8.1 and older.

That said, how I can use this to my favor? This is what I'm thinking about these days about that Engine Mount glitch - it hurts being broken, but it will hurt to fix due the hurt of being broken… And I came to realize we (me and previous TweakScale maintainers) had drawn ourselves to a corner because we didn't versioned the data on the craft file - I don't have the slightest clue about what TweakScale had generated that data, so I don't know how to migrate things to the newer state. A mistake that KSP didn't made, as every data file has the KSP version used to create it (and this is the reason that fellow Kerbonaut managed to fix the craft migration!).

So, assuming a versioning inserted somewhere on the craft file that states the TweakScale patch revision used, and since I now know the problems that such TweakScale patch revision had, and since I'm building the next TweakScale, the solution is obvious: if loading a craft from a older TweakScale, migrate the problems to the fixed revision. And the user will ever notice something had changed, things will just keep working transparently.

Currently there're no revisioning on TweakScale patches, but yet it's usable - next TweakScale will have the "patch revision 1", the absence of the revision will implies "patch revision 0" and the migration tool can still be implemented.

Unless something clever is proposed by someone else, I think this is what I'm going to work on the next holidays around here...

 

[kcs123]

Inserting version number into craft file would certainly help in future migration. Transition for proper craft files should not be much of issue. Problems might arise, though, with old craft files that contain parts with already built in broken TS patches. So, itm might be good idea to develop procedure how to detect already broken craft files within saved games and warn users about it, so savegame can be repaired before it become broken even more.

Can similar method as it is used on starting KSP, to detect broken MM patches on startup, to use it to detect broken craft files, inside savegame and standalone craft files ?
Once you got "patch revision 1" within craft files, any possible issue would be known and most probably method how to fix them, so that possibly can be automatic on "patch revision 2".
But, "patch revision 0" can contain almost any kind of bug that is solved long time ago and it will be much harder to detect and fix.

Regardless, TS version number within craft files and savegame files would help a lot in any future attempt to salvage old career savegames.
Just few thoughts about it, not sure how feasible is idea of detecting broken MM patches within savegame and craft files.