1.5.1 runtime deobfuscation missing names

[gcewing]

Is anyone successfully using runtime deobfuscation with Forge 7.7.1.611?

 

The deobfuscation_data file that this version of Forge uses appears to be missing some rather crucial field names. In particular, all the static fields defined in the Block, Material and MapColor classes are missing. Without access to these fields, it's almost impossible to define any custom block classes, so I have trouble seeing how this wouldn't affect just about every mod in existence.

[AzureusNation123]

im using it and it works fine just make a new mcpv44 folder and extrack the forge folder in ther and go in to the forge folder and install it and the deobfuscate, it should work fine

[LexManos]

Its not missing any names.

[gcewing]

  On 4/12/2013 at 3:39 PM, LexManos said:

Its not missing any names.

Maybe I've got the wrong idea about what runtime deobfuscation means. I've been assuming it means I don't need to reobfuscate my mod -- I should be able to drop the unobfuscated classes into a standard Minecraft instance and it will run. That doesn't work for me; I get errors like

 

2013-04-13 12:29:34 [iNFO] [sTDERR] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
2013-04-13 12:29:34 [iNFO] [sTDERR] 	at gcewing.sg.BaseMod.newBlock(BaseMod.java:140)
...
2013-04-13 12:29:34 [iNFO] [sTDERR] Caused by: java.lang.NoSuchFieldError: blocksList
2013-04-13 12:29:34 [iNFO] [sTDERR] 	at gcewing.sg.SGRingBlock.<init>(SGRingBlock.java:41)

 

So, have I got the wrong end of the stick? Is this meant to work or not?

[LexManos]

No you still need to rebfusicate your mods. To srg names.

Hence the reobfusicate_srg script.

Mapped names change, obfusicated names change, srg names don't. Thats how things work.

[gcewing]

Thank you! That's the piece of information I was missing.