How are mods updated?

[APproject]

I'm curious as to how mods are updated.
How must a developer alter code to make a mod compatible?
How much does the core MC code change from update to update?
Why can't they be upgraded with minimal effort?

I am familiar with how Java works, but I've never understood the updating process.

Furthermore, given that MC releases all those pre-releases, why aren't developers ready when an update actually comes?

This is not intended to criticize anyone or anything; I am curious. And I'm sure some of you are too.

Thanks for any info you may have!

 

[Saice]

I'm curious as to how mods are updated.

Well it is good to be curious.

How must a developer alter code to make a mod compatible?

It depends but in most cases it requires finding changes in code and having to adjust for them. Sometimes it is as simple as just updating a few tags here and there other times it requires a major rewrite of large parts of the mods code.

How much does the core MC code change from update to update?

It depends but you can look at the patch notes as a basic rough outline. The more done, added, or fixed the more code most likely had to be update, changed, or outright replaced.

Why can't they be upgraded with minimal effort?

I am familiar with how Java works, but I've never understood the updating process.

If you understand Java and by extention how programing is done you should know why minimal effort is rarely part of the act of updating code.

But in more basic terms it is because any update will require the mod maker to go sometimes line by line looking for changes that effect their own code. Then patch their code. Test it. Find out something else broke and start the line by line sreach again. Othertimes its not so bad.

Furthermore, given that MC releases all those pre-releases, why aren't developers ready when an update actually comes?

Pre-Releases are not final code often many times the final code is diffrent from the Pre-Release code meaning there is little to no point to try and make changes until the final release it pushed out becuase you could spend hours or days fixing something only to have to do that all over again when the actual release comes out. Even then it is good to wait for a bit on a full release becuase sometimes they will have to push out a few hotfixes for bugs. So in most cases a dev is going to wait until a full release before even looking at updating. A few will start with a pre-release code but you gambling that your time may be wasted if you do so.

This is not intended to criticize anyone or anything; I am curious. And I'm sure some of you are too.

Thanks for any info you may have!

Basicly to sort of sum up here. The big slow down is mojang does not always send out a full detailed letter to all the mod makers detailing all changes to their code. They don't host something like a GitHub and most devs for mods basicly have to try and figure out what was changed between every update. Something that sounds simple sometimes has huge impacts on code.

 

[APproject]

Thanks for the response!

Could some of the tension be resolved if Mojang were to release source code and what not to modders?

 

[Saice]

Thanks for the response!

Could some of the tension be resolved if Mojang were to release source code and what not to modders?

Here is the thing. Source code is not something a company always wants to release in full. But even just giving the full code (which people can just decompile on their own if they wish) is not really going to speed things up. What modders would need is something akin to github where every change is documented when and where it happened. This really is not something Mojang wants to do. It is also why they basicly changed how mods can interact with MC in 1.6 (and why they keep saying there will be a real mod API).

The sad turth is while Moding is one of the things that keeps MC alive it is not the only thing and there are many they still play vanilla and many new people coming into MC everyday. Mojang at least relizes mods help them and have been trying to make mods easier to impliment. They have worked with people like Bukkit and Forge form time to time. But in the end the devs still get the code the same time all of us get it. And the last few updates 1.5-1.6-1.7 have done major changes to core parts of the game meaning they have made some mod devs rewrite there mods sometimes completely in order to work with the new code.

So as it stands mods will never be ready at launch of new MC code unless that change is vary tiny. And Mojang has little incetive to change this though they are trying to make it easier.

 

[FyberOptic]

Sometimes changes required for mods are due to Minecraft itself changing, and other times they're from MCP and Forge changing.

First of all you have to keep in mind that Mojang obfuscates Minecraft, so when it's decompiled, the MCP team has to go about the arduous task of determining what the entirely random function and variable names mean. Reverse engineering can be very difficult and time-consuming, yet they have to do this for every version. I'm sure they have tools to help identify code fragments which haven't changed (or changed much) based on previous efforts. But any time new code is added by Mojang, it requires them to go through it line by line and figure out what it does. With Minecraft 1.7, for example, they say up to a third of the code has changed. It's a major undertaking, and it's why we should all always be very grateful to the MCP team, without which we wouldn't even be here right now.

As you can imagine, there's not a lot of point in deobfuscating and reverse-engineering the snapshots and preleases, because code is still going to change, as are the obfuscated names. In some cases it might help them get a jump on things, but in other cases it's just doing the same work twice.

But the obfuscation has an even deeper implication for modding: coremods. Sometimes you need to change the way Minecraft itself works. Maybe you need to add a hook to something to interact with it in your own code, or you want to change entire native functionality. You could do this through a jar mod, where you just compile and reobfuscate your code and drop it in the jar, but this really isn't recommended anymore if you want to be compatible with as many other mods as possible. Coremods on the other hand are able to intercept the loading of Minecraft classes, and allow you to either replace the entire class (not really recommended), or parse through it and add/remove/replace the raw Java bytecode (the most recommended method). Well, when you're developing your mods, everything is deobfuscated, including Minecraft. These easily-recognizable names are the ones you search for to modify during development. However, when your mod is compiled, reobfuscated, and running in a regular Minecraft client, Minecraft itself is obviously obfuscated now as well. This means in your coremod you have to be intercepting the obfuscated class, method, and variable names you intend to replace. You never know what the obfuscated names will be between versions, and they usually change. There's also the possibility that the code you're modifying could have changed, which might mean you have to change how you're parsing for it. Overall, it means compiling your coremod for essentially every version of Minecraft you want to support.

As for Minecraft itself, you have other major internal changes. Between 1.2.5 and 1.3, for example, it was pretty big. The client and server were "merged" so that even singleplayer games ran on an internal server. Beforehand, you had to write two separate mods. Afterward, you wrote just one. But obviously this had major implications from a programming point of view. All of your code was now always running in two places at once. The "proxy" system was implemented so that you could still have server and client-specific code, because there will still be times when you only want certain code to execute on one or the other. There were significant other differences as well, from everything on how you registered blocks, to recipes, to doing custom rendering, entities, key bindings, etc. Due to the effort required, some mods never updated again until Minecraft 1.4.x.

When Minecraft went from 1.4.7 to 1.5, textures were a major change. Before that you could have sprite sheets, but afterward every texture had to be in a separate file. Minecraft now stitched these together internally, handling all UV coordinates itself. There was also a new directory structure that they were supposed to be stored in. This all resulted in code-based changes in how you loaded and assigned your textures as well. Very tedious work, particularly for larger mods.

Minecraft 1.5.x to 1.6 was more changes in textures. They were in a different directory now. Differences in deobfuscated method names also resulted in changing how you specified your textures. Also, the way that Forge handled mod initialization changed. I'm sure there were other differences, some significant depending on what your mod did, but these are the two biggest things I deal with when maintaining two of my mods between both.

I could go on and on, and there were way more changes with all of these version differences than I'm mentioning, but I think you can start to get an idea. Forge isn't one central API which all mods can interact with; mods use native Minecraft methods to interact with the game. The introduction of SRG names with MCP was a huge improvement, where MCP began trying to map the same function names across as many similar versions of the game as possible, so that regular mods could likely work without recompiling. But when Mojang changes something significant, mods typically have to change as well. Sometimes it's huge changes, other times not so bad.

Another major upcoming change is apparently doing away with block IDs, using labels instead. This would be a significant improvement for both modders and players, since block ID conflicts have always been a bane. But internally this will have huge ramifications for developers.

Anyhoo, unfortunately, with 1.7, it's a big one. Eventually things will get caught up, and I'm sure we'll get to use some amazing mods along with all the great new features Mojang added. But in the meantime, we just have to wait, while the MCP and Forge teams do their magic.

 

[SatanicSanta]

Thanks for the response!

Could some of the tension be resolved if Mojang were to release source code and what not to modders?

Nah
Forge modders use the Forge source code, that's why there is this weird legal grey area when it comes to modding.

How must a developer alter code to make a mod compatible?
That depends, sometimes they want to completely rewrite their mod, which I'm sure you can imagine how long it would take. Usually it's just a matter of finding changes, which can be a lot depending on your mod
How much does the core MC code change from update to update?
That also depends
Why can't they be upgraded with minimal effort?
... Modding is hard work.
Furthermore, given that MC releases all those pre-releases, why aren't developers ready when an update actually comes?
When it comes to Forge modding, you have to wait for the Forge releases, which replaces most of the MC source code.

 

[FyberOptic]

Nah
Forge modders use the Forge source code, that's why there is this weird legal grey area when it comes to modding.

Forgive me if you simply misspoke, but to avoid confusion I should point out that it's MCP which provides the reverse-engineered Minecraft source code for modders. FML (part of Forge) then makes it possible to load mods (including everything a coremod needs in order to parse/replace code) and provides some other lower-level API stuff for interfacing with certain objects in the game, detect other mods, etc. Forge itself then provides the higher-level API stuff for making your mod easier, primarily to interact with hooks it's implemented into various parts of Minecraft (which mods commonly use to avoid needing to be coremods), as well as things like rendering helpers and general utility code. I don't like to say that this is "all" they do, since they still do a lot for modders, but yes, this is all they do. It's not a complete Minecraft API by any means, unfortunately, which is why mods must interact so heavily with Minecraft itself, and why mods are therefore very version-dependent.

Folks might also be interested to know that the reason it's legally "okay" to distribute MCP is because it doesn't actually come with Minecraft source code when you download it. You have to run a setup script which fetches the Minecraft JAR that it needs, all of the related libraries Mojang uses, all of the media assets, etc, then starts decompiling and deobfuscating the code for you. It's a very clean process from a modder's point of view. Point-and-click, even! Then when you're ready to package your mod up, you use other scripts they included, making it very easy to compile and reobfuscate your code. They've done an awesome job making this all streamlined for mod developers. They even include a fully-configured Eclipse workspace, so that you can jump right in!

And it's also worth noting that Forge too comes with an installation script, which will in fact download MCP for you by itself, automatically run MCP's setup, then install Forge into that source code, recompile it, make sure everything works, and then you're ready to go. Again, an awesome job.

As for Mojang releasing source code, that's not entirely important. Java is relatively easy to decompile. If Minecraft weren't obfuscated, however, then modding would be significantly easier for various reasons. The obfuscation alone is what requires all of the work by the MCP team to reverse-engineer, label everything, set up the entire system of automatic deobfuscate/reobfuscate tools and mappings, make sure it recompiles properly, etc. Obfuscation is also what required you to compile your mod for every single version of the game before SRG names came out, which as I mentioned above, now automatically maps the human-readable reverse-engineered names of classes/methods/variables into the obfuscated versions, even if the obfsucated names changed between Minecraft updates. Doesn't apply to core mods or JAR mods though, since that code is still pretty much for the specific version of Minecraft that it was compiled for. And lots of mods out there still need core mods.

Essentially, obfuscation has always been the primary reason why mods need such frequent updates. But Mojang has to protect their property, even if just for legal reasons.

If it were possible for Forge to be the be-all end-all Minecraft API, where mods only ever interacted explicitly with it, then this would be less of an issue. But there's just no way they can cover every single thing that a modder might want to do in the game. So, all things considered, I would still say that the current system is still pretty amazing, even if it does mean compiling some mods for every Minecraft version.

(Holy crap I did it again with another big-ass post.)

 

[SatanicSanta]

@FyberOptic
Now you're talking about decompiling things which has nothing to do with mod updates.
With a Minecraft update, Forge gets updated later, when the Minecraft source code changes dramatically (some good examples are 1.2.5 to 1.3, 1.6 to 1.7, etc). With these core changes, mods have to adapt to these changes.
Technically speaking, Forge does have different source code than Minecraft, which is why it is okay to distribute.

 

[FyberOptic]

@FyberOptic
Now you're talking about decompiling things which has nothing to do with mod updates.
With a Minecraft update, Forge gets updated later, when the Minecraft source code changes dramatically (some good examples are 1.2.5 to 1.3, 1.6 to 1.7, etc). With these core changes, mods have to adapt to these changes.
Technically speaking, Forge does have different source code than Minecraft, which is why it is okay to distribute.

Decompiling is the flux capacitor of modding. It's what makes modding possible.

When Minecraft updates, the MCP team decompiles it, examines it, labels anything new, sets up all the proper mappings, and creates a new version of MCP for it. This has to happen for literally every Minecraft version.

The Forge team then gets MCP, uses it to decompile Minecraft as well, examines what's changed, inserts their own hooks back into the decompiled source, creates their set of code patches to distribute, which are installed into the MCP source code when the modder runs the install script. This also happens for every single Minecraft version.

 

[SpitefulFox]

I'm curious as to how mods are updated.
How must a developer alter code to make a mod compatible?
How much does the core MC code change from update to update?
Why can't they be upgraded with minimal effort?

As mentioned above, Minecraft is "obfuscated". Instead of classes having helpful names like EntitySlime.class or BlockSand.class, they completely meaningless jumbles of letters like aj.class. Method names are also completely nonsensical. Programs are obfuscated in order to protect the author's work from being reverse engineered, but, as you probably noticed, this obfuscation hasn't stopped people from reverse engineering Minecraft's code in order to modify it. Most mods are written by using MCP to decompile and deobfuscate Minecraft so that it's readable, and then writing a mod using that code. Once the mod is done, MCP can obfuscate the mod so that it matches Minecraft's obfuscation.

Every time a new version of Minecraft comes out, the obfuscation changes. What may have been ab.class last version could now be pk.class this version. If you compile and obfuscate a mod for one version, it won't work with a different version because the obfuscation has changed. Unless your mod makes ZERO use of Minecraft's classes, your mod is going to be making references to classes and methods that no longer exist under those names. Thus, even if next to nothing changes in a Minecraft update, most mods still break and need to be updated simply because they no longer match the new obfuscation. Part of the reason why there's a delay after every update is because everyone has to wait for the MCP to finish cracking the new obfuscation.

Once MCP updates, you still have to run your mod through it again and try to recompile and reobfuscate it. While the general layout and structure tends to stay the same, MCP's "translation" of the obfuscated code tends to wiggle slightly between updates. What once may have been called "shiftedIndex" in one version could become "itemID" in a newer version. Trying to recompile a mod for a new version without changing any code can easily rack up a multitude of errors over little changes like that.

And that's not even getting into the mess that ensues when Minecraft actually changes something that you've been using for a while.

 

[ScottulusMaximus]

Most interesting thread EVAH!!! Thnx guys...

 

[Celestialphoenix]

I knew updating was a pain in the rear, but this thread certainly puts it all into scale.

Which begs the question- why bother going through with it?​

Surely it'll be better if we stick on the same MC version and branch out into more diverse and complex mods?​

​

 

[MigukNamja]

Also keep in mind the vast majority of people in the MC modding community do it for fun and don't make enough from donations to quit their day jobs - not even close.

As such, they are by and large volunteering their time and efforts and owe us nothing.

Contrast this with a large game development house like EA and Blizzard-Activision or even a smallish one like Paradox Interactive and it's not even close in terms of engineering hours spent on game developments and updates.

But, as a software engineer myself, I am in awe of the MC modding community and how so many people give freely or their time and substantial skills to make the MC modding scene what it is. It is a great example of human motivation beyond selfish greed.

 

[FyberOptic]

I knew updating was a pain in the rear, but this thread certainly puts it all into scale.

Which begs the question- why bother going through with it?​

Surely it'll be better if we stick on the same MC version and branch out into more diverse and complex mods?​

​

I think people just enjoy having the latest and greatest. When major new Minecraft versions come out, you'll find lots of even avid modded Minecraft fans going back to play vanilla just to see what's new. Twitch has had quite a few 1.7.2 streams lately, for example. Similarly, I think most mod developers probably enjoy updating their mods to some degree, getting to see what's new and improved in the Minecraft and/or Forge code, possibly making their jobs easier in the long run. Forge added support for handling fluids within the last few months, for example, which is why you now see so many mods which have liquids that can be used with one another's contraptions. And Forge constantly moves forward, pushing out several updates within a single Minecraft version alone, and then updating to the newest MCP shortly after it's released. So if you want to take advantage of any new API features, you basically have to keep up with the Minecraft versions as well.

Seems like sometimes the community kind of hits a stumbling point though, such as with the 1.2.5 -> 1.3.1 update, where so many mods take so long to update that developers keep supporting the old version longer than normal due to how many people are still playing them. You might see that happen here with 1.7.2, I dunno. Or particularly when the new block ID system is implemented in the future.

 

[Saice]

I'd would also add to FiberOptics statment that even modders tend to like the latest and greatest becusae some of the improvments to the game actuall make modding better in the long run. Sure things like the biome rewirte and moving texutres from sheets are a pain for a modder to update around. But once done it does improve things going forward. MC has been trying to improve its world saves and its rendering for awhile now and these in the long run can only make things better for everyone. MC had already gone through a few major changes just how the engine it self works and I am fairly sure moders would not want to go back to pre 1.0 MC map, save, and rendering engines.

 

[portablejim]

Just wanted to chime in...

The SRG names feature of MCP maps obfuscated functions to fixed names (within main minecraft versions) so that mods can still work when the obfuscation changes. Functions can even change names without changing the SRG function name, keeping mods working. The problem is that there are still some mods which do not do this.

Let me give specific examples with the move from 1.6.2 to 1.6.4, as it was a minor update that happened recently...

With modpacks moving from 1.6.2 to 1.6.4, it was that several mods "just worked" in 1.6.4 because of the mods were using SRG names and the functions they used. For example in the current 1.6.4 Overload pack, out of 114 mod files, 12 are still labeled as 1.6.2 (in the filename) and 2 that just say 1.6.x (full disclosure: one is mine) and the rest don't specify or specify 1.6.4. Included in this list is Buildcraft. A few mods saying 1.6.4 have been updated after the release of 1.6.4 and so are labeled as 1.6.4 mods even though the 1.6.2 version would have worked fine.

Other mods, as others have been saying, needed to change the code because the methods they used changed. The specific functions that changed and where they were in the loading process meant that they either crashed on game startup or crashed when you tried to use it. One example of this is Mystcraft. Mystcraft uses structure code to create a mystcraft house in any villages that spawn. Apparently you could use Mystcraft for 1.6.2 in 1.6.4 except you would corrupt your world when a village spawns due to the change in code. (gotten from the mystcraft blog)