Unstrip Existing Methods

[ds5678]

Context

Though there are still some improvements to be made, unstripping has gotten quite good. Similarly, upcoming performance improvements, like #172, reduce the disparity between native execution and managed execution.

This opens the door to discussion about where we want the boundary between managed and native to be. Up until now, we've operated under the mentality that "everything that can be native should be native." We may want to change that.

Generic Methods

Unstripping generic methods that weren't actually stripped would enable modders to use generic instantiations that were not present at compile time.

All Methods

In theory, we could attempt to unstrip every method we have IL for. This would be more readable to modders in ILSpy and opens the door to the possibility of reenabling Transpiler use for Il2Cpp games.

If an existing method has been unstripped, we can patch the native implementation to call our managed implementation. From there transpiling works the same as it would for a Mono game.

Harmony Patching

There are two approaches to consider for Harmony patching if this is implemented:

• Patch both implementations separately.
  • This is safer. It ensures that unstripping bugs never affect the game directly.
• Only patch the managed implementation, but ensure that the native implementation calls the managed implementation.
  • This is required to support Il2Cpp transpilers.