Yarn: Future of yarn: Javadocs or parameters?

Created on 4 Sep 2019  ·  4Comments  ·  Source: FabricMC/yarn

In 19w36a, Mojang shipped obfuscation data reference in the client.json for its launcher. Many people believe that since this point, yarn may be obsolete.

However, there are still some points to consider about yarn:

  1. Javadocs
    We've planned about Javadocs for a long time. I wrote a pr to enigma but never bothered to update it (my bad!), but if we do get javadocs, we can be more clear about what mojang does (since mojang does a lot of weird stuff in code, like blit vs drawTextureRect)
  2. Parameters
    We have parameter mappings. Mojang's proguard data doesn't. Params are especially important when there are multiple int fields or if there is any boolean parameter.

Asie has said on discord that mojang released this proguard thing probably because of yarn's work. We cannot make sure that mojang won't withdraw this data one day; if that happens, the fabric community is wrecked.

As asie noted, yarn cannot use anything from Mojang proguard data. I believe this would make our purpose more firm, that we are to create accurate names for classes instead of mojang-like names.

Any other points to consider? I am waiting to hear.

discussion toolchain wip

Most helpful comment

Yarn was being created to have accurate mappings with an unrestrictive license so that the mappings can be used by anyone.

With the current license, this is not the case for Mojang mappings.
So at the current state, I say we keep updating yarn as before, without even looking at Mojang mappings, much like it is the case with MCP mappings.

If the license gets loosened or clarified, we should still keep it for param names and Javadoc.

All 4 comments

Yarn was being created to have accurate mappings with an unrestrictive license so that the mappings can be used by anyone.

With the current license, this is not the case for Mojang mappings.
So at the current state, I say we keep updating yarn as before, without even looking at Mojang mappings, much like it is the case with MCP mappings.

If the license gets loosened or clarified, we should still keep it for param names and Javadoc.

I'm in full agreement with Neun. The current license fulfills the exact opposite goal for which Yarn was created. Switching to it as is would be putting ourselves in a legal minefield even more dangerous than competing with MCP. If the license were in Mojang's name instead of Microsoft's, I might feel differently, but as is I can't see the benefits of switching outweighing the risks.

I think yarn should always stay uninfluenced by the Mojang mappings. If in the future, we get permission from Mojang to use the mappings in mods, then adding parameter mappings and javadocs should be done in a different project, not yarn.

Now we get both javadocs and parameters. We should be good :rocket:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

quat1024 picture quat1024  ·  3Comments

enbrain picture enbrain  ·  4Comments

Sollace picture Sollace  ·  5Comments

Awakened-Redstone picture Awakened-Redstone  ·  4Comments

copygirl picture copygirl  ·  6Comments