No GUI on Module Manager 4.x

[popos123]

Hi, like in title, when you press a icon with welding - nothing happens. On Module Manager 3.1.3 everything OK.

[Lisias]

Yes, we know it. It's a problem on MM4.

Please use my fork of MM if you really think you need MM4.

But, really, MM4 doesn't really adds value over MM3, it't not even faster on a somewhat modded KSP (on my rig, the difference was less than 5 seconds).

Every single patch I ever used worked fine on MM3, so you will not have problems.

[Monniasza]

Yes, we know it. It's a problem on MM4.

Please use my fork of MM if you really think you need MM4.

But, really, MM4 doesn't really adds value over MM3, it't not even faster on a somewhat modded KSP (on my rig, the difference was less than 5 seconds).

Every single patch I ever used worked fine on MM3, so you will not have problems.

The fork didn't work, so mod must be fixed.

[Lisias]

The fork didn't work, so mod must be fixed.

The fork works.

[Monniasza]

The fork didn't work, so mod must be fixed.

The fork works.

The changes in fork must be merged into the original.

[Monniasza]

It doesn't work with original ModuleManager only. KSP.log It works with forked MM and KSPe. It doesn't work with original MM and KSPe. KSP.log

[Lisias]

The fork didn't work, so mod must be fixed.

The fork works.

The changes in fork must be merged into the original.

Now I see. Check the MM's thread. There's a reason I gave up and decided to fork MM for my own use.

It's a one liner fix, something silly that should not be a problem to rollback - had the maintainer completely changed the code to a point it could not be reused, that would not be a problem. But a one line change, without any apparent purpose (as other classes are still extending the LoadingSystem), followed by a dismissive "people uses MM in unintended ways" (or something) IMHO is not a proper way to handle the situation (since the fork).

The decision to fix the upstream belongs to the maintainer, not to me. The fix was proposed since April or May from the last year. There's nothing I can do about.

Please note that the "Original" is a fork from ialdabaoth's (original thread, unfortunately not available anymore: https://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-5-%28Nov-11%29 )

On a side note, there's some critical fixes on the latest MM. Using MM3 is not a safe option anymore.

[Lisias]

@Monniasza , I just saw the answer you got from the MM guys.

I want you to understand something: some people don't care about users (i.e. you). They only care about their public image, and so they don't do "wrong things" and hide any mistakes they make no matter the consequences to the users. They value their "public image" more than the user's satisfaction, so they don't measure efforts to salvage their image completely disregarding users' needs and opinions.

On the answer you got, I detected an attempt to shut you up by disqualifying you as a debater - he didn't even tried to explain anything to you, just made you a question he knows you can't answer - otherwise, you would not be there asking questions, right?

However, there're developers that value users above all. I want to believe I am one of them. I don't mind doing "wrong things" if this is the best way to satisfy the user on the short and on the long run - i.e. I will not do anything that would harm the user at any time even if he asks it, but once what is being asked is harmless (besides "wrong"), I don't mind doing it if this is the best way out of the user's problems.

The LoadingSystem is a kind of "magic": when you want something to be used to load your game on a nice... "Loading Scene", you create your code around this "magic", so Unity will locate and use your code automatically.

The LoadingSystem extends another "magic" thingy, called MonoBehaviour, that is a more generic way of creating and use code that Unity handles automatically - you say "Hey, Unity, this code should be run at Scene XXX. Here is the Awake, Start, Update, etc codes what I want you to call when needed". And so Unity does that for you (we call this whole stunt "Life Cycle").

Code that is not handled automatically by Unity should be loaded and started in memory manually. When they got rid of the LoadingSystem from that code, that code stopped being loaded by Unity, and since the Welding Tool relies on Unity to find and call that code, it was borking because Unity was not loading it anymore.

So, yeah, THIS IS A FIX for the Welding Tool - because once I put it back the Welding Toll came back to work.

It's the best fix? Nope. It's even a good fix? Debatable. But it did the trick, kept Welding Tool (and anything else that would be using it) working at no cost.

What are the consequences of the stunt?

Well, Unity loads it on the Loading Scene, but then detectes that this code has none of the expected hooks to be called by it (IsReady, ProgressTitle, etc), and so it will forget about and leave that code there, eating a bit of memory for the rest of the program cycle (being a cycle everything that happens between being started and finished - by the user or by a crash).

I will admit that I would try to get rid of the thing the same way - what I would do differently is, once I realised this will break user space, I would roll back the change immediately, and then would try to reach a compromise where both sides would end up satisfied (me, as I would be doing something "technically good", and the users that would not have their toys broken by me).

Some people plain forget (or knowingly ignore!) the reason we write programs: to have them used - and people don't like to use things that hurt them without a good reason: people accepts being poked by needles when it's a vacine, but try to poke someone on the streets because it's the easier way for you to accomplish something... ;)

It's the same thing on Software.