ksp-modularmanagement / modulemanagerwatchdog Goto Github PK

Hi me again :P.
So i have updated watchdog and kspe and noticed now that the ModuleManager.dll file in

C:\Kerbal Space Program\GameData\ModuleManager\PluginData

is being deleted upon starting KSP so is the dll files in

C:\Kerbal Space Program\GameData\ModuleManagerWatchDog\Plugins\PluginData

this never happened before I think is this expected now can?
I still have the ModuleManager.dll in

C:\Kerbal Space Program\GameData

Thanks

TODO

Using MMWD as a Deployment Tool for MM looked as a good idea once, but on the field if revealed itself almost catastrophic.

See KSP-ModularManagement/KSPe#72 for a more comprehensive discussion.

So this task will remove all deployment code from the MMWD, that will rely on the Deployment Tool from KSPe from now. Such code will now be handled by KSPe's Deployment Tool.

The main client for this stunt is CurseForge anyway, that now have the Modular Management suite making things simpler - and Forum slandered MMWD to a point that it's losing its usefulness on CKAN so, frankly, I will let them hang themselves. I can't save people from themselves, I just got burnt by trying.

That's the deal: old and deprecated MM are scattered on the scene, playing havoc with KSP installations when the user inadvertently install it on the rig.

So MMWD checks for rogue old copies of MM and remove them when found. It keeps record of the user's preference for my /L or Forum when in doubt.

Problem: if the user removes /L and replaces it with Forum's, MMWD after checking for the user's preference and being it /L will gladly remove Forum's anyway, rendering the rig unusable.

Solution: MMWD should not remove the "rogue" MM if it is the only one available at the time.

JESUS FSCKING CHIRST! AGAIN!!

[EXC 08:06:51.247] TypeLoadException: Could not resolve type with token 0100001b (from typeref, class/assembly ModuleManagerWatchDog.SanityLib, ModuleManagerWatchDog, Version
=0.1.0.0, Culture=neutral, PublicKeyToken=null)
        UnityEngine.DebugLogHandler:LogException(Exception, Object)
        ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
        UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
[EXC 08:06:51.248] TypeLoadException: Could not resolve type with token 0100001a (from typeref, class/assembly ModuleManagerWatchDog.SanityLib, ModuleManagerWatchDog, Version
=0.1.0.0, Culture=neutral, PublicKeyToken=null)
        UnityEngine.DebugLogHandler:LogException(Exception, Object)
        ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
        UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Somehow, an old mishap on my toolchain struck again! The latest release from TweakScale and KSP-Recall have botched 666_ModuleManagerWatchDog.dll (facepalm)

I just recompiled the very same DLL I distributed on TweakScale and KSP-Recall and it's working.

Apparently, something bad on my toolchain was resurrected when I recovered my development rig after the huge screwup from Apple ruined my life.

Oh, well…. Here we go again.

Fellow Kerbonaut Lucky21 was bitten by a minor installation problem that escalated pretty badly!

Having multiple ModuleManagers in different directories apparently is fooling KSP into loading and executing them all. At least, is the only explanation I have for the diagnosis of his problem ai made here.

I think the MM Watch Dog needs to handle this situation again, KSP 1.12.3 didn't really fixed the problem after all.

Tasks:

• Code a Option Dialog Box (customizable)
• Write back end support for the selection
• Write a nice web page with instructions if the user asks for it.

Dialog Prototype:

Following suit with KSP-ModularManagement/KSPe#65 , do the same on Module Manager /L, i.e.:

• Detect if the host directory was removed;
• If positive, remove both Module Manager /L and the 666_ModuleManagerWatchDog.dll from user's GameData.
  • Don't touch Forum Module Manager if existent.

With CKAN pushing (Forum)Module Manager aggressively even when it is not needed (as in this example, where the author told me explicitly it's a parts only add'on with optional patches, so MM would be optional), chances are that MM/L users will be constantly annoyed with the need to manually remove the offending fork.

However, it's perfectly possible to automate such fix once MMWD knows for sure what would be the user's preference.

So this enhancement should:

• On the first KSP boot up without problems, detect what is the ModuleManager in use and remember it.
• Every time more than one fork is detected, automatically remove the offending forks using the setting detected by the previous step.
• When no previous detection is remembered, shows the usual Show Stopper Dialog and ask the user to fix manually the rig.
  • On the next sane boot up, the setting will be persisted and from that point the tool will be able to automatically fix the rig.

The user's preferences may be reset by deleting the file <KSP_ROOT>/PluginData/ModuleManagerWatchDog.cfg and starting KSP.

The tool should:

• Be standalone, so it will be run even if 666_ModuleManagerWatchDog.dll is absent
• Will check for the presence of 666_ModuleManagerWatchDog.dll and install it from our PluginData if absent, or will update it if older.
  • Remove the original when the job is done. Be failure resilient (it may run from a R/O filesystem or something)
• Will check for the presence of 999_Scale_Redist.dll and install it from TS' PluginData if absent, or will update it if older.
  • Remove the original when the job is done. Be failure resilient (it may run from a R/O filesystem or something)

Should do nothing if the original files does not exist (saving a bit of I/O on the process).

see the following issues for the reason:

• TweakScale/TweakScale#254
• TweakScale/TweakScale#255

Today installed as update KSP Recall and suddendly we had a problem on loading, telling me that interstellar_redist.dll is missing. going back to 2.0.5 fixed it for me for now, but maybe this is a mishap in packaging or setup?