Closed Mremenar closed 4 years ago
tbh this project's topic is different.
This project focuses on automatically reversible obfuscation. Obfuscation which changes the name of fields, methods and classes cannot be automatically reverted without manual mapping (because the data gets replaced). Forge uses a handcrafted dictionary to get back to meaningful names.
The fields which are not manually mapped will be named in a generic way like you noticed. You could search and set up your own forge workspace so you can use eclipse to better find out the meaning of certain variables and/or methods.
An alternative way to seek for help would be to use the forge forums and/or asking both mod developers to fix their incompatibility.
An example for obfuscation would be string encryption. Tools (mostly paid) exist around the internet to replace string constants with calls to methods which calculate that constant string in various different ways. For that reason, this java-deobfuscator contains anisolated bytecode interpreter to safely emulate and execute parts of a possibly dangerous jar.
Umm. Okay. Both the mods have been abandoned by their authors. The author of Dragon Mounts holds hostility against the author of Orespawn (and has verbally stated his refusal to cooperate), claiming inferior coding (static vs dynamic IDs) is the reason for the incompatibility. I've proven that theory incorrect by recoding the Orespawn Constants class to use dynamic numbering, and successfully recompiling the Orespawn mod and running it with Dragon Mounts and still having DM fail. The failing has to do with the process of rendering the entities in Dragon Mounts. The renderer fails but the entity is still there, but invisible. I can't figure out the soup of variable-field-names Dragon Mounts uses. And the author isn't going to be friendly to someone who points out the hole in his position. If I could figure out which class/how the class for rendering is being accessed, I think I could replace it with something functional that wouldn't conflict with Orespawn. Or so I tell myself. :-\ If I heard you correctly, you are saying the deobfuscator won't help in further clarifying the coding?
Do you by chance have any pointers for dealing with entity renderers?
I have no experience with those topics :/
Thank you for taking the time to talk with me. Many blessing to you and Merry Christmas.
Hi. First I'd like to say "thank you" for sharing this work of yours. :-) Second, I apologize for any noob-ness on my part. I am new to software development. Third, I followed your instructions (even the detect.yml file) and received the error message "Failed to load Main-Class manifest attribute from Dragon1.jar."
I decompiled the troubled jar file using Procyon, which worked wonderfully, but has some fields listed in it that I don't understand: this.mc.field_71460_t; func_151463_i; etc.
I'm hopeful you and this deobfuscator software can help me make heads or tales of it. The issue I'm trying to solve is that this is a Minecraft mod and the dragons become invisible when the mod Orespawn is loaded with it in Minecraft. My son REEEEEEALLY wants to play them together.
The author thinks it's the use of static IDs, but I recompiled Orespawn after changing it to dynamic IDs format per his rant and couldn't keep the dragons from disappearing, even with dynamic ID allocation (the Forge method).
I have a suspicion as to what the problem is, i think it's tied in with the rendering issue that plagued Mojang for a while (https://bugs.mojang.com/browse/MC-65040?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&showAll=true), but the rendering/invisible issue I'm trying to solve only occurs when Orespawn and DragonMounts are loaded together.
The locus of my help request is the error message "Failed to load Main-Class manifest attribute from Dragon1.jar." But any additional help, pointers or expression of your knowledge and prowess will be warmly and gratefully received.
Thank you in advance for reviewing my issue. Marc
Dragon-Mounts-Decompiled.zip