There's two halves to the reason why mods cannot be updated immediately. Right now, you have no clue how the mod development process works internally. Posts like this serve no practical purpose - we flat out cannot update without the dependencies.
Snapshots give tool-makers and map makers a chance to prepare, since the game structure will not change much. But mod makers can't work directly against snapshots - it's more or less impossible. Saying "Don't release snapshots" will not let mods get updated faster, since snapshots (generally) do not impede progress.
There are no forge builds for snapshots. Forge isn't targeted against snapshots. It's targeted against releases. And while you can try to port forge to snapshots, your port will fail on the next snapshot - such is the way of life.
You see, Minecraft is closed source and obfuscated. Have you ever looked inside of the Minecraft jar? The actual one, not the launcher? Classes are named things like 'awx' and 'bfz' (incremental series of letters). Methods are also named like that. And if Mojang introduces additional classes, these names shift. So it's futile to try and develop any large mod against a snapshot.
Now, no sane mod developer will work against these obfuscated names. Which is why there are deobfuscation/decompilation toolkits, mainly MCP (which forge depends upon). These provide sane environments to write code against, and reobufscate the code to make it reusable later. It also gives a bit of functionality between versions, since the deobfuscated names are (mostly) the same between versions, so long as MCP is released.
However, just because it doesn't make sense to develop against snapshots does not mean that snapshots should be removed. While snapshots are of little to no use to develop mods, they are great for toolmakers, and do let (to some level) toolkit developers plan what changes will need to be made to adapt. Admist, for example, was updated mid-snapshot to deal with the new stronghold locations and to find igloos. And wiki.vg has been hosting some level of pre-release protocol documentation, so that people who write custom clients can work with it. And the key point of snapshots is to find and fix bugs in Minecraft itself, so stopping them serves no purpose.
I would say that your poll showcases the pinacle of your ignorance to this subject. It's flat out neither of those choices. Snapshots do not create any sort of dependency - the obfuscation process might, but all major mods use a loader of some sort if they are to be compatible with other mods. This is a bytecode-level truth - you can't have two mods modify the same class, so you need forge to dynamically load the mods.
Let me reiterate - No major mod can be fully developed for a snapshot build; snapshot builds are a way to get a head start of some sort but you can't update code to it.
[rule]
We ARE trying to update. But there's a lot of steps, and it's nigh impossible to update instantly. 3 days is hardly enough time to fully update the deobfuscation tools, forge, and one's mod. And while as tools update mods update, we're not there yet.
[rule]
That said, bugfix updates after the release of a full update may cause issues, since the same problems with changing obfuscation may occur. In that sense, it may make sense to procrastinate on updating mods (and that's why mods were developed for 1.8 even when 1.8.7 was out). But it doesn't make sense to stop releasing bugfix updates. It's easier to just use earlier versions.
[rule]
Modders cannot develop against snapshots, for the reasons I've listed before. I tried, more to see if it's doable. A number of things prevented me:
The fact that everything has incomprehensible names without deobfuscation; although I do have some practice working with obfuscated code the majority do not
The fact that it would be partially broken next snapshot anyways
And my mod is (arguably) simple. It doesn't add any blocks or items, and only holistically does it add packets. I am able to work with just MCP. Any complex mod, like the ones you describe, needs a loader - usually forge.
I challenge you - Write a mod that adds blocks, and do it against 16w02a. And 16w05a, 16w03a, 15w51a, etc. It's not possible to work against those. But, again, that doesn't make snapshots something that inhibits modding - read the rest of my text.
If you're willing to argue on a technical level and give programmatically sound solutions, then maybe it'll make sense to debate with you. Otherwise, I just see someone who does not understand what they are doing, trying to explain why people who do know what they are doing don't.
[rule]
Oh, one final note - snapshots aren't an exclusive concept to Minecraft. Many libraries have snapshot releases, intended for getting prepared and acquainted with upcoming changes, but with the upcoming changes not yet being finalized nor stable.
There's two halves to the reason why mods cannot be updated immediately. Right now, you have no clue how the mod development process works internally. Posts like this serve no practical purpose - we flat out cannot update without the dependencies.
Snapshots give tool-makers and map makers a chance to prepare, since the game structure will not change much. But mod makers can't work directly against snapshots - it's more or less impossible. Saying "Don't release snapshots" will not let mods get updated faster, since snapshots (generally) do not impede progress.
There are no forge builds for snapshots. Forge isn't targeted against snapshots. It's targeted against releases. And while you can try to port forge to snapshots, your port will fail on the next snapshot - such is the way of life.
You see, Minecraft is closed source and obfuscated. Have you ever looked inside of the Minecraft jar? The actual one, not the launcher? Classes are named things like 'awx' and 'bfz' (incremental series of letters). Methods are also named like that. And if Mojang introduces additional classes, these names shift. So it's futile to try and develop any large mod against a snapshot.
Now, no sane mod developer will work against these obfuscated names. Which is why there are deobfuscation/decompilation toolkits, mainly MCP (which forge depends upon). These provide sane environments to write code against, and reobufscate the code to make it reusable later. It also gives a bit of functionality between versions, since the deobfuscated names are (mostly) the same between versions, so long as MCP is released.
However, just because it doesn't make sense to develop against snapshots does not mean that snapshots should be removed. While snapshots are of little to no use to develop mods, they are great for toolmakers, and do let (to some level) toolkit developers plan what changes will need to be made to adapt. Admist, for example, was updated mid-snapshot to deal with the new stronghold locations and to find igloos. And wiki.vg has been hosting some level of pre-release protocol documentation, so that people who write custom clients can work with it. And the key point of snapshots is to find and fix bugs in Minecraft itself, so stopping them serves no purpose.
I would say that your poll showcases the pinacle of your ignorance to this subject. It's flat out neither of those choices. Snapshots do not create any sort of dependency - the obfuscation process might, but all major mods use a loader of some sort if they are to be compatible with other mods. This is a bytecode-level truth - you can't have two mods modify the same class, so you need forge to dynamically load the mods.
Let me reiterate - No major mod can be fully developed for a snapshot build; snapshot builds are a way to get a head start of some sort but you can't update code to it.
[rule]
We ARE trying to update. But there's a lot of steps, and it's nigh impossible to update instantly. 3 days is hardly enough time to fully update the deobfuscation tools, forge, and one's mod. And while as tools update mods update, we're not there yet.
[rule]
That said, bugfix updates after the release of a full update may cause issues, since the same problems with changing obfuscation may occur. In that sense, it may make sense to procrastinate on updating mods (and that's why mods were developed for 1.8 even when 1.8.7 was out). But it doesn't make sense to stop releasing bugfix updates. It's easier to just use earlier versions.
[rule]
Modders cannot develop against snapshots, for the reasons I've listed before. I tried, more to see if it's doable. A number of things prevented me:
The fact that everything has incomprehensible names without deobfuscation; although I do have some practice working with obfuscated code the majority do not
The fact that it would be partially broken next snapshot anyways
And my mod is (arguably) simple. It doesn't add any blocks or items, and only holistically does it add packets. I am able to work with just MCP. Any complex mod, like the ones you describe, needs a loader - usually forge.
I challenge you - Write a mod that adds blocks, and do it against 16w02a. And 16w05a, 16w03a, 15w51a, etc. It's not possible to work against those. But, again, that doesn't make snapshots something that inhibits modding - read the rest of my text.
If you're willing to argue on a technical level and give programmatically sound solutions, then maybe it'll make sense to debate with you. Otherwise, I just see someone who does not understand what they are doing, trying to explain why people who do know what they are doing don't.
[rule]
Oh, one final note - snapshots aren't an exclusive concept to Minecraft. Many libraries have snapshot releases, intended for getting prepared and acquainted with upcoming changes, but with the upcoming changes not yet being finalized nor stable.
Deobfuscation mappings can be converted, however making the code compile
Deobfuscation mappings can be converted, however making the code compile
That's a valid point, and reminds me of something else. Forge actually does partially deobfuscate the game at runtime - I don't remember when they started doing so but they are doing it to make mods (at least hopefully) compatible between versions. And it's a good technique, when it works.
Still I don't think it helps too much with snapshot releases - you still need to create the deobfuscation mapping, which takes a while and then the next snapshot comes out :/
And I just remembered another point (not targeted at you) - in a way, snapshots make mods come out faster and do the oposite of slowing down modding. Snapshot builds let bugs get fixed before the full release, making it come out faster and also helping to ensure that there won't be a second bugfix release. So removing snapshots is even more counterproductive.
That's a valid point, and reminds me of something else. Forge actually does partially deobfuscate the game at runtime - I don't remember when they started doing so but they are doing it to make mods (at least hopefully) compatible between versions. And it's a good technique, when it works.
Still I don't think it helps too much with snapshot releases - you still need to create the deobfuscation mapping, which takes a while and then the next snapshot comes out :/
And I just remembered another point (not targeted at you) - in a way, snapshots make mods come out faster and do the oposite of slowing down modding. Snapshot builds let bugs get fixed before the full release, making it come out faster and also helping to ensure that there won't be a second bugfix release. So removing snapshots is even more counterproductive.
I believe Forge does that through deobfuscating the game to Searge mappings.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAbsolute, direct anti-support.
There's two halves to the reason why mods cannot be updated immediately. Right now, you have no clue how the mod development process works internally. Posts like this serve no practical purpose - we flat out cannot update without the dependencies.
Snapshots give tool-makers and map makers a chance to prepare, since the game structure will not change much. But mod makers can't work directly against snapshots - it's more or less impossible. Saying "Don't release snapshots" will not let mods get updated faster, since snapshots (generally) do not impede progress.
There are no forge builds for snapshots. Forge isn't targeted against snapshots. It's targeted against releases. And while you can try to port forge to snapshots, your port will fail on the next snapshot - such is the way of life.
You see, Minecraft is closed source and obfuscated. Have you ever looked inside of the Minecraft jar? The actual one, not the launcher? Classes are named things like 'awx' and 'bfz' (incremental series of letters). Methods are also named like that. And if Mojang introduces additional classes, these names shift. So it's futile to try and develop any large mod against a snapshot.
Now, no sane mod developer will work against these obfuscated names. Which is why there are deobfuscation/decompilation toolkits, mainly MCP (which forge depends upon). These provide sane environments to write code against, and reobufscate the code to make it reusable later. It also gives a bit of functionality between versions, since the deobfuscated names are (mostly) the same between versions, so long as MCP is released.
However, just because it doesn't make sense to develop against snapshots does not mean that snapshots should be removed. While snapshots are of little to no use to develop mods, they are great for toolmakers, and do let (to some level) toolkit developers plan what changes will need to be made to adapt. Admist, for example, was updated mid-snapshot to deal with the new stronghold locations and to find igloos. And wiki.vg has been hosting some level of pre-release protocol documentation, so that people who write custom clients can work with it. And the key point of snapshots is to find and fix bugs in Minecraft itself, so stopping them serves no purpose.
I would say that your poll showcases the pinacle of your ignorance to this subject. It's flat out neither of those choices. Snapshots do not create any sort of dependency - the obfuscation process might, but all major mods use a loader of some sort if they are to be compatible with other mods. This is a bytecode-level truth - you can't have two mods modify the same class, so you need forge to dynamically load the mods.
Let me reiterate - No major mod can be fully developed for a snapshot build; snapshot builds are a way to get a head start of some sort but you can't update code to it.
[rule]
We ARE trying to update. But there's a lot of steps, and it's nigh impossible to update instantly. 3 days is hardly enough time to fully update the deobfuscation tools, forge, and one's mod. And while as tools update mods update, we're not there yet.
[rule]
That said, bugfix updates after the release of a full update may cause issues, since the same problems with changing obfuscation may occur. In that sense, it may make sense to procrastinate on updating mods (and that's why mods were developed for 1.8 even when 1.8.7 was out). But it doesn't make sense to stop releasing bugfix updates. It's easier to just use earlier versions.
[rule]
Modders cannot develop against snapshots, for the reasons I've listed before. I tried, more to see if it's doable. A number of things prevented me:
And my mod is (arguably) simple. It doesn't add any blocks or items, and only holistically does it add packets. I am able to work with just MCP. Any complex mod, like the ones you describe, needs a loader - usually forge.
I challenge you - Write a mod that adds blocks, and do it against 16w02a. And 16w05a, 16w03a, 15w51a, etc. It's not possible to work against those. But, again, that doesn't make snapshots something that inhibits modding - read the rest of my text.
If you're willing to argue on a technical level and give programmatically sound solutions, then maybe it'll make sense to debate with you. Otherwise, I just see someone who does not understand what they are doing, trying to explain why people who do know what they are doing don't.
[rule]
Oh, one final note - snapshots aren't an exclusive concept to Minecraft. Many libraries have snapshot releases, intended for getting prepared and acquainted with upcoming changes, but with the upcoming changes not yet being finalized nor stable.
1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 World Downloader mod maintainer
Moderator on the mojang bugtracker, and also pretty deeply involved with the protocol documentation on wiki.vg.
Deobfuscation mappings can be converted, however making the code compile
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's a valid point, and reminds me of something else. Forge actually does partially deobfuscate the game at runtime - I don't remember when they started doing so but they are doing it to make mods (at least hopefully) compatible between versions. And it's a good technique, when it works.
Still I don't think it helps too much with snapshot releases - you still need to create the deobfuscation mapping, which takes a while and then the next snapshot comes out :/
And I just remembered another point (not targeted at you) - in a way, snapshots make mods come out faster and do the oposite of slowing down modding. Snapshot builds let bugs get fixed before the full release, making it come out faster and also helping to ensure that there won't be a second bugfix release. So removing snapshots is even more counterproductive.
1.8 / 1.9 / 1.10 / 1.11 / 1.12 / 1.13 / 1.14 / 1.15 / 1.16 World Downloader mod maintainer
Moderator on the mojang bugtracker, and also pretty deeply involved with the protocol documentation on wiki.vg.
No you don't.
I believe Forge does that through deobfuscating the game to Searge mappings.
So basing on the first post, you don't want snapshots so modders can update at once?
To a broken version?
That then, they'll have to re-update?
Can't you just WAIT?
Your whole point is that updating to each snapshot is hard and painful, but THAT'S NOT THE IDEA OF THE SNAPSHOTS.
The idea of the snapshots is to push out a stable(r) version of the game by when it's released, and to give players a feel for the new stuff.
Your idea is like getting a house built and living in it as IT IS BEING BUILT. NOO. You should go in when IT'S DONE BUILDING.