Lisias

I agree, you have some solid arguments. But I'm also happy with @OPBlue suggestions, and for the ones that doesn't fits on KAX, I'm cooking a solution. But make no mistake, you opinion is identically appreciated. It's what will help me on the decision making about what will go to where.

About 9. But this mileages may vary! I usually put people on the ignore list to heat discussions down. Being mentioned on discussions I don't wanna to participate anymore is way annoying, so the easiest way to finish my part on a discussion people insists in dragging me back is the ignore list. Now and then I clean up the list: If I don't remember why I had put the guy there, it's usually a reason to get it out of the freezer. There're about 3 or maybe 4 that will probably be there forever. These are the ones that handles discussions on a somewhat vicious way. I'm a fan of Schopenhauer's "The Art of being Right". Ie: How to detect phallacies on an argument. Now and then everyone mishaps on this (including myself sometimes), but once I conclude the guy is doing it on purpose, he's banned from my timeline for good. Life is too short to be wasted with Intelectual dishonesty.

Oh, that communication line got crossed. Sorry. There're two things, one that is being done now and another that I would like to do instead: 1) Currently, it's using MMPatchLoader's StartLoad to reload the world so the new welded parts became active without restarting KSP. The way the class is searched is specially interesting, as it overcomes the buggy Mono's runtime support for Reflection (long story made short: if anything goes wrong everywhere while loading a DLL, the runtime's Reflection fails miserably for the whole system until restart - damn, I'm becoming repetitive about it). Whatever you do to the public classes of MM that could be reused, allowing it to be found with UnityEngine.Object.FindObjectOfType apparently will save a lot of grief (as it appears to be imune to the problem described). 2) What I wanna do instead is, somehow (and this is just a bit more than a brainstorming now), plain inject the new welded part into the GameDatabase without reloading the World. Mangling parts on the prefab is not exactly hard, what's hard is to avoid breaking people on the process, and this is where MM could be a huge differential: a common ground mechanism, with concurrency being correctly dealt, to allow safe GameDatabase mangling. That item 2 thingy would help too to prevent stunts like this one I made on TweakScale - a lot of Add'ons (including the current SquadExpansion and probably the future new one) uses the Main Menu Scene to carry on some unfinished business on GameDatabase, and with everybody running concurrently, a awful amount of feet stomping would be avoided. — — — POST - EDIT — — -- 3) There're a third suggestion that could be lost in the stream, I will avoid repeating it by linking it here.

What ended up allowing the class to be handled by Unity's reflection nevertheless. Being intentional or not, it ended up being the mechanism people managed to reuse that class for some years. It's what we call a de facto standard. The whole Add'On scene is unintended and unsupported. We are at our own here. All that can be done is trying to work together, or trying to work in separate ways. Both are valid, by the way - but some ways tends to be more useful to the end users, and IMHO the ultimate objective of every Software is to be useful - so I tend to be somewhat grumpy on everything that hinders the usefulness of the software to the end users. Please observe that I didn't complained on a change on DataBaseReloadWithMM() - had it changed somehow, I would just had coped with the new behaviour and called it a day. The show stopper happened because a change happened that broke down the very mechanism we were using to even safely reach a public class without relying on the buggy Mono's Reflection, so no matter what, I would had to change something that was working safely to something that historically leaded to some grind. Fixing UbioWeld to cope with the current status quo is easy. Doing it safely without uncontrollable side effects is the problem. The safest approach to the problem is keep using UnityEngine.Object.FindObjectOfType, what would need only this patch. No MM code stops working by this (I'm testing this for some weeks now), and everything else just keep working as before without any change. Of course, alternatively it can be decided that MMPatchLoader should not be used by anyone else - I'm Ok with it. Tell us, put an "internal" on the class declaration (so preventing further misunderstandings) and everybody else are free to decide the best way to cope with that.

You missed the point completely. If a change was made on the method, I would had it fixed by now. I'm talking on the class definition itself. LoadingSystem was extending Unity's, and the change that broke me is that Unity's reflection ceased to work on it's and since Moni:'s Reflection is flawed, I ended up without a reliable and sturdy mechanism to find the class. The fix I choose is not the only the easiest, but also the safest. There're few value on working on a new mechanism that would ending up being brittle and leading people for asking for support constantly. And this is the reason I shoved KSPe on my fork anyway, where at least I will confine the problem on a component that already have it. If something brake (and it will, due Mono's runtime data being corrupted when a exception happens anywhere else while loading DLLs), then I have only one thing to fix and update, instead of scattered code over multiple Add'Ons. My intent precisely. If they rollback that single line, problem vanishes. Of course that the new mechanism would not be recognised by WeldTool, but this is not a problem: a punctual update on the code and we would be fine. But, and again, what broke UbioWeld was a change apparently unneeded. No used feature was changed, my MM4 fork is working perfectly fine with my two last releases by only changing a line back - all the rest was essentially the same.

It's usable right now if you use MM3 or my personal fork for MM4 This is not a job. We are not getting paid. There's no guarantees on nothing. But we can do people's life easier or harder - and this will reflect on what people choose to use

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!