Information Requested (Error Unknown, Soft-Lock, WTF is this?)

[Shaggygoblin]

From the #kspofficial IRC Lounge

11:14 can someone point me to specific information on the 'difference' between the ModuleManager (sarbian) and the ModuleManager /L (lisias)(a fork of MM(sarbian))?
11:15 I ask because on the github entry of the older mod I have (zer0Kerbal/FieldTrainingLab) has, on it's github, both MM's listed.
11:15 Browsing the lisias fork of MM shows a TON of commits ahead, but I can find no reference to MM/L when searching the KSP Forum.
11:15 Additionally, the forum entry for zer0Kerbal/FieldTrainingLab does not list the MM/L where the github entry does.
11:15 I 'think' the lisias fork is an attempt to make older mods forward compatible with newer/newest KSP, but need clarification.
11:16 The 'docs' for the MM/L are just clones of the MM(sarbian); no 'new' info there.

Could we get something in the README.md for this fork explaining the reason/core difference for this project/fork to exist?
While I get great lolz out of reading the comments to yourself in the issues (reminds me of my own thought process), it does little to highlight what the end-goal of this fork is...

[Lisias]

Hi, @Shaggygoblin !

As a rule of thumb, if you don't know why use my fork is almost surely you should not use it. :)

The TL;DR is more or less this:

1. Some time ago, a not unreasonable (but surely unneeded) change on "Canon" MM broke Ubiozur Welding Ltd. We reached the MM's maintainers about the problem and asked for a rollback on the change - as the alternative would need reflection, what it's unstable due a KSP bug until nowadays.
   1. My request was downplayed, I tried to argue but the exchange became… counterproductive.
   2. So I forked the damned thing, did the rollback myself and called it a day
2. Since I had forked the damned thing, I reworked the terribly log subsystem it had. The net result is a way more convenient logging (with selectable levels).
3. Found some non functional bugs, and fixed them (as long the fix would not break expected behaviour, being it a bug or not - there's no way my fork would patch something differently than "Canon", and if you find something like this, I consider it a bug and I will fix it).
4. Detected a HUGE major screwup due some really bad decision making both on Module Manager and KSP itself that leaded to choosing the oldest copy of Module Manager when more than one DLL is installed (something that I always had deeply advocated against). My fork have no such problem.
   1. Module Manager Watch Dog was built to handle the issue anyway, because the older Canon MM ended up taking precedence over my fork too - only KSP 1.12.3 made some reasonably (but too few and too late) steps towards a working solution (unfortunately, adding new problems on the process).
5. Canon MM has a weakness (as the problem is essentially how it used a thingy called digest as it would be identity and not exactly the code) where sometimes MM fails to detect a change on the GameData and you end up with incomplete patching being applied (from the MM cache), causing some trouble with add'ons that assume the patches were applied if a directory is present or a DDL is loaded.
   1. My fork works the problem by using a slightly different identity calculation. It's still theoretically prone to false positives, but the chances this would happen now is some orders of magnitude smaller then the current Canon approach.
   2. If you are curious, digests are meant to calculate integrity, and using them to hash identities is usually a bad idea - you need more data in order to get a statistically safer identity method.
6. Surprisingly (or not that much), my fork became faster, way faster than "Canon" on huge patch sets. 10 to 20%, as it was reported to me
   1. Interesting enough, weaker machines apparently harvester most benefits from it!
7. At last, but not by least, my fork works perfectly on any KSP version since 1.3.0 (and I publish a special package for people using 1.2.x), so people that still use older KSP versions (as I do) don't have to rely on older, buggier MM versions to play. My fork will always be available to any KSP >= 1.2.2, with all the bugfixes and enhancements - and without breaking existing patches.

The "Canon"'s maintainer refusing to publish MM on a mirror so people could download it from a reliable source when his site is down (what happens once a year more or less, being something on his side or being something happening somewhere else) ended up promoting my fork, because I have a mirror of the "Canon" distributions on my repo and pinpointed it to the users, that so ended up asking about it. Had the Canon maintainer published a official mirror for these emergencies and a lot of people would not even be aware of my fork! :D

And the rest is history.

The main reason I maintain my own fork of MM is because I got fed up with dealing with the Canon's maintainers, and decided to solve the problems myself. I know of a few people that decided to use my fork, but to every single one of them (as well I'm doing to you now), I explain that by using my fork you will probably lose support from most add'on authors. So always uninstall my fork and reinstall "Canon" and reproduce the problem before filing a bug report or ask for help (except, of course, to me - I actively support things no matter the Module Manager is in use).

(And if you ever find a situation where installing back the Canon Module Manager fixes something, by all means file a bug report here and I will fix it!)

[Lisias]

Found a discussion about the fallout from a user trying to reason with MM maintainers. At that time, I was already using my fork for almost a year, I think.

UbioWeldingLtd/UbioWeldContinued#47

[Shaggygoblin]

As a rule of thumb, if you don't know why use my fork is almost surely you should not use it. :)

I absolutely agree with you. As and end-user, generally, we should stick with tested and released options.
Being that I have a fair bit of 'dabbling' in .cfg's under my belt, it caused me to soft-lock when I saw MM and MM/L on the Dependencies of zer0kerbal/FieldTrainingLab.

I went to the forum and didn't see it on the same mod. Just appears on the GH page. As mentioned, I was leafing through comments-to-self and commits trying to piece together what set this fork apart from regular MM. I have been away from KSP for not quite a year... or maybe it has been a year... dang... Anyway, I was very interested in learning about this 'new' MM/L and it's potential applications/use-cases. Prototype or not.

[Shaggygoblin]

1. I recall the 'discussions' around the Ido>sarbian handoff...or at least shortly after... popcorn reading that was.

2. I recall a lot of 'discourse' around that ^^then^^.

3. (i,ii) Surprising to me, I actually understood most of that, given my meager understanding of how MM functions. Especially about it taking from cache and not properly checking it's entries against updated mods.

4. There were some framerate increasing and ram reducing mods that achieved similar results, enabling heavier mod-sets to run on potatoes, mine included (at the time). Reducing erroneous code, like registry cleaning, arguably can yield benefits. I am happy to read you achieved similar results with your fork.

5. Here is where you clarify to me a very important misconception I had. I initially thought this was an attempt to make a MM that would forward-compat. mods for older KSP versions to newer KSP. Enormous and unrealistic pipe dream, I know...lol. But alas, I still wish that were possible. There are still several mods I'd love to use with later KSP that stopped working almost entirely after .90. I've got the .90 install with all my own cfg's to make the mods(pre-.90ksp) work on .90, on a HDD in a lockbox...lol.

Cheers to you, sir! I will give your MM a good whirl around my SSD and if I run into any issues that are obviously MM related, I know where to come to report (yes, I include logs and, when appropriate, savefiles/screenshots in my reports).
I wish you well.

[Lisias]

@Shaggygoblin

As mentioned, I was leafing through comments-to-self and commits trying to piece together what set this fork apart from regular MM. I have been away from KSP for not quite a year... or maybe it has been a year... dang... Anyway, I was very interested in learning about this 'new' MM/L and it's potential applications/use-cases. Prototype or not.

zeroKerbal is using MM/L for a long time, as far as I know - and he found MM/L with ModuleManagerWatchDog (as I can't monitor MM from inside due KSP bugs on Reflection) way more stable than "Stock".

I'm inclined to agree with him, by obvious reasons. :D

However, I got my share of drama on Forum, so I usually recommend end-users to suffer, I mean stick with "Canon". I can't support the whole Scene by my own, so keeping MM/L outside the mainstream ends up being a safe measure for me. At least, until power-users enough would be using MM/L - and then we would be able to share a bit the support burden.

[Lisias]

5. Here is where you clarify to me a very important misconception I had. I initially thought this was an attempt to make a MM that would forward-compat. mods for older KSP versions to newer KSP. Enormous and unrealistic pipe dream, I know...lol. But alas, I still wish that were possible. There are still several mods I'd love to use with later KSP that stopped working almost entirely after .90. I've got the .90 install with all my own cfg's to make the mods(pre-.90ksp) work on .90, on a HDD in a lockbox...lol.

As a matter of fact, what you want will be accomplished by KSPe and my personal forks on my Unleashed hierarchy. :)

All the techniques I'm using on HLAirships, DOE and TweakScale (all of them working fine - or most - from KSP 1.3.1 to the latest) I had developed on that hierarchy. I managed to keep some DLLs working downto 1.2.2, see Impossible Innovations.

In time, I just adopted Kourageous Tourists and I'm not only supporting KSP 1.4 and 1.3 too, but I also support Real Chutes if you have it installed! ;)

I have some pretty old add'ons recompiled against the multi-version support of KSPe running from KSP 1.1 to KSP 1.12 - but with some bugs, being the reason I didn't published them yet.

If you are curious, give a peek on the Unleashed hierarchy - but keep in mind that that things are completely unofficial forks, some of them are still actively maintained on Forum. The reason for them is do keep them working on most KSP versions as possible, as as I have savegames scattered on many KSP versions. :)

[Shaggygoblin]

Good morning.
Will be checking out the Unleashed you mentioned, thank you.

For your consideration; possibly add this, or similar to the main page of this fork:

This fork is intended to bring functionality and performant improvements to ModuleManager.
Great success has been achieved toward these goals, and others not mentioned here.
Development for this fork is ongoing.
Please, DO NOT submit bug reports/issues to: ModuleManager - Public.
This is an EXPERIMENTAL/WIP version of ModuleManger - Public being developed in parallel, but separately from the Public version.
Necessarily, ModuleManager /L will receive no support from the maintainers of ModuleManger - Public
Please, DO submit bugs/issues to this fork: ModuleManager /L

Including something along those lines will go far to ease the "Hey, what is this and why" questions going forward.
Although, I get the sense you're a kindred spirit, and enjoy the periodic intercourse of 'Bringing up to speed on why MM/L is/needs-to-be a 'thing'.

I'm off to go consume some KSP-Unleashed action!
Again, I thank you for your efforts.

[Lisias]

For your consideration; possibly add this, or similar to the main page of this fork:

Humm.. Ok. I will do.

I'm off to go consume some KSP-Unleashed action! Again, I thank you for your efforts.

Don't try anything not updated this year - I got out of time to update them all since a major KSPe release that broke ABI - you would need to install an older release of KSPe to use them.

[Shaggygoblin]

That's a beautiful introduction.
I will indeed keep in mind the up-to-date-ness of the aforementioned.
Cheers!