Hi!

Currently, Contract Configurator is a hard dependency on KSP 1.12.2 due that pesky bug on KSP that borks everything when a DLL dependency is not met.

This just had bitten me on the issue TweakScale/TweakScale#210 on TweakScale.

I really don't know how to "fix" this from your side, other that declaring Contract Configurator a dependency too (currently it's only a suggestion on CKAN), or KSP Community Fixes (as it has a fix for this Assembly Loader bug that is peskying us right now).

But we also know that KSP Community Fixes may have issues on Forum due KSP's EULA, so I don't know what would be the best line of action for this problem.

Another option would be selective loading of DLLS, as I do on TweakScale (using KSPe), but this would require another dependency the same and some work on the code.

In a way or another, I think you need to find a solution before other Authors decide to recommend uninstalling ScrapYard to fix the problem (as was done with TweakScale in the past).

Thank you. Kindly read contributiing.md, code_of_conduct.md and styleguide.md.\n These are boilerplate.

@Lisias the most prudent course of action might be to just sever the CC part (for now)

Poke! Any traction on this? I just helped someone on the /r/ksp discord that hit this problem. I think fixing this is as simple as setting up the ckan metadata to treat ScrapYard and ScrapYard_ContractConfigurator as two separate mods.

@JonnyOThan It comes down to this:

• either remove CC support completely. This is because of changes Squad made to the game for 1.12.?
• make CC a dependency, at least on KSP 1.12.x

Guess it will be option B); with a note in the readme/manualInstallation files that it is only a dependency for ...

now that I have replaced my broken monitor (Craigslist for the win) I will be more inclined to work on code.

I don't think this issue is new to KSP 1.12 but I could be wrong about that.

Does ScrapYard work if you delete the ScrapYard_ContractConfigurator.dll and any associated patches? If so, then option C is to set up CKAN metadata so that you can install the two parts of the mod separately.

I don't think this issue is new to KSP 1.12 but I could be wrong about that.

see @Lisias above

Currently, Contract Configurator is a hard dependency on KSP 1.12.2 due that pesky bug on KSP that borks everything when a DLL dependency is not met.

You are welcome to try - but I really suspect no. I have already updated the Forum thread OP to state hard dependency for KSP 1.12.x - which if you think about it, isn't much of a deal, because you can just choose not to use CC.

I saw the comment, but that doesn't mean they're right.

We are right.

ReflectionTypeLoadExceptions have been breaking installs since 1.8 when the unity version was updated.

I have dozens of reports that were fixed by installing the depencency. KSP's Assembly Resolver is broken since 1.8.0, and things became way worse on KSP 1.12.x.

The out of date managed assemblies were a side effect of the problem, not the cause.

The usual culprit was out-of-date managed assemblies, but you get the same exception when missing hard dependencies.

And in both cases, since KSP 1.8 everything trying to use Reflection or trying to load a (satisfied) dependency after the first ReflectionTypeLoadException start to bork relentless until you fix that first ReflectionTypeLoadException.

It's important to note that somehow MechJeb is screwing the KSP.log - when it is installed, the first ReflectionTypeLoadException does not tell us anymore who is the one stepping on the mine - so I ask the users to temporarily remove MechJeb, then reproduce the problem, send me the KSP.log and after installing MechJeb back - otherwise diagnosing the problem is harder.

I saw the comment, but that doesn't mean they're right. ReflectionTypeLoadExceptions have been breaking installs since 1.8 when the unity version was updated. The usual culprit was out-of-date managed assemblies, but you get the same exception when missing hard dependencies.

We're talking past each other a bit here. @zer0Kerbal seemed to be under the impression that this was a new issue in 1.12. I don't think it is. I think you agree. Or are you trying to say that missing a hard dependency did NOT break the game prior to 1.12?

We're talking past each other a bit here. @zer0Kerbal seemed to be under the impression that this was a new issue in 1.12. I don't think it is. I think you agree. Or are you trying to say that missing a hard dependency did NOT break the game prior to 1.12?

Ah, now I see.

At the time I wrote the report, KSP 1.12.2 was the latest KSP, and the only one in which I had tested for it. I don't report bugs for KSP versions I didn't test for it, even when I know for sure it will be reproduced - now and then I'm wrong, and it's pretty embarrassing reporting a bug against something when it's not there.

My apologies for the confusion.

So, in an attempt to prevent my future self to fall into the same trap I let myself fell today :) :

• Since KSP 1.8.0, there's a Nasty Bug™ on the Assembly Resolver that once something fails to load a dependency, everything and the kitchen's sink will also bork the same later while loading a dependency (no matter is the dependency is good or not) - additionally, things using Recflection borks the same (don't have a clue why).
• At least for KSP 1.12.2 (the one I tested for it on that time), CC became a hard dependency for ScrapYard due that bug. Without the bug, that DLL would just fail to be loaded and everything else would just live their lives as usual.
• Logic says that downto KSP 1.8.0 ScrapYard would fail the same due the Assembly Resolver bug, but I didn't tested for it.

@Lisias @JonnyOThan

so the quick and dirty would be Option C - thing is that CKAN is very backlogged. We can release a CC free version on CurseForge; I would prefer to not have two listing for SYD on SpaceDock.

I am working right now on a fresh recompile/1.12.4 maintenance release and will do both versions for CurseForge.