Removing empty HarmonyPatches from HugsLib log

[LecrisUT]

I am currently using a Harmony transpiler to search the body of all JobDrivers, in search for calls of StatDefOf so that I can substitute with my own when necessary. In order to keep the log clear of the pseudo-transpilers, I unpatch them out.

The problem is that the log is still flooded with empty patches: Here's an example.

Is there an alternative or HugsLib method of eliminating those?

[UnlimitedHugs]

Gotcha. I suppose I could switch the logger to skip methods with no patches- they don't carry much useful information in that form anyway. For reference, here's the method that produces the output.

[LecrisUT]

Hmm, seeing how it is made there is another improvement I had on my mind.

• Check if DeclaringType.IsNested (also DeclaringType.IsSealed?) and append until it returns false. This is useful for JobDrivers where the action is always in a nested class and it's hard to figure out where it comes from.

As for the unpatching, unless you can also get the assembly that unpatched it, there is not much useful information there. Do you have time to code that part up or shall I make a PR?

[UnlimitedHugs]

After some consideration, I'm not too eager about removing the empty method entries from the log. There is no information about who did the removing, but they're better than nothing.

Perhaps what you want could be done by reflecting into Harmony to get the list of instructions and cancelling the patch on the way in based on the results? That way you would also avoid the overhead of double-patching the methods. I'm sure Pardeike would add that as an API option if we were to ask.

I do like the nested method name resolution thing, however. I'm glad to take the help if you're offering. If you decide to go ahead with that, I recommend forking the dev branch- there is a big update coming up.

[LecrisUT]

The latter part should be easy to code, I'll write it up tomorrow. If you want I can implement a method where users can add a custom search and replace function to how they want to change how their patches are displayed, and remove them if deemed not necessary. I'll make tow separate PR with those features for you to judge ;)

[UnlimitedHugs]

Search and replace in published logs is an idea I have on my radar, but not right now. God knows the whole publisher needs a good rewrite.

If hiding patched method had to become a thing, I would rather have something like HarmonyUtility.RegisterIgnoredPatchedMethod, which would add methods to a set, and ignore them at publish time.

[LecrisUT]

The pull request is up if you want to check them. It is quite a simple implementation.

[LecrisUT]

I've tried to get Brainz opinion on the removing empty patches (pardeike/Harmony#292) with little progress

[UnlimitedHugs]

Well, then you're fully justified to use reflection to meet your needs. Otherwise, if you're feeling adventurous, you could use MethodBase.GetMethodBody to inspect the instructions manually. Otherwise, you could look through the Harmony source and borrow the parts that parse methods into instructions. Lots of options.

[LecrisUT]

Brainz has pushed an update that includes a proper Method IL at the transpiling stage. Problem with GetMethodBody was that it only gave the original IL instead of the transpiled ones. So my original problem for needing to remove empty patches is gone.

I'll try next week to see how well it goes.