Skip to content
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

Start creating intermediaries for non-obfuscated classes/methods/fields #15

Open
liach opened this issue Nov 15, 2019 · 4 comments
Open

Comments

@liach
Copy link

liach commented Nov 15, 2019

We have seen situations where mojang suddenly deobfuscates existing fields/methods, breaking our mod usage. This has defeated the intermediary names' purpose, i.e. to allow mods to work across versions more easily. Also, see #9; mojang has changed obfuscation status of classes as well, making such intermediary inclusion more necessary.

@modmuss50
Copy link
Member

Yes, I think this needs to be done. We might need a way to re-populate the obf names when yarn builds if it doesn’t have a replacement name for them.

@asiekierka
Copy link
Contributor

The problem is that Mojang and other developers may introduce libraries and software which expect these de-obfuscated names to exist. We need to handle that as well.

@sfPlayer1
Copy link
Contributor

I don't think there's any realistic use case where keeping the original deobf names is beneficial, everything but calling main will most certainly need to access obfuscated parts as well..

@liach
Copy link
Author

liach commented Mar 4, 2020

Now it becomes a bigger problem as seen in 20w10a where many realms classes have been moved away from deobfuscation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants