(De)Obfuscation problems

[Reika]

I am trying to port my mods from 1.6.4 to 1.7.10 and have run into a very serious problem: Large swaths of the code are still functionally or even completely obfuscated.

The really high-traffic functions have their names set, but their arguments are still things like "p_345983459", and most of the code is still field_this and func_that.

 

I cannot possibly develop when so many of the functions I rely on are unnamed and hidden in a mass of 300+ obfuscated names, and the fact that I can no longer modify the vanilla code to check references and effects of various parameters means I cannot work it out on my own like I used to.

 

I have tried updating to the newest version of Forge, which did not help; is there some way I can get some level of functionality like that which I had in 1.6?

 

EDIT:

I just realized that I accidentally posted this in the wrong section. Can a moderator please move it to the correct location?

http://www.minecraftforge.net/forum/index.php/board,73.0.html

[LexManos]

I am trying to port my mods from 1.6.4 to 1.7.10 and have run into a very serious problem: Large swaths of the code are still functionally or even completely obfuscated.

The really high-traffic functions have their names set, but their arguments are still things like "p_345983459", and most of the code is still field_this and func_that.

1) Those are not obfuscated names those are unique SRG names

2) The 'modder friendly' names are supplied by the community to get to work.

I cannot possibly develop when so many of the functions I rely on are unnamed and hidden in a mass of 300+ obfuscated names, and the fact that I can no longer modify the vanilla code to check references and effects of various parameters means I cannot work it out on my own like I used to.

Welcome to minecraft modding, this is just a thing of life. As for not being able to read the source, it is there, you can read it, you just cant MODIFY it. And you can EASILY find references of anything. So, learn to your use IDE better I guess.

I have tried updating to the newest version of Forge, which did not help; is there some way I can get some level of functionality like that which I had in 1.6?

We have superior functionality to 1.6, All of the things that were named in 1.6 are still named in 1.7, the things that are GONE are GONE not renamed or anything stupid like that.

EDIT:

I just realized that I accidentally posted this in the wrong section. Can a moderator please move it to the correct location?

http://www.minecraftforge.net/forum/index.php/board,73.0.html

*notes renforcment of lack of attention to detail.*

[Reika]

I am trying to port my mods from 1.6.4 to 1.7.10 and have run into a very serious problem: Large swaths of the code are still functionally or even completely obfuscated.

The really high-traffic functions have their names set, but their arguments are still things like "p_345983459", and most of the code is still field_this and func_that.

1) Those are not obfuscated names those are unique SRG names

Fair enough; I misused a term.

 

2) The 'modder friendly' names are supplied by the community to get to work.

I realize that, but in past updates, the new names arrived fairly quickly, often within weeks of the update. Forge for 1.7 has been out for months, and the fact that 75% of the code is still unreadable seems very odd to me. I was suspecting that something had gone wrong with the installation.

 

I cannot possibly develop when so many of the functions I rely on are unnamed and hidden in a mass of 300+ obfuscated names, and the fact that I can no longer modify the vanilla code to check references and effects of various parameters means I cannot work it out on my own like I used to.

Welcome to minecraft modding, this is just a thing of life. As for not being able to read the source, it is there, you can read it, you just cant MODIFY it. And you can EASILY find references of anything. So, learn to your use IDE better I guess.

Half of the way I reverse-engineer this sort of code is by forcing various parameters and testing their effects. This is no longer possible in this version, hence my point.

Also, you say "Welcome to modding", but as far as I have experienced, unless you are one of the first mods to update, it is a rather rare occurrence; as mentioned above, I have never before seen this much code still scrambled this late into a version's life, and I have been modding since before the fiasco that was 1.3.

 

I have tried updating to the newest version of Forge, which did not help; is there some way I can get some level of functionality like that which I had in 1.6?

We have superior functionality to 1.6, All of the things that were named in 1.6 are still named in 1.7, the things that are GONE are GONE not renamed or anything stupid like that.

I am not talking about code, but was again wondering if there was some other repository of updated names and/or a way to edit the source in the dev environment. I understand your disapproval of the latter when used to make mods, but if only done in the developer environment for the sake of debugging, that is not an issue.

 

EDIT:

I just realized that I accidentally posted this in the wrong section. Can a moderator please move it to the correct location?

http://www.minecraftforge.net/forum/index.php/board,73.0.html

*notes renforcment of lack of attention to detail.*

More like having two adjacent tabs and posting in the wrong one. Simple mistakes are easy to make.

 

 

If it comes down to it, I may well try hybridizing the MCP and Forge environments, so that I can at least get editable source, allowing me to debug as I see fit. It may well not work, but in lieu of a better approach...

[jabelar]

Many of the methods are the same, but just using the SRG names again.  So you can often compare the 1.6.4 source with the 1.7.10 to guess what the equivalent functions are.  Based on the argument set and the rest of the code (which should be easy to see if it is equivalent) you should have fairly high confidence in figuring them out.

 

I have also run into situations where I had to get into the code that was less readable, but for me it is rare even on 1.7.10.  I guess I'm just digging around in more common areas of modding...

[Reika]

Many of the methods are the same, but just using the SRG names again.  So you can often compare the 1.6.4 source with the 1.7.10 to guess what the equivalent functions are.  Based on the argument set and the rest of the code (which should be easy to see if it is equivalent) you should have fairly high confidence in figuring them out.

Normally, yes, but the problem here is that there are, depending on the class, dozens or hundreds of methods with SRG names that are not readily distinguishable. A line-by-line search could probably do it, but that is so time-consuming and inefficient it would be better just to wait until more code is given proper names. The problem is compounded by the naming of all the arguments as p_*, because that makes everything "look" the same as each other and unlike their 1.6 counterparts, and greatly stifles at-a-glance comparisons.

 

 

I have also run into situations where I had to get into the code that was less readable, but for me it is rare even on 1.7.10.  I guess I'm just digging around in more common areas of modding...

I have had to do it too, but it was always "backwater" code like obscure parts of the render engine or chunk provider stuff. Now it is in what I call frontline code; furnace recipes, common world operations (markBlockForRenderUpdate being the most recently discovered example), various entity methods and fields...

Some, like EntityFallingBlock, have literally every field as an SRG name. Other classes do the same with their methods.

 

This is actually another case where I would like to be able to edit the source; that way, as I work out names and fields, I can rename them as needed. I could also fix the p_ names of the arguments.

[jabelar]

I'm not sure how the MCP project works (I think they're the guys coming up with the human-readable names), but maybe you can submit stuff you figure out.  Keep in mind that all this stuff is done by volunteers as a community project.  Maybe you can contribute as well

 

For my own sanity, where possible I'll extend the vanilla block and @Override, create wrapper methods, or even just add comments for what I can to be more readable.

[Reika]

I'm not sure how the MCP project works (I think they're the guys coming up with the human-readable names), but maybe you can submit stuff you figure out.  Keep in mind that all this stuff is done by volunteers as a community project.  Maybe you can contribute as well

The problem is, if I submit a name, if it goes through at all - something my experience has taught me is unlikely - that it will have to wait until a new MCP build, something which may well not happen again until a new MC version comes out. Given that said version will be MC 1.8, there is no point in trying to get further 1.7 updates.

 

For my own sanity, where possible I'll extend the vanilla block and @Override, create wrapper methods, or even just add comments for what I can to be more readable.

That would work if it was my own class, yes. The problem is where I am calling functions, like in the world class, which happens to be where my worst problems are.

 

By the way, markBlockForRenderUpdate is now func_147479_m.

[jabelar]

That would work if it was my own class, yes. The problem is where I am calling functions, like in the world class, which happens to be where my worst problems are.

 

By the way, markBlockForRenderUpdate is now func_147479_m.

No, what I'm saying is that for functions you figure out you can make a method in your own class that calls the other method.

 

Like this:

public void markBlockForRenderUpdate(int parX, int parY, int parZ)
{
    World.func_147479_m(parX, parY, parZ);
}

 

It is still bit of a pain, but can help improve the readability and might save you some headache for those methods you use a lot.

[Reika]

That would work if it was my own class, yes. The problem is where I am calling functions, like in the world class, which happens to be where my worst problems are.

 

By the way, markBlockForRenderUpdate is now func_147479_m.

No, what I'm saying is that for functions you figure out you can make a method in your own class that calls the other method.

 

Like this:

public void markBlockForRenderUpdate(int parX, int parY, int parZ)
{
    World.func_147479_m(parX, parY, parZ);
}

 

It is still bit of a pain, but can help improve the readability and might save you some headache for those methods you use a lot.

 

Clever. I like that.

 

I am actually going to do it whether or not functions get renamed, because by "funneling" all my calls through something I control I can reduce the amount of changes needed from update to update.