-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch from Yarn to Mojang mappings #4
Comments
cool |
Do Mojmaps have parameter names yet, or is that still only in Yarn? Also, Yarn has Javadoc info that Mojmaps will almost definitely never have. |
While not in the mappings themselves like Yarn does, there is a project called Parchment which is attempting to do just that. I don't know how it stacks up against Yarn; all I know is that it exists. |
Parchment is great, but the issue is it removes day-one availability. (Although, you can remove parchment at any time as it’s simply cosmetic to my knowledge.) |
I have a working version of Sodium in Mojang mappings, outside of a single alias in both MixinSpriteAnimation and MixinSpriteInterpolated which is failing due to the use of unmapped names as the required alias. any idea how we could get around this EDIT: I've found a kind of hacky way around this, which will be detailed in the PR. |
That would eliminate a lot of the point of moving. Also - yarn is normally updated within a few minutes of intermediary. You can't update your mods without intermediary, so there really isn't much time saved, if any, using mojmap |
I think the point is day one availability with usable names. |
I don't want to debate here, but yarn does have useable names on day one in most cases - it does update to snapshots after all |
The main point isn't day one availability in my opinion, but rather having usable rendering names. Currently, the rendering names for yarn are quite bad. |
While Yarn's names for existing things generally carry over once Intermediary has been updated, names for new things take time to come out. The speed at which names for new things are made is inversely proportional to their quality - the push to have same-day Yarn updates is very likely a big source of many of the low quality and blatantly incorrect names in the new rendering classes and methods added around 21w10a. Mojang mappings do not have this issue - we get decent passable names alongside every MC snapshot / release, and they don't change around a ton in the days after the snapshot comes out.
If true, this is a limitation of the Fabric toolchain that does not necessarily apply to other toolchains. |
It is true, however Intermediary doesn't need to be maintained, and only updated once for every version unlike Yarn. Almost all other toolchains have a required intermediary, be it srg or Fabric's. However, having a singular official mapping set removes the need for constant renaming. |
Parchment's javadoc works well as an optional thing - you can probably get away with not using them when updating to point releases of MC, but the additional context would be useful when upgrading to a major version. The only concern I have about switching to Mojang's mappings is that you lose the accountability - sure, some names are sub-optimal, but that can be fixed with a bug report or a PR. If we rely on Mojang's mappings there'll be no guarantee that they're actually fit for purpose. I'm not saying that Mojang will degrade the quality of the mappings they provide, but its something to keep in mind. |
@jellysquid3 Lithium still hasn't moved to Mojmap and yet this issue is closed as completed. Would you like to do something about it? |
Right now, all of Caffeine's mods are using Yarn for name mappings. This is largely because it was the de-facto option (well, really the only viable option) for Fabric mods when Lithium and Phosphor were first published.
Since then, Mojang have released their own (official) mappings, and these have seen ever increasing adoption in the modding community. Notably, the Forge project is using them as their primary mappings since Minecraft 1.16.5+, and Quilt is considering them for default use (or at the very least will probably support them.)
There's also a few other notable benefits that come with switching to Mojang's mappings. Most of what's written here is taken more-or-less from Coderbot's write-up here, with some emphasis of my own added.
Consistency and stability. While this is not intended to be a mark against the Yarn maintainers, the Yarn project is still a moving machine, and unfortunately much of what currently exists for Minecraft's rendering code is pretty poor. Mojang's mappings, while not particularly high-quality themselves, are relatively more stable and better documenting of render code.
Day-one availability. Creating names in Yarn involves human beings de-obfuscating a new release of Minecraft. This takes time, and doubly so to produce high quality names. With Mojang's mappings, there's immediate availability with the release of a new version of Minecraft.
We're not tied to any specific toolchain. While Loom (for Fabric modding) can be configured to use a variety of mappings, the only platform which really supports Yarn is Fabric itself. Using Mojang's official mappings means wider support and easier porting to other platforms.
However, this is not to say that Mojang's mappings are all good. There are some downsides and legitimate criticisms. I'll try to address some of the arguments that people have brought up to me.
Mojang's mappings have a non-free license. Yes. The Mojang mappings are not distributed under a libre license like Yarn is. However, the general consensus is that they are safe for use in open-source projects and pose no risk. Even in the case of ambiguity, I think it's fairly clear that Mojang's intention with these mappings is to enable modders, rather than to use it as a weapon against us. In the event that Mojang does decide to revoke that good faith and start weaponizing it against us, well -- I wouldn't want to continue modding their game, anyways.
Won't contributors to Yarn and Fabric no longer be able to contribute to Caffeine's mods? I don't really want to dig into this argument too much. The clean-room argument for Yarn doesn't really hold up in my opinion, and I don't think you could reasonably assert either for or against that the policy has been enforced, or that the project hasn't already been poisoned or otherwise compromised. For as toxic as some people paint the MCP/Mojang mappings to be, you would expect that the LGPL license of our mods would be just as much of an issue. Ultimately, the venn diagram between Yarn contributors and Caffeine contributors has had very minimal overlap, if any.
Why not contribute to Yarn instead? This argument gets brought up a lot in the open-source space, and while it sometimes makes sense, this isn't one of those times. When the discussion is about switching software stacks, the counter argument should not be "well if you have issues with our software, you should fix it yourself." I'd like to spend my time on writing mods, not on tooling and mappings.
With all that said, there's a pretty clear case for us to move away from Yarn and to Mojang's mappings. However, doing this is not exactly straightforward, and a lot of somewhat tedious work is involved in migrating. As such, this issue exists as a call to help for those who are interested in helping us switch mapping sets in each of our projects. Right now, this call includes Hydrogen, Lithium, Phosphor, and Sodium.
If you are interested in helping and have time to contribute, feel free to let us know in this issue or on Discord. Alternatively, one can also just open a work-in-progress PR for a given project and let us know that way.
The text was updated successfully, but these errors were encountered: