Lisias

Well… I made a research on the matter, and got into this: change, the last change before, oldest mention of the file before a internal refactoring, and the first time MMPatchLoader was extended with LoadingSystem. This first LoadingSystem commit was made in 2014, so we have 5 years of a public class being served to the general public!! So I understand the reason Add'Ons choose to hook this way: it's available (it's a public class!) and it was stable for 5 years. It's my understanding that internal classes should be declared… internal… and that public classes are intended to be consumed by the general public. Of course, perhaps the MMPatchLoader should never be declared as public at first place - but yet, we have a de facto standard that in an ideal world, should not be changed without a reason.

I I think it's premature doing something by now. By checking MM's commit history, you will realize that that line of code was there for years. Check: change, the last change before, oldest mention of the file before a internal refactoring, and the first time MMPatchLoader was extended with LoadingSystem. This first LoadingSystem commit was made in 2014, so we have 5 years of a public class being served this way!! (yeah, I did my homework!! ) It's my understanding that classes not intended to be reused should be internal, private or whatever - so I found very understandable the reason Welding Tool decided to use it. So this is a unfortunate event and will be reverted, or it is part of a ongoing major overhaul of MM and will change again. In both cases, we need to wait and see - and if the later, I intent to tackle the problem on KSPe by creating a proper public interface to the feature, so every time MM brakes something, KSPe would be the only thing to be updated. Doing anything else would be playing catch and mouse with MM - hardly something enjoyable to users and developers.

So… For ones in need of a fixed working Welding Tool, the 2.6.0.4 release. Download: https://github.com/net-lisias-ksp/UbioWeldContinuum/releases Issue tracking: https://github.com/net-lisias-ksp/UbioWeldContinuum/issues Dependencies: https://github.com/net-lisias-ksp/KSPAPIExtensions/releases/tag/PRERELEASE%2F2.1.1.0 https://spacedock.info/mod/1689/Click Through Blocker https://github.com/linuxgurugamer/ToolbarControl/releases The Change Log is huge, I suggest reading it right from the source. This thing is welding fine as long you don't try to weld parts with ModulePartVariant - it will weld the part, but the welded part will behave (and look!) erratically. The best workaround is to weld your parts on KSP 1.4 (where no but one part uses ModulePartVariant) - but them you can have problems with parts gone into the zDeprecated folder. You also need to use ModuleManager 3, as the 4 changed in a way that broke the Welding Tool. If you really want MM4, see the Known Issues file for tips. Unless I had borked (yet another time), I think this release will be somewhat definitive for this code-tree. Kick me on the Issue Tracker (or privately if you prefer). (and yes, it's late night - Venusian Local Time. )

If you don't mind restarting the game, yes. But UbioWeld and that hypothetical solution above on deprecated parts would preferably avoid restarting everything and load the config into memory at runtime and then carry on with their business, using the very same ModuleManager code that would be used on KSP loading time. It's how it was being used on the Module Manager 3 and previous., by the way.

Because it is how UbioWelding creates welded parts on GameDatabase. Using Mono's Reflection to locate MMPatchLoader for now can be unreliable due Mono's unhappy bugs on Reflection, and I think this is the reason MMPatchLoader extends LoadingSystem : to allow to use UnityEngine's equivalent. Better idea: each Add'On specifies what it needs, and MM only handles what it was specifically told to do. This would impose a delay only for the first Add'On to ask for something that's not there yet.

Yep. @OPBlue ?

The problems,we tackle them one by one. And I think that Module Manager can help on it too. I'm mangling GameDatabase for some time now, and it's really not a problem to "brute force" a part into it - so yeah, we can feed GameDatabase with the deprecated parts ourselves. Ideally, this should be done on Module Manager, as it always have the MMPatchLoader available to itself, and since MM4 outsiders lost the canonical way of invoking it.

I think that this problem can be mitigated on a better way. Module Manager would issue a "meta-name" with the current KSP version, so you can use ":NEEDS" et all to check the current KSP version in the same way we do for Add'Ons. Something like: KSP_<MAJOR> KSP_<MAJOR>.<MINOR> KSP_<MAJOR>.<MINOR>.<PATCH> So the author would peek the less restrictive one that works for him. As an example @PART[airbrake1]:FOR[TweakScale] // A.I.R.B.R.A.K.E.S { %MODULE[TweakScale]:NEEDS[KSP_1.4.5] { type = free_square_old_edition } %MODULE[TweakScale]:NEEDS[KSP_1.6] { type = free_square_new_edition } %MODULE[TweakScale]:NEEDS[KSP_1&¬KSP_1.6&¬KSP_1.4.5] { type = free_square_common_edition } } Would define a Module with type "free_square_old_edition" for KSP 1.4.5, but would define it to "free_square_new_edition" for KSP 1.6.0 and 1.6.1 (or 1.6.2 if it would be issued). But "free_square_common_edition" would be issued for every KSP version that starts with 1, except 1.6 and 1.4.5 . (I'm not sure now about the correct syntax on MM, so I used the following boolean notation : "&" = AND ; "¬" = NOT) I think this will solve pretty well a lot of issues.

This thing gave me some ideas….

In my humble opinnion, KPS Demo still serves perfectly to its role. It's possible to download it on Steam if you now how to handle the Steam Console. Step by Step instructions here:

Ask Squad. There're some concurrency right now on KSP, and that's the reason I'm asking for mutexes while accessing the GameDatabase. And no, I'm not talking about co-routines. KSP is calling Add'Ons concurrently on the Main Menu Scene. Making History, ScanSAT and KIS (that i'm currently aware of) instruments the GameDatabase simultaneously and I had to do some interesting stunts on TweakScale to cope with them. A mutex on the GameDatabase would had saved me from handling a lot of nasty stuff. Module Manager 4 is doing that too - it's the reason it's loading faster now, it applies the patches while KSP is loading the textures/meshes/etc. It's tricky, but it is doable. About multithreading on UI, frankly this is common business. I already had that on Win32 (1995, baby), I already had that using AWT, I already had that using LWUIT (on freaking Nokia and Samsung feature fones!), I already had that in Android. You just don't handle UI events on the main program loop (or vice-versa), and this is common business for about 25 years already (and I'm plain ignoring UNIX, shove more 10 years on it). Last time I had to cope with a single threaded UI I was coding for Windows 3 or for MS-DOS using Turbo Vision. It's time to stop excusing this by now, Unity is late due on this. Utterly. Developers get paid by doing hard stuff - the easy stuff end users can do it by themselves, they don't need to pays us for that.

Yet.

I can add some more delays on TweakScale, if you want some more loading times!!!!

Damn. I thought I had fixed this last time I made a release. I was wrong. I didn't made the Kraken damned release!!! I'm working on it, it should be available late night, after some pending activities of the day... — — POST - EDIT — — I just remembered what I was doing in December on UbioWelding. Not big deal, but I think it will worth finishing it!!! Release on the weekend!

I want mutexes for handling concurrency on some critical parts of KSP guts. As GameDatabase.

Believe it or not, it would be counter productive! the debugging potential for both cases are better with you tweaking TweakScale without caring or knowing about TS intrinsics and with me not taking design decisions for AllTweak. It's kind of a black box testing, when the thing is put to use in a uncontrolled environment, where people can do unbiased testing decisions. I would ending up filtering good ideas due my knowledge of how TweakScale works - that "for whom have a hammer, every screw is a nail" thing.

Yes, but not exactly how you expect. When free scaling is available, the node is being scaled by the formula: node.size = (int)(tmpBaseNodeSize * tweakScale / defaultScale + 0.49); There's also an array called "ScaleNodes" that you must define on the ScaleType, one for each ScaleFactor. For example: SCALETYPE { scaleFactors = 0.1 , 0.3 , 0.625 , 1.25 , 1.875 , 2.5 , 3.75 , 5.0 , 7.5 , 10 , 20 scaleNodes = 1 , 1 , 1 , 1 , 2 , 2 , 2 , 3 , 3 , 3 , 3 } Would force the node size to 1 for scales [0.1, 1.875[ , 2 for the scales [1.875, 5.0[, and so on. interesting enough, no default TweakScale patch make use of this. But it's available on the code, and on a fast eyeballing it appears to work. Please try it and kick me here if anything goes wrong. If we have a bug on this, I want to have it worked out for the next minor release!

This is a Mac problem. Thanks Apple and/or Unity for that. Close Safari and any other program also using the GPU - this started to happen to me when Facebook start to show that fancy 2D images with depth, simulating stereoscopy.

You saw it first here, on Kerbal Space Program!

I use GIT on everything nowadays. You don't really have to push the commits to a external repository (but I use a private account on bitbucket since I dumbly deleted a test savegame that wasn't a test savegame). The last big bork on TweakScale screwed up ALL my savegames. It was a silent corruption - and once the corrupting Add'On was uninstalled (for unrelated reasons - I just concluded it didn't fit on the current RPG on that installment), I ended up with ALL my crafts and savegames mangled to a terrible state. I spent the whole week fixing all of that - I'm kind of expert on these things nowadays. Oh, that savegame I deleted by mistake? Was due this - since it was supposed to be a test savegame, it didn't worth the pain to fix it. But that savegame had some interesting crafts I ended up building for testing and didn't moved them to a proper place yet. (sigh) Well, so is the life. — POST EDIT — In time, these breakage is exactly the reason I issue the beta! Could you please send me your KSP.log, out_put.log and MM caches? This will help me to code a Sanity Check to prevent this happening again!

Good night.

It's a debt of mine that will be paid when I manage to get KAX on the focus on my activities. :-) On the mean time, there're some albums and screenshots from the previous maintainers that I prefer not to directly link on the OP as is their work, not mine. You will find images on the following links: https://kerbal.curseforge.com/projects/kerbal-aircraft-expansion-kax/images https://forum.kerbalspaceprogram.com/index.php?/topic/155448-122-kerbal-aircraft-expansion-kax-v264/&amp; But google, currently, does a better job than I could do, so use this link!

Hi! I'm searching for TweakScale issues in order to see if there's something more to be done before the next major release, and found this: Well.. This usually happens because as soon as Module Manager finishes the patches and KSP the assets loading, some Add'Ons use the "Main Menu" Scene to finish some business. TweakScale is one of these, but Making History, KIS, ScanSAT (are surely others) do it also. Some of them tries to instrument GameDatabase too, and when this happens, someone somewhere will bork due uncontrolled concurrency. And since TweakScale sticks its nose on every existent part on the Kerbol, these situations fatally leads to someone borking - usually TweakScale. The next minor release, 2.4.3, apparently managed to find a way to preventing being overran on interim and some field tests. It will be on the wild in the next days, I hope! Cheers!

You get used to it. Trust me. Something doesn't compute. I have Mk2Expasion too, and I don't remember seeing this… I will do some more checks! — — — POST EDIT — — — I found no occurrence of this last problem using a clean install with the bare minimum to run Mk2-Expansion (and EDU) with the latest release of TweakScale. We have some Kraken food here. It's a third Add'On stomping on our feet.

Exactly. On the top one, somebody is shoving "free" when he/she had to put a "true" or "false". On that part of the code, TweakScale is reading the SCALETYPE, and the "freeScale" datum is a boolean. I suggest you to search all the patches for "freeScale = free" to see what you get. On the bottom one, apparently M2X_SCRCS is trying to redefine some TweakScale default ScaleExponent. However, it's not impossible that yet another one did the stunt for something M2X is trying to create, and so M2X is the Screaming Victim and not the perpetrator. In both situations, it's a patch problem that must be fixed by the Add'On maintainer - as soon as you figure out the right one.