Parchment
Parchment copied to clipboard
migrate to quilt enigma
gaming
the stats stuff isn't particularly useful as of the latest version, it throws up on quite a few parchment classes. I'm going to work on improving that
stat issues tracked by https://github.com/QuiltMC/enigma/issues/184. from a little bit of poking around, that's the only major bug affecting parchment
It might be advantageous to keep Fabric's one around as an option, in case unintended issues arise. Kinda like Loom, which provides both genSourcesWithCfr and genSourcesWithVineflower, with the standard genSources defaulting to one of the aforementioned ones.
that's not really an option if the parchment project begins using a plugin for automatic mapping
Can somebody explain to me why this pr was made?
The pr description is really bad: "gaming"?!? What has gaming to do with this? Also what is up with the stats?
Second of al, if this is a fork of fabrics enigma then what indicates zo us that the quilt variant will stay with upstream / is better then fabrics?
It's no secret that Fabric's Enigma has been falling behind in features lately, Quilt's fork has added quite a few quality of life improvements (more powerful plugin system, UI indicators for mapping progress, fixing of the hosted server etc). Although I'd argue that most of these aren't relevant for Parchment, except maybe for the Vineflower integration. Which Fabric is only missing because the required API hasn't been released yet, and we don't want to depend on unstable snapshot versions.
So while Fabric's fork has been stale for quite a while now, Quilt's changes don't provide much benefit for Parchment (at least as of now), and I too am currently working on a large internal refactor for Fabric's Enigma, aiming to improve stability and extensibility in the long run. That's why I proposed to keep both options for now, as long as you don't start developing custom Enigma plugins, there shouldn't be any drawbacks
It's no secret that Fabric's Enigma has been falling behind in features lately, Quilt's fork has added quite a few quality of life improvements (more powerful plugin system, UI indicators for mapping progress, fixing of the hosted server etc). Although I'd argue that most of these aren't relevant for Parchment, except maybe for the Vineflower integration. Which Fabric is only missing because the required API hasn't been released yet, and we don't want to depend on unstable snapshot versions.
So while Fabric's fork has been stale for quite a while now, Quilt's changes don't provide much benefit for Parchment (at least as of now), and I too am currently working on a large internal refactor for Fabric's Enigma, aiming to improve stability and extensibility in the long run. That's why I proposed to keep both options for now, as long as you don't start developing custom Enigma plugins, there shouldn't be any drawbacks
So are you a maintainer of Fabrics Enigma, or Quilts?
I'm working on Fabric's one, since Quilt's fork had horrible performance regressions in the past which made it unusable for my personal deobfuscation project. Afaik there has been work on resolving these, though I haven't conducted any new tests in the last few months
@ix0rai Could you provide me with a list of advantages of the Quilt Enigma version vs the Fabric one. Also what are its disadvantages?
I didn't include a big description, because when I made this PR I thought the decision was already made based on my conversations with the maintainers, specifically @sciwhiz12. Either way, here are some key features for parchment:
- as mentioned, the added Vineflower decompiler produces what is IMO leagues better output than anything else
- our docker system allows you to reorganise and hide tabs such as the class tree, the implementations view, and others, to make more room for your code or display more information
- the statistic icons in the class tree provide an immediate view of what requires mapping, and what is complete
- a much improved API for plugins, including better documentation, a reworked name proposal system, and an api/impl split for enigma code to ensure we can follow semver (I've discussed doing some plugin stuff with sciwhiz as well)
- more convenience actions, like support for renaming an entire package in one go
- tons of little improvements and bugfixes, like the better notification system, improved multiplayer support, support for searching methods, fields, and classes all at the same time, a pinned navigator to help you find obf things in a certain class, etc etc
screenshot (I tried to pack as many new features as I could in here):
cc @marchermans
I didn't include a big description, because when I made this PR I thought the decision was already made based on my conversations with the maintainers, specifically @sciwhiz12. Either way, here are some key features for parchment:
* as mentioned, the added Vineflower decompiler produces what is IMO leagues better output than anything else * our docker system allows you to reorganise and hide tabs such as the class tree, the implementations view, and others, to make more room for your code or display more information * the statistic icons in the class tree provide an immediate view of what requires mapping, and what is complete * a much improved API for plugins, including better documentation, a reworked name proposal system, and an api/impl split for enigma code to ensure we can follow semver (I've discussed doing some plugin stuff with sciwhiz as well) * more convenience actions, like support for renaming an entire package in one go * tons of little improvements and bugfixes, like the better notification system, improved multiplayer support, support for searching methods, fields, and classes all at the same time, a pinned navigator to help you find obf things in a certain class, etc etcscreenshot (I tried to pack as many new features as I could in here):
Okey but what are the downsides to using your version?
as far as I'm aware, there shouldn't be any. I watch the fabric repo and, with permission, pull in their changes when possible.
if you do find downsides (please, test this PR instead of discussing theory with me!) I'm happy to fix them for you. having input from the parchment team is important in order to make enigma better!
I'm working on Fabric's one, since Quilt's fork had horrible performance regressions in the past which made it unusable for my personal deobfuscation project. Afaik there has been work on resolving these, though I haven't conducted any new tests in the last few months
@NebelNidas missed the mention of performance regressions -- this was an issue in I think 1.6 when it released due to statistics being calculated on the main thread, it's since been fixed. I don't know of any other major regressions, I'd really appreciate some profiling data if you test and find that there are still issues!
I just did a quick re-test, and while there may have been some improvements, your fork is still taking almost twenty times longer to index than Fabric's one (1min 10s for Fabric Enigma v2.4.2 vs. 21min 40s for Quilt Enigma v2.2.1). And after having waited for 22 minutes, all I got was a blank window (Swing probably crashed, idk).
this was an issue in I think 1.6
My report from last April mentions that 1.6 had performance regressions in the realm of around 100% longer indexing times, but the more problematic update was actually 1.7, which upped this number to at least 1000%. I have to say I'm not too keen on profiling this issue myself (given that I'm fairly invested in Fabric's fork), but if you wish to reproduce my results, this is the project I used. /gradlew enigma runs the Fabric version, ./gradlew enigmaQuilt the Quilt one.
interesting. I'll take a look
update: these performance regressions are purely issues with our swing gui (in fact, quilt enigma is a bit faster with indexing). fixes are being worked on!
Okey for now I will make this a draft.
why?
