Forge could have theoretically automated that. Or hell, Mojang could have provided backward compatibility for a while. They dont fully understand the importance of mods yet...
1.5.2 Oh joy!
- Thread starter Jyzarc
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
When you absolutely, positively, don't want to update before you want to, MultiMC. Accept no substitutes. 
I should probably explain what runtime deobfuscation actually is.
Java code, unlike most code, is easy to decompile - you can pull it apart and get back pretty much the same code that the author originally wrote. This means you can get back the full source code for the program and (in theory) steal it however you like.
Obfuscating code is a fancy way of saying "do find and replace on all the names of features and procedures in the code to total gibberish before compiling it". As the names in the code are mainly for the benefit of humans reading the code and all that's required by a computer is that references to that same piece of code all need the same name so it can actually find it, obfuscating code makes the code harder for people to borrow for their own ends without breaking it for your actual program.
The problem for modders is that Mojang use new gibberish for each version of Minecraft, so old mods always break in newer versions because they look for code they need in the wrong place or a place that doesn't exist anymore. Most of the MCP project revolves around finding out what parts of code in Minecraft do and then giving them a useful human-readable name again.
With runtime deobfuscation, it means that the gibberish is translated to the correct human-readable name when the code is actually run by the user. To make this possible Forge has to keep a list of all the name mappings, which it now does as of Minecraft 1.5.0. So long as mods point to a name that Forge recognises and can translate to the appropriate gibberish, it won't break...
...unless, as has already been pointed out, the code being pointed to no longer works the way the mod code needs it to work and breaks anyway. If that happens then the mod has to update to work with the new Minecraft code anyway.
Does that make more sense now?
Java code, unlike most code, is easy to decompile - you can pull it apart and get back pretty much the same code that the author originally wrote. This means you can get back the full source code for the program and (in theory) steal it however you like.
Obfuscating code is a fancy way of saying "do find and replace on all the names of features and procedures in the code to total gibberish before compiling it". As the names in the code are mainly for the benefit of humans reading the code and all that's required by a computer is that references to that same piece of code all need the same name so it can actually find it, obfuscating code makes the code harder for people to borrow for their own ends without breaking it for your actual program.
The problem for modders is that Mojang use new gibberish for each version of Minecraft, so old mods always break in newer versions because they look for code they need in the wrong place or a place that doesn't exist anymore. Most of the MCP project revolves around finding out what parts of code in Minecraft do and then giving them a useful human-readable name again.
With runtime deobfuscation, it means that the gibberish is translated to the correct human-readable name when the code is actually run by the user. To make this possible Forge has to keep a list of all the name mappings, which it now does as of Minecraft 1.5.0. So long as mods point to a name that Forge recognises and can translate to the appropriate gibberish, it won't break...
...unless, as has already been pointed out, the code being pointed to no longer works the way the mod code needs it to work and breaks anyway. If that happens then the mod has to update to work with the new Minecraft code anyway.
Does that make more sense now?
Hopefully more mods will start using that recent Forge feature that makes the MC version irrelevant, any time soon.
Eh, if this is a pure bugfix update, I imagine that it won't break anything too massively, so updates will either be not needed or trivial. 1.4.6 to 1.4.7, for example.
Also, apparently Mojang is getting better at releasing stable code, as it has been nearly a month and a half and we are only up to 1.5.2.
Also, apparently Mojang is getting better at releasing stable code, as it has been nearly a month and a half and we are only up to 1.5.2.
They have been working with either CPW or one of the other major modders to get this texture thing out. Its not some idiotic idea like that. Also you can hear the mod that was/is working with them for this texture improvement in the background of one of Direwolf's SMP letsplays (when he was working on the roller coaster).
There's no reason for Mojang to bend over backwards just for mod compatibility. Have you seen the change in question? (to vanilla ISidedInventory)
That wasnt the statement, was it. I said they *could* not *should*.
And youre right. Why should Mojang make things easier on their modding community? F them, right?
They want to make it easier for people to play and mod Minecraft. What they are doing is helping modding, although requires some initial work to transfer your mod.