Compatibility with CameraStudio broke up !

[Sushen]

Hi, I'm the CameraStudio mod author,

 

I post in here because my mod used to work with versions prior to 1.5, but now it doesn't launch anymore with forge's latest version (although it's totally compatible with modloader).

 

As an experienced developer, I always paid attention to stay compatible with other mod makers, BUT, after some investigations, I found out that your reobfuscated code keeps searge field mappings instead of restoring minecraft vanilla ones.

To be more precise, it seems out you're changing the field names dynamically with the asm lib - at least I suspect it, because the vanilla fields are present in your distrib class files, but not anymore when Minecraft is launched.

 

I don't know if it's intended to work so, but, by doing such a thing, you're breaking compatibility with all other mods that need to acces minecraft specific internals.

 

I don't know if you're aware of this problem, so, I report it here, and I would like to know if you're going to change something about this behavior.

 

Thank you for your attention,

Sushen

 

 

[Sushen]

Here is more detail if you're wondering what I'm talking about - which I doubt, but one never knows ^^

 

I'm running the following code in the first onTickInGame modloader call :

Field[] fields = EntityRenderer.class.getDeclaredFields();
String msg = "Fields for class " + EntityRenderer.class.getName();
for (Field field : fields) {
    msg+= "\n"+field.getName();
}
Log.info(msg); // log with my own logger class

This code prints all fields of the EntityRenderer class (mcp name), which is bfr class with 1.5.1 mc version.

 

Results with vanilla or modloaded minecraft is :

 

Fields for class bfr

a

b

r

s

c

t

u

v

w

x

y

z

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

d

Q

R

S

T

U

V

W

X

Y

Z

aa

ab

ac

e

f

g

h

ad

ae

i

j

k

l

m

n

o

p

af

ag

q

 

.. and here with forge :

 

Fields for class net.minecraft.client.renderer.EntityRenderer

field_78517_a

field_78515_b

field_78531_r

field_78530_s

field_78516_c

field_78529_t

field_78528_u

field_78527_v

field_78526_w

field_78541_x

field_78540_y

field_78538_z

field_78489_A

field_78490_B

field_78491_C

field_78485_D

field_78486_E

field_78487_F

field_78488_G

field_78496_H

field_78497_I

field_78498_J

field_78499_K

field_78492_L

field_78493_M

field_78494_N

field_78495_O

field_78505_P

field_78513_d

field_78504_Q

field_78507_R

field_78506_S

field_78501_T

field_82831_U

field_82832_V

field_78500_U

field_78503_V

field_78502_W

field_78509_X

field_78508_Y

field_78510_Z

field_78536_aa

field_78514_e

field_78511_f

field_78512_g

field_78524_h

field_78537_ab

field_78534_ac

field_78525_i

field_78522_j

field_78523_k

field_78520_l

field_78521_m

field_78518_n

field_78519_o

field_78533_p

field_78535_ad

field_78539_ae

field_78532_q

 

Funny, because I'm asking fields for the bfr class, and I get answers for (magically translated  ) client.renderer.EntityRenderer class! (along with mcp mappings) 

[LexManos]

Yes, we now deobfusicate minecraft at runtime to a more stable environment so that modders can now start working on mods that can survive multiple minecraft versions.

We also deobfusicate every standard ModLoader mod or anything else that is loaded at runtime to srg names so everything should work fine.

However there will be edge cases, usually when someone is using dirty name based reflection without support for srg names.

For those edge cases we typically say its up to the modder to update as it's about a 2 second job which in all honesty they should already have as they need multiple names to test there mod in the dev environment...

 

Anyways, there is nothing 'magical' about your logs. Its doing exactly what it was intended to do.

Provide a stable codebase at runtime for modders. There needs to be a little cooperation with modders but for the most part its super super easy for them to do.