Version-independent mod?

[Kinniken]

Hi guys,

 

Is there any doc somewhere on releasing a version-independent mod? I know it's supposed to be possible now but couldn't find any instructions. Just using the compiled but not reobfuscated code from mcp/bin doesn't work for me, I get this early in my mod's loading (probably the first call to an MC method):

 

java.lang.NoSuchMethodError: net.minecraft.client.Minecraft.getMinecraftDir()Ljava/io/File;

 

I'm not so much interested in releasing version-independent client versions (even without the reobf my experience is that every MC releases except for some bug fix ones break Millénaire anyway) but in testing MCPC+ for 1.5.1.

 

Thanks

 

K.

[Viper283]

you have to use the reobfuscate_srg.bat/sh. ifthat it not there, just add "--srgnames" at the end of the reobfuscate.bat/sh

[Kinniken]

Thanks, that worked! And my mod now runs in MCPC 1.5.1.

 

Any particular pros and cons of using this BTW? Beyond of course that my mod will no longer be affected by changes in obfuscation (but will still likely need updating due to change in method signatures etc. in about every version)?

[Draco18s]

OK, so I went looking at this.

 

What is the farthest back a mod can be and still make use of the version independence?  There's a guy going around on the Minecraft forums telling all the 1.4.7 mod owners to "reobfuscate with the latest reobfuscale_srg" and it'll magically update them to 1.5.1

 

But I can't seem to get it to work.

 

I can't just add "--srgnames" to the end of the reobfuscate.bat file, I get an error:

 

reobfuscate.py: error: no such option: --srgnames

[LexManos]

No things don't get 'magically updated' Especially between 1.4 and 1.5

You will ALWAYS have to update to handle changes in minecraft with things you interact with.

However, 1.5 and 1.5.1 is the perfect example of why runtime deobfusication is a good thing.

The obfusication changed between 1.5 and 1.5.1 because there were a few new classes introduced. HOWEVER no real functionality changed.

There were a few changes with the MC Realms stuff but nobody uses that.

So any real mod who was made for 1.5 and reobfusicated to srg names will most likely works fine for 1.5.1.

 

Basically, the real benifits are for things between minor mc releases.

For example, if we had this in 1.4, it is quite likely that most mods would not of had to update for 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, or 1.4.6 {kinda seeing why its a good thing?}

 

I've explained this many times before. However I guess I will do it again.

There are 3 'types' of names for minecraft:

 

Notch, or Obfusicated: Classes named crap: 'a', 'b', 'asd', Fields/Methods name really useless names like 'a', 'b', 'qwe', these change between EVERY minecraft version.

 

SRG Names: Classes receive good names 'Item', 'Block', and all Fields/Methods get unique names 'field_1234_b', these names are designed to be constant cross minecraft versions, unless minecraft actually removes/changes signatures the names will be the same.

 

Mapped Names: Based off SRG names, but fields/methods are given community names such as 'getMiencraftDir', 'update' etc.. The problem with these names is that they are community based. And change on whims.

 

So, its the logical choice for us to go with SRG names as they are stable cross versions.

 

So basically. if you reobfuscate to srg names, your mod MAY be able to work cross obfusication changes. If you don't it has ZERO chance.

 

You would only have to update your mod if minecraft changes things that you mod actually uses.

As the vast majority of minecraft is stable code, the vast majority of mods will be able to have a stable platform.

[Kinniken]

Ok, thanks for the review LexManos. I had not realised that the "srg" names were the "field_1234_b" ones, not the user-friendly ones.

 

With that setup yes most mods should indeed work across bug fixes. IIRC when I updated Millénaire to 1.5.1 the only compilation errors were due to mapped names changing.

 

Any performance hit in that new setup though? The srg names must be remapped to the obfuscated ones when MC runs right, doesn't that slow thing down a bit?

[agaricus]

Any performance hit in that new setup though? The srg names must be remapped to the obfuscated ones when MC runs right, doesn't that slow thing down a bit?

Actually its the opposite. FML deobfuscates everything to srgnames at runtime, including Minecraft itself. Runtime deobfuscation is always enabled [1], so obfuscated mods will be deobfuscated at runtime as well, though version-independent mods won't need deobfuscation. But the transformer still runs, and several other transformers run as well (for access, siding, coremods, etc.); I would not expect you to see any noticeable performance difference from version-independent/version-dependent mods (but I haven't benchmarked anything, FWIW). Also note the transformation only applies at class load time - once the classes are loaded, they are as fast as any other class.

 

[1] Not quite true, FML will skip runtime deobf if it detects a non-obfuscated environment, e.g. testing with MCP's start scripts. The other instance where runtime deobf is disabled was:

 

I'm not so much interested in releasing version-independent client versions (even without the reobf my experience is that every MC releases except for some bug fix ones break Millénaire anyway) but in testing MCPC+ for 1.5.1.

I had to temporarily disable deobfuscation in the early builds of MCPC+ 1.5.1 due to an issue with the server deobfuscating itself (FML issue #210 if you're interested, some obscure edge case with overloaded fields), effectively "pre-deobfuscating" the server at compile-time. This had the consequence of only supporting version-independent mods since the deobfuscation transformer did not run for them either. But as of builds 261+, runtime deobf is now enabled, so both types of mods should load. I just tested loading Millénaire, works great (awesome mod btw, great work).

 

Going back to the question of performance, for MCPC+ I considered continuing to pre-deobfuscate the server (but enabling deobfuscation of mods), with the hope of better startup times. Forge and FML have to deobfuscate Minecraft itself due to how they are distributed (patches over vanilla classes), but since MCPC+ being based on CraftBukkit is a complete server jar, theoretically it could be deobfuscated at compile time. I.e., rather than remapping from MCP csvnames in the source code -> obfuscated names in the compiled binary -> deobfuscated srgnames at runtime, cutting out the middle step and going straight from csvnames in the source -> srgnames in the compiled binary. In fact this is how MCPC+ was built temporarily since the deobf issue was with obf -> srgnames, but now that that works, MCPC+ is compiled to obfuscated names just like a vanilla server. Maybe pre-deobfuscation is something that could be reconsidered in the future, but its probably not worth it, would be non-trivial to implement and again I expect little to no performance benefit.

 

Any particular pros and cons of using this BTW? Beyond of course that my mod will no longer be affected by changes in obfuscation

About the only con is that your mod might work when you don't want it to .

 

What is the farthest back a mod can be and still make use of the version independence?  There's a guy going around on the Minecraft forums telling all the 1.4.7 mod owners to "reobfuscate with the latest reobfuscale_srg" and it'll magically update them to 1.5.1

"Version-independence" only guards against obfuscation changes - unfortunately not actual code changes (only real way to do this is with an API). So if Mojang changes the code a mod relies on, it may not work as intended. In 1.5, texturing significantly changed, several older methods which mods relied on no longer exist. And most all mods use textures of course. Not to mention, reobfuscate_srg was added in 1.5. But throughout the 1.5.x minor releases, you can expect version-independence to take effect. A couple mods built with srgnames for 1.5 already work for 1.5.1 (Portal Gun and Gravity Gun at least).

 

With that setup yes most mods should indeed work across bug fixes. IIRC when I updated Millénaire to 1.5.1 the only compilation errors were due to mapped names

 

This is an interesting point - as Lex explains, srgnames were chosen for FML runtime since they are as version-independent as possible. The mapped descriptive csvnames are up to the community via MCPBot submissions, so they are more volatile than srgnames. So curiously, a mod's compiled binary may be more stable across versions than its source code.

 

One way to ensure version stability of source is to write your mod using srgnames. This is the approach FML itself takes, and it works pretty well for this purpose. But the downside is the user-unfriendliness of srgnames - with FML's relatively small patches, its not too big of a deal, but if you're writing a large Forge mod using srgnames everywhere would just be unbearable, leading to unreadable code. And after all, the mapped csvnames are intended to be descriptive and human-readable.

 

Another possible solution is to use csvnames, but with a source-remapping tool to update the names automatically. We now have Srg2source, which can mass-rename large source code bases thousands of times faster than any IDE's built-in rename refactoring tool. Currently it is being used to automatically remap each commit of CraftBukkit into MCPBukkit, and it is tailored for that purpose, but in principle it could be reworked as a more general-purpose tool for modders. Something I've been wanting to look into, but haven't got around to it. A tool sort of like MCP's updatenames, but supporting not only renaming unmapped names (srgnames) to mapped names, but also arbitrary symbol renames between MCP updates.

 

However, even if such a tool was used, it wouldn't take care of all symbol changes. Renames of mapped symbols are relatively rare (MCPBot requires a force update command, and its considered polite to only rename very poorly named symbols since it can break people's mods). In the 1.4.7 to 1.5.1 update, many symbols which appear to have been renamed were actually new altogether. The world block setting methods, for one. Signature changes, new parameters, regarded as new symbols by srgnames. So a source-based remapping tool using srgnames wouldn't take care of these situations. Still would be cool to have such a tool packaged up and easily available for modders to use, though (srg2source works today for this purpose, but it may not be the easiest tool to use unless you want to read the code and see how it works, what options are required, generating the update mappings, etc).

[Kinniken]

Thanks for all the information, it makes things clearer. I hadn't realised that Forge ran Minecraft in deobf mode. BTW if you tested Millénaire using the latest version (4.6) it was a version-independent one.

 

And yes I know MCP is conservative when it comes to renaming methods. For my 1.5.1 update most of them were indeed new 1.5 methods getting a proper name for the first time. In the past I've noticed real renames mainly on major version bump - I assume because they felt that it's the good time to do it, as people have to update anyway (and I agree).

 

Anyway, so with no speed difference to speak of, I guess I'll continue using the new feature. That it works over bug fix versions is really nice. My only concern is that for major updates it will likely "mostly work" with unpredictable crashes wherever Mojang changed the code. That could potentially lead to nasty bugs, maybe data-destroying ones (hard to say since it will depend on what has changed, of course). Maybe a setting could be added to forbid a mod from running in a different major version?

 

And good luck with MCPC+, it's really a cool product.