Major refactor and code clean, as well as introducing Official Mappings and obf->mapped support. - #48
Major refactor and code clean, as well as introducing Official Mappings and obf->mapped support.#48LexManos wants to merge 9 commits into
Conversation
Update libraries Remove guava, apache, and trove dependencies, they were just simple macro helpers, that are no longer needed with J8+ and added 6MB to the fatjar.
Added downloading of MCP/MCPConfig.
…mcpbot export, until MCPBot is updated to properly index on maven.
Download Minecraft client/server jar Add inheritance calculation and mapping to allow for OBF->MCP renaming. Use ASM's ClassRemapper adapter as it is more robust then homebrewing it.
|
Alright, so added full SRG remapping. |
|
Does that change the way srg->mcp is done? This may actually break one of the major use cases I have for BON2. Remapping mods that use mixin from srg to mcp relied on the simpler way of remapping. Mixin classes generally can contain methods with SRG names that (currently) need to be remapped for mixin to work (I think it is considered a mixin bug bit it's not fixed yet), but if inheritance is taken into account, they won't be remapped, because the mixin class isn't the class that normally contains the srg name (and this is also why runtime remapping in 1.12.x doesn't handle it) |
|
It does srg->mcp after obf -> srg |
|
would love to see mappings for ever older versions |
|
Official mappings are only avalible for versions Mojang releases. As for this PR in general, no idea if it'll ever be uptaken, but feel free to clone my fork and build yourself. |
Parker8283
left a comment
There was a problem hiding this comment.
I'm honestly surprised that this project still has a userbase. Thanks Lex for the changes! Hope that tterrag looks at it soon, would be cool to see this upstreamed.
|
I just tested this and ran into 2 issues
With the original jar containing the SRG mapping DIRECTION_CODEC = IStringSerializable.createEnumCodec((Supplier)Direction::values, (Function)Direction::func_176739_a);MCPBot reports
After fixing the version manifest, I did another test with a few McJtyMods which seemed to load fine in my workspace. Also, now that Forge is using official mappings, are there tsrg's available for remapping SRG to Official? |
As for SRG->Official.. No thats not how this works. Forge is not 'using official' It's still using SRG names for runtime/devetime. It just uses official as if it were a MCPBot export. Which is what this does: LexManos@4bcf352#diff-fc439e3caafda604b0e6d265439166b2fd1c147e6ba71b1bec90cd2c43d5e9c9R96 |
|
The command line options do not work, there is no way to specify official mappings. |
|
Nothing, mcpbot is dead, if someone wants to spend the time updating my fork we could probably publish it. But this PR doesn't seem like this will ever be merged. Next time I need this tool gain, i'll fix my fork. But who knows when that'll be. |
|
I compiled it myself and it cannot procces the mappings for newer versions, stating: |
So, this is a fairly big rewrite/refactor.
Updated gradle
Updated dependencies
Removed a bunch of unneeded deps (trove, guava, apache) saves 6MB in the fat jar.
Updated to maven publish plugin for gradle.
Added sources jar to published artifacts
Added 'Minecraft' dropdown and download buttons to the main menu, this will download MCP/MCPConfig so we have access to the SRG files.
Massive amounts of deadcode cleanup/removal. Data Objects now have a central static management class {MappingsVersions/MinecraftVersions/MCPVersions}
Allow downloading of everything above for both CLI and in GUI.
Anyways, I started poking this because I wanted to convert some notch named jars to MCP mappings.
But turns out this project doesnt do that. It ONLY does SRG->MCP names in a very basic way...
Perhaps someone who cares could come along and expand the actual remapping to be intelegent and do full SRG remappings.