Add inspector transpiler

[Nytra]

Closes #120

[Nytra]

It doesn't respect the Enabled state yet, wasn't sure how to do that

[Nytra]

It doesn't rely on counting the branches anymore

[Nytra]

It now respects the Enabled state

[Nytra]

I think this now 100% matches the behavior of the old patch

[Banane9]

Added some comments - I'd also prefer this to be an optional thing, at least for the start, I think. As in, have a toggle to use replacement instead of transpiler 🤔
Also let me know whether you think the history of the commits should be kept or whether it should be squashed

[Nytra]

Added some comments - I'd also prefer this to be an optional thing, at least for the start, I think. As in, have a toggle to use replacement instead of transpiler 🤔 Also let me know whether you think the history of the commits should be kept or whether it should be squashed

Would be a bit odd to have both a prefix and transpiler, is that even possible? Also I don't mind what happens to the commits. Probably fine to squash.

[Banane9]

Would be a bit odd to have both a prefix and transpiler, is that even possible?

well, a prefix would just skip the transpiled content of the method, so it would be possible to have both indeed. It's mainly that restoring the vanilla behavior becomes harder when a transpiler is involved. We could do patch / unpatch with enabled / disabled, but that's also kinda funky 😩

[Nytra]

The transpiler respects the Enabled state, so if its disabled, skip the prefix and then the original should run via the transpiler

then just have a toggle for if you want to use prefix replacement or transpiler

[Banane9]

The transpiler respects the Enabled state, so if its disabled, skip the prefix and then the original should run via the transpiler

What I'm thinking about is the transpiler breaking the method so it doesn't work anymore at all after an update - so disabling it would have to be an unpatch 🤔

[Nytra]

The solution to that would be to make the transpiler very robust so it is very unlikely to break after an update.. The same thing could happen to the prefix.

[Banane9]

The solution to that would be to make the transpiler very robust so it is very unlikely to break after an update.. The same thing could happen to the prefix.

Yea... though at least in my scenario, the prefix and transpiler break in different ways. The transpiler could break the method from working entirely (if not made properly), while the prefix just stays stuck on the old implementation, but doesn't "break" anything in that sense.

Of course that all goes out of the window when any of the referenced methods change so they're not found anymore.

[Nytra]

If the transpiler IL code is invalid it won't patch anyway.

Resolved