Add support for custom debugging builds.

[R-T-B]

This simply adds support for custom dll builds where possible, mostly by using prefixes or fixed transpilers. It uses a basic size heureustic that is pretty reliable to detect custom dlls of Assembly-CSharp.

This is mostly useful for debugging, and is expected to be best effort, not a truly supported thing, but I expect it would be welcomed by some.

[R-T-B]

Should be ready now, there were some slight transpiler logic errors on MSVC built dlls but I fixed them.

[R-T-B]

converting to draft pending more testing.

[Phantomical]

I will probably have more comments but I need to do my taxes so I'm posting these for now.

[R-T-B]

So, I think it's ready now. But welcome any further comments.

The worst part is probably how it uses file size to ID stock dlls, but, well, it certainly won't ever do the wrong codepath on a stock user, and the support for modded dlls is explicitly understood to be best effort, so...

[R-T-B]

That should be it for tweaks, I have made a test build here and will be asking custom deobfuscated dll / debugging build users to play with it and see what happens.

https://github.com/R-T-B/KSPCommunityFixes/releases/tag/1.40.1_RTBFORKr2

[Phantomical]

Two more small comments. I'm also not quite happy with the ModuleIndexingMismatch one, so I'm going to take a shot at rewriting some of it to work appropriately.

[Phantomical]

Alright, check your PRs for simplifications to the two patches that still use the conditional.

[R-T-B]

Alright, check your PRs for simplifications to the two patches that still use the conditional.

done and merged, thank you.

I'll test later today with my release build from MSVC just to be sure it works properly.

[R-T-B]

The ModuleIndexingMismatch change fails with MSVC builds, at least. I suspect it probably works fine with mono builds, since that is what you tested against.

I'll try to supply you with an example dll soon of that style for comparison. The changes are usually pretty minor.

Everything else seems good.

[R-T-B]

FYI I am now on the fence about the utility of this...

The whole point of a debugging build is predictability for debugging right? Whats the utility in using lightly tested fragile patches in such an environment, honestly, when you can just disable patches?

It just kind of hit me like that. Feel free to head check my thought process here, it was fun regardless lol.

[Phantomical]

This is part of why I have been pushing for patches that are the same in both environments (well that and maintenance burden).

IMO the patches are useful if they work. Unfortunately, since you are the one with the weird environment the work to make sure that they actually work in that environment falls on you.

[R-T-B]

The irony is I'm actually not the one with the weird environment, it's siimav I just got told how to replicate the process heh. I do like to support him because he does great work but I need to make sure our support work is ALSO both useful and reliable.

I guess we can merge this if it does not bother you but it just seems so fragile without a real dedicated tester ( I won't honestly be doing that beyond these spot tests).