Mod loaders like forge are all well and good, they do a fine job. But for a game as big as minecraft I would expect a system by which mods can be easily integrated with the game. Like steam has for some of their games. A minecraft workshop if you will. One unified official place where all mods go and things like forge are no longer needed. It might add a bit more chaos at first but the benefits to the modding community would be great.
Also less version compatibility problems with mods. If other games can update without losing compatibility with all mods that were made for previous versions, why can't minecraft?
Mod loaders like forge are all well and good, they do a fine job. But for a game as big as minecraft I would expect a system by which mods can be easily integrated with the game. Like steam has for some of their games. A minecraft workshop if you will. One unified official place where all mods go and things like forge are no longer needed. It might add a bit more chaos at first but the benefits to the modding community would be great. Not really, most mods are on CurseForge now anyway. And what's wrong with Forge? The installer is simple and from there it's a matter of putting the .jar files in /mods and launching the game. Biome IDs and the like can be a problem sometimes but Forge 1.9 does them automatically now.
Also less version compatibility problems with mods. If other games can update without losing compatibility with all mods that were made for previous versions, why can't minecraft? Other games usually limit what modders can do to achieve this, Forge allows modders to do almost anything.
It would also get rid of the need to install seperate cores in addition to the mod you want. I'm afraid not, those are utilities and libraries which make mod development much easier. While some of their functionality could be integrated into an API, some of it wouldn't be used enough to justify it's inclusion.
Rollback Post to RevisionRollBack
Please don't PM me asking for help, I will just redirect you to the appropriate forum, where there are others who are far more skilled than me.
"And what's wrong with Forge?"
Nothing is, its fine, but I think it'd be a nice feature to have what many other games are doing where there are in game links to mods and they automatically download and apply, no need to figure out where to put the mods or anything. I know many people who would be into mods but have too short attention spans to figure out how to type %appdata% into run. Also I've found that I can't disable mods via the forge interface, I have to physically remove them from the mods folder.
"Other games usually limit what modders can do to achieve this, Forge allows modders to do almost anything." But like, looking at some of the changelogs I don't see anything that seems like it would conflict with previous mods. I'm no programmer but shouldn't it be possible as long as there's nothing added or changed that the mod depends on?
Mod loaders like forge are all well and good, they do a fine job. But for a game as big as minecraft I would expect a system by which mods can be easily integrated with the game. Like steam has for some of their games. A minecraft workshop if you will. One unified official place where all mods go and things like forge are no longer needed. It might add a bit more chaos at first but the benefits to the modding community would be great.
Also less version compatibility problems with mods. If other games can update without losing compatibility with all mods that were made for previous versions, why can't minecraft?
Firstly, keep in mind Mojang currently does not officially support modding (though they let it happen, they have a weird stance on it).
Secondly, what you're describing sounds more like a mod manager rather than an API. It doesn't matter whether or not you can download mods from within the launcher like the Steam Workshop, the game still needs a way to load said mods into the environment and let them do their thing, which is where an API comes in.
Version compatibility is a tough thing, as you often have to abstract the functions that mods have access to so much that updates don't ever affect the functions that mods can use. This inherently limits what mods can do, as you're anchored down to what the API gives you to work with, and there's no way to cleanly do what it doesn't allow you to do.
"And what's wrong with Forge?"
Nothing is, its fine, but I think it'd be a nice feature to have what many other games are doing where there are in game links to mods and they automatically download and apply, no need to figure out where to put the mods or anything. I know many people who would be into mods but have too short attention spans to figure out how to type %appdata% into run. Also I've found that I can't disable mods via the forge interface, I have to physically remove them from the mods folder. This is where other launchers come into play, you can do this all from ATLauncher or MultiMC from an interface.
"Other games usually limit what modders can do to achieve this, Forge allows modders to do almost anything." But like, looking at some of the changelogs I don't see anything that seems like it would conflict with previous mods. I'm no programmer but shouldn't it be possible as long as there's nothing added or changed that the mod depends on? Except there is things being added or changed that mods rely on.
All Forge mods sit directly on top of the game's code. To add a block into the game, you create a new class and extend the "Block" class. This is the very same method that every block in vanilla Minecraft uses, every single block Mojang has added extends the exact same "Block" class that you have. Now if Mojang were to move this "Block" class to a new folder in an update, but you haven't told your own block classes where to find the new copy (you haven't updated the path of the "Block" class), crash, because you're referencing a non-existent class which isn't allowed. Furthermore, if you were to call "World#setBlock(int x, int y, int z, Block block)" under 1.7.10, then someone tries to run your 1.7.10 mod in 1.8, crash, as "World#setBlock(int x, int y, int z, Block block)" has been changed to "World#setBlock(BlockPos pos, Block block)": the method has changed, so you're now attempting to call a method that doesn't exist, which isn't allowed, hence the game crashes. Even outside of code changes, Mojang does something called obfuscation, which is basically a technique used to protect your code by renaming every object to a random but unique new name, hence making things much more confusing for anyone trying to read your code. Within unobfuscated code, the code we work in when making mods, "World" is called "World", but under compiled 1.7.10 it could be called "aa", under compiled 1.8 it could be called "gs", under compiled 1.9 it could be called "yk". And it doesn't stop there, methods inside these classes are also obfuscated, so under 1.7.10 "World#setBlock()" could be "ow", but under 1.8 it could be "qt". Each update Mojang changes the obfuscation mappings, everything is renamed to an entirely random name. Your mod is made for 1.7.10, and "World" is "aa". You try to load it in 1.8, "World" is now called "gs", but your mod is still referencing "aa", which could be some other class. You try to call a method in "World", say "World#setBlock()" again. Now, not only do you have the difference in method parameters causing problems, but you're trying to call "aa#ow(x, y, z, Blocks.stone)" or whatever, which uses the 1.7.10 mappings, but you're trying to run it under 1.8, so "aa" could really be "Minecraft" and "ow" could really be "getMinecraft()": firstly, these two are not the class and method you wanted, obviously, and secondly, you're trying to pass arguments to a method which doesn't take arguments, it's basically the same thing as before, sooo, uh oh, crash, for 2 different reasons. And to make matters work, "ow" might not even exist in whatever class you're accidentally referencing, "aa" could really be "EntityCreeper" which doesn't have an "ow" method: once again, referencing something that doesn't exist, crash.
No matter what, mods are always broken during updates. The only way around this would be to not let mods talk to and reference the base code of the game, which severely limits what they can do. The only reason why you have mods like Thaumcraft, Buildcraft, etc which do things so wildly different to what Minecraft itself offers is because they not only have direct access to use the same code the base game itself uses, but they also have the ability to rewrite the code of the game indirectly by injecting custom code when Java is reading each class and loading each class into memory.
I see, very helpful I always wondered why so many of the files seemed to have random names like that in... many things really. It also explains why a mod that hasn't changed at all can take so long to get updated after an update. One more question though, why in the world does mojang obfuscate the code? It seems like people have no problem accessing it for extensive mods like thaumcraft so really what's the purpose? sounds almost like they are trying to make life harder on modders and mod creators.
I see, very helpful I always wondered why so many of the files seemed to have random names like that in... many things really. It also explains why a mod that hasn't changed at all can take so long to get updated after an update. One more question though, why in the world does mojang obfuscate the code? It seems like people have no problem accessing it for extensive mods like thaumcraft so really what's the purpose? sounds almost like they are trying to make life harder on modders and mod creators.
The intent is to slow down crackers to avoid exploits leaking out as quickly, gives Mojang time to patch out obvious exploits before crackers get an understanding of the internals of the game. As well as make the internals more secure through the same reasoning. But, you did highlight why Mojang seems to have a weird stance on modding. Even though the obfuscation is in place to prevent modding of the game to develop cracks, they let the modding community openly develop de-obfuscation mappings, and have even recruited members of the community (Searge, the guy behind MCP, basically the grandfather of modded Minecraft as we know it).
The way that mods deobfuscate the game is typically the game's code, once decompiled (which is a pain in and of itself), the source goes through a number of steps: a script walks through the source code and renames objects to "SRG names", these are random but more discernible names like "func_11041_a" which are mapped to the obfuscated names ("aa" -> "func_04190_g", "ge" -> "field_21404_t", etc). While still random and hard to work with, you can more easily go to the actual map itself (it's just a spreadsheet, able to be opened in Excel) and look at what each one does as there's a short description of each entry. Then, the script goes one step further and renames objects to "human readable names". These are the final names, so "World", "Block", "Item", etc. To my knowledge, only objects which mods frequently access are given proper names, while others are just left as SRG names. For instance, often at times when making say an inventory container, there'll be multiple methods that roughly do the same thing, just with different parameters. The one that you'll most frequently use will be given a proper name, but the others will be left as SRG names.
Then, once it comes time to release your mod, the process is basically reverse, source code is converted back to obfuscated names that match the version you're developing for, and your mod is recompiled and packaged in a single .jar file ready for distribution.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I give this support even though i am very sure it will never be implemented. I hate forge a lot because it always crashes my MC and yes i used forge versions.
Most mods come in an all in one package, utility, library and mod all in one single jar or zip. All mods should be like this, an all in one package. Mods with external utils/libraries show that the author's lazy and down't put that much effort into the mod.
I would support this but something like this is in the works. Its not for the pc edition though. A pocket edition dev said they would like an unified version of minecraft. That version of minecraft would be pocket. I have a strong feeling that with this other thing he said about phasing out the pc edition and releasing the pocket edition everywhere else for crossplay that they will eventually stop releasing mod breaking updates and continue on to the new minecraft. Then mods could easily take over the old abandoned minecraft pc so there will be no hassle to update mods.
I bet since they may not have supported modding but allowed it they have seen what the modders do. I bet they have seen people taking awhile to update to the latest version or just quitting on the latest minecraft. I know that they are allowing mod support in the next update to pocket edition and this would probably mean exactly what you are saying here in this post. There is not forge or bukkit on pocket edition so the opportunity is wide open. They don't have this opportunity on the pc edition.
I would support this if this edition of minecraft was going to last but I see no point now since they are saying to slowly phase out minecraft pc. Updates come slower now and pocket edition has had many big updates about as big as big main updates we get to minecraft pc. Pocket edition is catching up way faster then the pc edition is releasing updates. Mods have time to update because of the large gaps but soon I bet updates will get smaller and pocket edition will have the exclusives over the pc edition. Easier for modders to update and soon they will just stop. Mods update and people play them. pc edition has become the modding edition while the pocket edition gets its fair share of mods. Pc minecraft dies down and as pocket edition is now on Windows 10 they should be releasing it for more computers soon. Minecraft lives on better then before while some people stay on the pc edition maybe even playing new minecraft because it will get its mods.
I would support this but something like this is in the works. Its not for the pc edition though. A pocket edition dev said they would like an unified version of minecraft. That version of minecraft would be pocket. I have a strong feeling that with this other thing he said about phasing out the pc edition and releasing the pocket edition everywhere else for crossplay that they will eventually stop releasing mod breaking updates and continue on to the new minecraft. Then mods could easily take over the old abandoned minecraft pc so there will be no hassle to update mods.
I bet since they may not have supported modding but allowed it they have seen what the modders do. I bet they have seen people taking awhile to update to the latest version or just quitting on the latest minecraft. I know that they are allowing mod support in the next update to pocket edition and this would probably mean exactly what you are saying here in this post. There is not forge or bukkit on pocket edition so the opportunity is wide open. They don't have this opportunity on the pc edition.
I would support this if this edition of minecraft was going to last but I see no point now since they are saying to slowly phase out minecraft pc. Updates come slower now and pocket edition has had many big updates about as big as big main updates we get to minecraft pc. Pocket edition is catching up way faster then the pc edition is releasing updates. Mods have time to update because of the large gaps but soon I bet updates will get smaller and pocket edition will have the exclusives over the pc edition. Easier for modders to update and soon they will just stop. Mods update and people play them. pc edition has become the modding edition while the pocket edition gets its fair share of mods. Pc minecraft dies down and as pocket edition is now on Windows 10 they should be releasing it for more computers soon. Minecraft lives on better then before while some people stay on the pc edition maybe even playing new minecraft because it will get its mods.
Pocket Edition won't ever "take over" as it's constantly held down by the hardware that mobile devices contain. Why do you think the Windows 10 edition isn't as popular as Mojang hoped it would be with the PC community? Because it's a straight port of PE, which PE is not designed to be played on PCs.
A unified game won't ever happen as well, maybe cross-platform capability to an extent, but a unified game that works on all platforms plainly won't work as each platform has huge differences to every other platform, and each of these differences plays into how you manage and develop applications, meaning you'll always be limited by the lowest link in the chain. A unified game will have to cater to the lower performance of mobiles, which means the PC version of the game, and console versions, will be severely limited (otherwise it'll be incompatible with the mobile version and hence won't be "unified"), as well as the closed-system aspects that plague consoles, meaning modding isn't a thing anymore.
Also, where is any evidence stating that they're "phasing out" the PC edition? They simply cannot as it is the edition keeping the game alive. Windows 10 edition isn't a viable option as, firstly it's a direct port of PE with the issues PE has, and secondly it's only for Windows 10, so what happens with OSX and Linux users? And on top of that modding is what's keeping the game alive currently, Mojang's even indirectly admitting to this by catering to the modding community (and in this context modding basically means any deviations from the vanilla game, whether it be a slightly modded game, a heavily modded game, a server with custom plugins that introduce game modes and such, etc).
Things aren't as easy as you think they are, PE won't take over, nor will Windows 10, without major changes, and unfortunately these changes will also render this future edition based on PE to be not supported by mobile and likely consoles due to it just plainly not working on those platforms. Hence a "unified edition" won't become a thing.
Most mods come in an all in one package, utility, library and mod all in one single jar or zip. All mods should be like this, an all in one package. Mods with external utils/libraries show that the author's lazy and down't put that much effort into the mod.
No, it cuts down on bulk and reduces conflicts. If you have Thaumcraft installed and 3 addons for Thaumcraft also installed, Thaumcraft has it's API internally, and the three mods incorrectly package the API accidentally rather than referencing it within the IDE. So each addon has the API also stored internally. Whatever addon is loaded last gets the worm, so to speak, so whatever addon is loaded last, that's what API instance is loaded. If that addon happens to have the API for an older version, it can cause conflicts as both Thaumcraft and addons expect there to be a newer version of the API installed and hence call newer methods within the API, but they don't exist, so crash. On top of that, it reduces the file size as it's less code to store within the file, on something as small as an API this isn't much, but for every single library, the difference can be in 10's of megabytes in size, maybe hundreds, where those libraries could be already installed within your OS installation (say for the DirectX DLL files, dxd9, dxd10 and dxd11 .dll are all stored within your DirectX installation in Program Files, think of the bloat if every game you owned included every single binary file for DX).
Coding in terms of modules and libraries is good practice as it means your code only has to be updated once and that update will trickle down to any and all code that uses the library automatically without touching that code. If you say otherwise, then you honestly shouldn't be programming.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Mod loaders like forge are all well and good, they do a fine job. But for a game as big as minecraft I would expect a system by which mods can be easily integrated with the game. Like steam has for some of their games. A minecraft workshop if you will. One unified official place where all mods go and things like forge are no longer needed. It might add a bit more chaos at first but the benefits to the modding community would be great.
Also less version compatibility problems with mods. If other games can update without losing compatibility with all mods that were made for previous versions, why can't minecraft?
I would like this as well. Maybe send this suggestion to the Minecraft subreddit. Support.
*cough* Modding api *cough*
It would also get rid of the need to install seperate cores in addition to the mod you want.
Please don't PM me asking for help, I will just redirect you to the appropriate forum, where there are others who are far more skilled than me.
This is not the signature you are looking for.
Banners and such things
Leviathan143 >>
"And what's wrong with Forge?"
Nothing is, its fine, but I think it'd be a nice feature to have what many other games are doing where there are in game links to mods and they automatically download and apply, no need to figure out where to put the mods or anything. I know many people who would be into mods but have too short attention spans to figure out how to type %appdata% into run. Also I've found that I can't disable mods via the forge interface, I have to physically remove them from the mods folder.
"Other games usually limit what modders can do to achieve this, Forge allows modders to do almost anything." But like, looking at some of the changelogs I don't see anything that seems like it would conflict with previous mods. I'm no programmer but shouldn't it be possible as long as there's nothing added or changed that the mod depends on?
Firstly, keep in mind Mojang currently does not officially support modding (though they let it happen, they have a weird stance on it).
Secondly, what you're describing sounds more like a mod manager rather than an API. It doesn't matter whether or not you can download mods from within the launcher like the Steam Workshop, the game still needs a way to load said mods into the environment and let them do their thing, which is where an API comes in.
Version compatibility is a tough thing, as you often have to abstract the functions that mods have access to so much that updates don't ever affect the functions that mods can use. This inherently limits what mods can do, as you're anchored down to what the API gives you to work with, and there's no way to cleanly do what it doesn't allow you to do.
All Forge mods sit directly on top of the game's code. To add a block into the game, you create a new class and extend the "Block" class. This is the very same method that every block in vanilla Minecraft uses, every single block Mojang has added extends the exact same "Block" class that you have. Now if Mojang were to move this "Block" class to a new folder in an update, but you haven't told your own block classes where to find the new copy (you haven't updated the path of the "Block" class), crash, because you're referencing a non-existent class which isn't allowed. Furthermore, if you were to call "World#setBlock(int x, int y, int z, Block block)" under 1.7.10, then someone tries to run your 1.7.10 mod in 1.8, crash, as "World#setBlock(int x, int y, int z, Block block)" has been changed to "World#setBlock(BlockPos pos, Block block)": the method has changed, so you're now attempting to call a method that doesn't exist, which isn't allowed, hence the game crashes. Even outside of code changes, Mojang does something called obfuscation, which is basically a technique used to protect your code by renaming every object to a random but unique new name, hence making things much more confusing for anyone trying to read your code. Within unobfuscated code, the code we work in when making mods, "World" is called "World", but under compiled 1.7.10 it could be called "aa", under compiled 1.8 it could be called "gs", under compiled 1.9 it could be called "yk". And it doesn't stop there, methods inside these classes are also obfuscated, so under 1.7.10 "World#setBlock()" could be "ow", but under 1.8 it could be "qt". Each update Mojang changes the obfuscation mappings, everything is renamed to an entirely random name. Your mod is made for 1.7.10, and "World" is "aa". You try to load it in 1.8, "World" is now called "gs", but your mod is still referencing "aa", which could be some other class. You try to call a method in "World", say "World#setBlock()" again. Now, not only do you have the difference in method parameters causing problems, but you're trying to call "aa#ow(x, y, z, Blocks.stone)" or whatever, which uses the 1.7.10 mappings, but you're trying to run it under 1.8, so "aa" could really be "Minecraft" and "ow" could really be "getMinecraft()": firstly, these two are not the class and method you wanted, obviously, and secondly, you're trying to pass arguments to a method which doesn't take arguments, it's basically the same thing as before, sooo, uh oh, crash, for 2 different reasons. And to make matters work, "ow" might not even exist in whatever class you're accidentally referencing, "aa" could really be "EntityCreeper" which doesn't have an "ow" method: once again, referencing something that doesn't exist, crash.
No matter what, mods are always broken during updates. The only way around this would be to not let mods talk to and reference the base code of the game, which severely limits what they can do. The only reason why you have mods like Thaumcraft, Buildcraft, etc which do things so wildly different to what Minecraft itself offers is because they not only have direct access to use the same code the base game itself uses, but they also have the ability to rewrite the code of the game indirectly by injecting custom code when Java is reading each class and loading each class into memory.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I see, very helpful I always wondered why so many of the files seemed to have random names like that in... many things really. It also explains why a mod that hasn't changed at all can take so long to get updated after an update. One more question though, why in the world does mojang obfuscate the code? It seems like people have no problem accessing it for extensive mods like thaumcraft so really what's the purpose? sounds almost like they are trying to make life harder on modders and mod creators.
The intent is to slow down crackers to avoid exploits leaking out as quickly, gives Mojang time to patch out obvious exploits before crackers get an understanding of the internals of the game. As well as make the internals more secure through the same reasoning. But, you did highlight why Mojang seems to have a weird stance on modding. Even though the obfuscation is in place to prevent modding of the game to develop cracks, they let the modding community openly develop de-obfuscation mappings, and have even recruited members of the community (Searge, the guy behind MCP, basically the grandfather of modded Minecraft as we know it).
The way that mods deobfuscate the game is typically the game's code, once decompiled (which is a pain in and of itself), the source goes through a number of steps: a script walks through the source code and renames objects to "SRG names", these are random but more discernible names like "func_11041_a" which are mapped to the obfuscated names ("aa" -> "func_04190_g", "ge" -> "field_21404_t", etc). While still random and hard to work with, you can more easily go to the actual map itself (it's just a spreadsheet, able to be opened in Excel) and look at what each one does as there's a short description of each entry. Then, the script goes one step further and renames objects to "human readable names". These are the final names, so "World", "Block", "Item", etc. To my knowledge, only objects which mods frequently access are given proper names, while others are just left as SRG names. For instance, often at times when making say an inventory container, there'll be multiple methods that roughly do the same thing, just with different parameters. The one that you'll most frequently use will be given a proper name, but the others will be left as SRG names.
Then, once it comes time to release your mod, the process is basically reverse, source code is converted back to obfuscated names that match the version you're developing for, and your mod is recompiled and packaged in a single .jar file ready for distribution.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
It's amazing anyone mods at all.
Okay new idea. for thread suggestion. DE OBFUSCATE CODE xD
I give this support even though i am very sure it will never be implemented. I hate forge a lot because it always crashes my MC and yes i used forge versions.
Most mods come in an all in one package, utility, library and mod all in one single jar or zip. All mods should be like this, an all in one package. Mods with external utils/libraries show that the author's lazy and down't put that much effort into the mod.
I would support this but something like this is in the works. Its not for the pc edition though. A pocket edition dev said they would like an unified version of minecraft. That version of minecraft would be pocket. I have a strong feeling that with this other thing he said about phasing out the pc edition and releasing the pocket edition everywhere else for crossplay that they will eventually stop releasing mod breaking updates and continue on to the new minecraft. Then mods could easily take over the old abandoned minecraft pc so there will be no hassle to update mods.
I bet since they may not have supported modding but allowed it they have seen what the modders do. I bet they have seen people taking awhile to update to the latest version or just quitting on the latest minecraft. I know that they are allowing mod support in the next update to pocket edition and this would probably mean exactly what you are saying here in this post. There is not forge or bukkit on pocket edition so the opportunity is wide open. They don't have this opportunity on the pc edition.
I would support this if this edition of minecraft was going to last but I see no point now since they are saying to slowly phase out minecraft pc. Updates come slower now and pocket edition has had many big updates about as big as big main updates we get to minecraft pc. Pocket edition is catching up way faster then the pc edition is releasing updates. Mods have time to update because of the large gaps but soon I bet updates will get smaller and pocket edition will have the exclusives over the pc edition. Easier for modders to update and soon they will just stop. Mods update and people play them. pc edition has become the modding edition while the pocket edition gets its fair share of mods. Pc minecraft dies down and as pocket edition is now on Windows 10 they should be releasing it for more computers soon. Minecraft lives on better then before while some people stay on the pc edition maybe even playing new minecraft because it will get its mods.
Pocket Edition won't ever "take over" as it's constantly held down by the hardware that mobile devices contain. Why do you think the Windows 10 edition isn't as popular as Mojang hoped it would be with the PC community? Because it's a straight port of PE, which PE is not designed to be played on PCs.
A unified game won't ever happen as well, maybe cross-platform capability to an extent, but a unified game that works on all platforms plainly won't work as each platform has huge differences to every other platform, and each of these differences plays into how you manage and develop applications, meaning you'll always be limited by the lowest link in the chain. A unified game will have to cater to the lower performance of mobiles, which means the PC version of the game, and console versions, will be severely limited (otherwise it'll be incompatible with the mobile version and hence won't be "unified"), as well as the closed-system aspects that plague consoles, meaning modding isn't a thing anymore.
Also, where is any evidence stating that they're "phasing out" the PC edition? They simply cannot as it is the edition keeping the game alive. Windows 10 edition isn't a viable option as, firstly it's a direct port of PE with the issues PE has, and secondly it's only for Windows 10, so what happens with OSX and Linux users? And on top of that modding is what's keeping the game alive currently, Mojang's even indirectly admitting to this by catering to the modding community (and in this context modding basically means any deviations from the vanilla game, whether it be a slightly modded game, a heavily modded game, a server with custom plugins that introduce game modes and such, etc).
Things aren't as easy as you think they are, PE won't take over, nor will Windows 10, without major changes, and unfortunately these changes will also render this future edition based on PE to be not supported by mobile and likely consoles due to it just plainly not working on those platforms. Hence a "unified edition" won't become a thing.
No, it cuts down on bulk and reduces conflicts. If you have Thaumcraft installed and 3 addons for Thaumcraft also installed, Thaumcraft has it's API internally, and the three mods incorrectly package the API accidentally rather than referencing it within the IDE. So each addon has the API also stored internally. Whatever addon is loaded last gets the worm, so to speak, so whatever addon is loaded last, that's what API instance is loaded. If that addon happens to have the API for an older version, it can cause conflicts as both Thaumcraft and addons expect there to be a newer version of the API installed and hence call newer methods within the API, but they don't exist, so crash. On top of that, it reduces the file size as it's less code to store within the file, on something as small as an API this isn't much, but for every single library, the difference can be in 10's of megabytes in size, maybe hundreds, where those libraries could be already installed within your OS installation (say for the DirectX DLL files, dxd9, dxd10 and dxd11 .dll are all stored within your DirectX installation in Program Files, think of the bloat if every game you owned included every single binary file for DX).
Coding in terms of modules and libraries is good practice as it means your code only has to be updated once and that update will trickle down to any and all code that uses the library automatically without touching that code. If you say otherwise, then you honestly shouldn't be programming.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!