Open aldelaro5 opened 1 year ago
So what is the feature exactly?
So what is the feature exactly?
I am referring to this ini option: https://github.com/NeighTools/UnityDoorstop/blob/eab4428a0ad8b3e6e55730c3b08fecea1a601b9a/assets/windows/doorstop_config.ini#L29
What this will do is it will start a mono debugging server bound at the address and port you set it to. It's similar to what happens when you have a unity game's dev build where it starts a debugging server you can connect with an IDE, but you don't need to have a dev build.
I need this to debug the game because dnspyex doesn't work well (it crumbles with very large methods and is in general limited such as working on windows only). This way, I can decompile the code with ILSpy, recompile them with a dll and a pdb and then start a server that way to debug the code as a unity dev would be able to do (every tools the IDE provide works like the evaluator and stuff).
I suggest you check the doorstop 4's repo and docs to learn more, but that's the gist of it: you can have an alternative way to debug the game or mods that doesn't involve dnspyex.
Describe the new feature or enhancement
I currently use bepInEx 6 (with my own change to support doorstop 4) and I was looking at melon as an alternative to this, but I found this feature I was using wasn't in melon and when asked about it in the discord, there was interest to open an issue about it so here I am. I'll describe my concrete setup so everyone can understand why it's such a useful feature to have.
I have a lot of plans to bring modding tools and libraries to mod Bug Fables, a mono game in unity 2018.4.12f1. It uses the older then deprecated mono runtime, but I found an easy way to upgrade it without breaking anything. My goal at first is to inspect the code in details so I can document its internals in technical details so I can build off this info later. This requires a bit of debugging to understand more complex stuff so naturally, I checked what everyone recommended at first, dnspy/dnspyEX.
However, I found this tool is not suitable for this. For developmental reasons (mostly not being aware this can become an issue), there are very large MonoBehaviors in this game (at least 3 are big enough to be a problem while they are a core part of the game) and one method is INSANELY long (about 30k lines after decompilation) which happens to be very essential to analyse. Due to this, dnspyEX can literally take MINUTES to decompile while debugging the code and nothing is cached so this has to be done every debugging session (which wasn't found to be very stable, the connexion could just drop). This is on top of ILSpy's version being too old while I get very decent decomp with recent ones so really, dnspyEX is just not the good tool to use here.
But it turns out I am able to decompile the entire code with ILSpy such that it's VERY close to be able to recompile it (there's only 2 issues where ILSpy failed to inline stuff, but it's very easy to fix). So what i effectively was able to do is to recompile the Assembly-CSharp.dll, overwrite the vanilla one and the game was still working. Since I have the code, I can make pdb from it and debug it.
The problem is that it's not as simple as attaching to the EXE because the exe is the unity player which works differently. What you actually need is to turn the game build into a dev build which autostarts a Unity debug server that your IDE can connect to. However, doing this is very annoying: it involves picking a lot of files from an actual unity install and overwriting them on top of the fact this can be checked at runtime which means doing this can have side effects so you're changing the behavior of the game.
It turns out doorstop 4 has a feature where you no longer need to do this: you simply configure it so it will start the server on its own. This is supported since doorstop 4 at least for mono games, but you can learn more here: https://github.com/NeighTools/UnityDoorstop#debugging-in-unitymono To note, it seems to only work with newer mono (.net standard 2, not .net 2), but it worked after I figured out how to upgrade the runtime on the game.
The neat thing is because it starts a server, it allows for remote debugging: I could have the game running on my steam deck, but debug on my desktop pc.
This issue is to ask if it could be possible to implement this in melon. Since melon doesn't use Doorstop, it seems that it would need to be implemented in melon's entrypoint directly so hence why I submit this.