My problem is Minecraft Forge. Most of mods on here need Minecraft Forge installed too. So, why not just include it in the 1.6 update. Yes or no, should Forge be included?
Its jeb's game. Mods are add-ons to the game. There's no copyright on the mods (but there is on the game) So technically, Mojang owns all the mods and can add what they want with no worries.
Its jeb's game. Mods are add-ons to the game. There's no copyright on the mods (but there is on the game) So technically, Mojang owns all the mods and can add what they want with no worries.
This is patently not true. There is a copyright on mods, at least with the mod developers. And no, Mojang does not "own" any mod at all, although there is a general assumption that those who are modding the game do so with the understanding that Mojang can copy ideas used in the mods and incorporate that into the main game. Sort of a gentleman's agreement here with mod developers, even though it doesn't fit with copyright law and can't strictly be enforced in a courtroom.
The game is also Notch's to do with as he would, although Jeb is admittedly the main gatekeeper at the moment in terms of deciding what goes into Minecraft. That is also why Notch stepped out from development as he really put Jeb in a weird position for awhile where Notch was "working" for Jeb as the lead developer, but Notch could technically fire him at any time since Notch owned the company as a whole.
Ideally Mojang needs to come out with a plug-in developer's license that spells out exactly what a plug-in developer can and can't do... and offer a little more support beyond just the API (such as a plug-in shop like an app store). Definitely some authentication that the mod author who claims to have written the mod really is the guy who made it and some kind of reputation metric to show established mods and root out potential malware.
As for Forge being directly included in vanilla Minecraft, I seriously doubt that is going to happen and at Minecon as well as magazine interviews and other comments (including twitter as well as the forums here) they have definitely said that the API is going to be a clean-sheet design that won't be depend on pre-existing API libraries... including Bukkit I might add (in part because of copyright issues). It will be something very much like Forge though, and I hope that some of the better ideas in Forge are put into vanilla Minecraft.
I would love to see at the very least, in version 1.6 if not later, a basic plug-in loader even if all it does is just pull up a *.zip or *.jar file and just report the name of the plug-in and the author. The ability to add custom recipes (not even custom blocks) would be a bonus even if that is all the API would do right now.
My problem is Minecraft Forge. Most of mods on here need Minecraft Forge installed too. So, why not just include it in the 1.6 update. Yes or no, should Forge be included?
If Forge was added to the game, I would ragequit all future versions of the game. We want a Mod API- Forge does not come close to being an API. it's designed by amateur Modders that like to think they have an understanding of Java and API design, but everything they've learned they got from "Learn Java in 21 Days".
No, Jeb_ has already stolen enough ideas from the Minecraft Community.
Ideas cannot be stolen. IP laws protect tangible Intellectual Property, not 'ideas'.
The only things that were based on existing ideas directly that I recall are Pistons. (Horses don't count at all because the premise is simple and the implementations will be vastly different, just as was the case with wolves). Very few mods I've tried over time actually provide a cohesive whole. The only one I can think of off-hand is "Better Than Wolves".
No. Forge isn't Jeb's to use, and I'd rather Mojang continue developing for the better API.
the ToS are quite clear on this. Forge is just a mod; The ToS agreement regarding Modifications is that Mojang will not pursue any litigation against Modders as long as they adhere to specific rules; one of those is basically that they can use anything that is modded onto the original game. They have been very gracious and have asked mod authors before they attempt any vanilla addition that is based on a mod; Mostly because they want the ideas and experience that the Modder has on the issue. Usually they go with a completely different implementation.
heck, Eloraam (one of the creators of forge) was working with Jeb a fair bit a while ago.
I remember this, it was an interview a few years back; apparently one fabrication- by whom, is unknown- was that Jeb directly offered Eloraam a Job. This is particularly unlikely given that Jeb_ doesn't actually have direct hiring capacity; he can recommend offering somebody a Job, but I do not think he can just go offering them. Additionally, this is allegedly before they approached Bukkit; basically, somebody has decided that Eloraam was the "first choice".
However, I could not and cannot find any first-hand evidence from Mojang employees on this; All I can find are some old forum posts that say they learned from a "reliable source" that Eloraam was offered the Job. None of them are particularly encouraging as actually taking place. I found this. In particular:
[10:46:58] <Miner_Dave> jeb, hire eloraam already
[10:47:14] <jeb> Miner_Dave: i asked her, but she's stuck in US
Worth noting, is that, on IRC, you can assume any Nick you want. Nothing seems to indicate, clearly, that this is actually Jeb. I find it doubtful that he would be in the #RedPower Channel; particularly since he has since pleaded ignorance to the existence of several basic RedPower features.
Basically, I can find NOTHING that actually cites this; none of the interview content I can find regarding the addition of the Bukkit Team members to Mojang goes "oh, we did ask Eloraam first" In fact, I recall several mentions that the bukkit team was their first choice. Sounds more like Envy on the side of the Forge people trying to make themselves feel better by building themselves up with a reality distortion field; the only mentions of it I can find are on Pro-Forge Forums and sites. There is no actual evidence that leads me to conclude that the <jeb> IRC nick is in fact the real one.
Grumm works with the Forge community pretty closely. He even plays on their Forgecraft whitelisted server. They wont be simply adding Forge to Minecraft, the point of the API is to make something BETTER than Forge.
Rollback Post to RevisionRollBack
I use the FTB modpack, because it's fun, and extremely convenient.
My problem is Minecraft Forge. Most of mods on here need Minecraft Forge installed too. So, why not just include it in the 1.6 update. Yes or no, should Forge be included?
Sorry, guy... I think it may get a little hot in the reply section...
This is patently not true. There is a copyright on mods, at least with the mod developers.
This only protects the work from others. It doesn't protect them from Mojang because the existence of Mods and modding to begin with is only because Mojang allows it; it's a concession as part of their ToS; Modding is allowed, but we aren't going to tiptoe and avoid overlapping new functionality with existing Mods, is generally what they are going for. The legalese is a bit more upfront and basically states that the Copyright on derivative works- Something that can be controlled by the upstream- waives any possible copyright claim against the original authors.
And no, Mojang does not "own" any mod at all
Definitely Poor wording. The Modders definitely own their own work; however, they are limited by the upstream license. In much the same way as how you cannot take a GPL work, mod it, and then discard the GPL, so too must Mod Authors meet the ToS of Minecraft in how they operate; part of that ToS is that Mojang reserves the right to use their downstream.
Arguably, there are some big exceptions: First off, if the mod does not actually contain any Mojang code or is otherwise separated by an API- for example, Bukkit Plugins do not apply as something Mojang can blanket use- then your plugin/mod is safe. It's pretty close to impossible to make any non-trivial Forge Mod without modifying the core files, but if you can, then your Forge Mod is probably 'protected' from Mojang.
although there is a general assumption that those who are modding the game do so with the understanding that Mojang can copy ideas used in the mods and incorporate that into the main game. Sort of a gentleman's agreement here with mod developers, even though it doesn't fit with copyright law and can't strictly be enforced in a courtroom.
Both of these can and have been and in fact have judicial precedence set forth by the Electronic Frontier Foundations enforcements of GPL downstream requirements. one of the requirements of using GPL code in your own applications or programs is that whatever you put it into must also be GPL. In much the same way, anything that uses the Minecraft code must allow Mojang to do whatever they want with it. it's not "unfair" because Modders ought to understand what they are getting into to begin with. Thankfully, Mojang always asks first. My best analogy is that it's very much similar to how Weird Al works; under copyright law, he can make a parody of any song he wants, regardless of whether he has permission from the original artist. However, he always asks them first, simply out of courtesy but also as a 'warning' :P.
That is also why Notch stepped out from development as he really put Jeb in a weird position for awhile where Notch was "working" for Jeb as the lead developer, but Notch could technically fire him at any time since Notch owned the company as a whole.
Notch stopped working on Minecraft actively at the same time Jeb took on the lead developer role. Notch's contributions at that point were mostly explaining how something worked to Jeb or adding small bits of code where Jeb needed help. This happened Dec 2011, between the Release version (1.0.0) and 1.1. Before that they were collaborators and Notch was lead developer.
Ideally Mojang needs to come out with a plug-in developer's license that spells out exactly what a plug-in developer can and can't do...
As a side note, once the Plugin API is about, they will almost certainly have a Terms of Use for the API itself, which will probably flesh out the details.
such as a plug-in shop like an app store. Definitely some authentication that the mod author who claims to have written the mod really is the guy who made it and some kind of reputation metric to show established mods and root out potential malware.
Based on what they said at their Minecon Panel, this is their intention- in fact they touch on all of these points in the panel. What this means is that they are building far more than just a Plugin API- they are creating practically an entire service, and it will heavily involve most of the Mojang team. It's likely the Web-folks they have will have just as much work implementing it as those working on Minecraft itself.
It will be something very much like Forge though
I certainly hope not. Forge is the saddest excuse for an "API" I have ever used in any language in my entire programming career.
I would love to see at the very least, in version 1.6 if not later, a basic plug-in loader even if all it does is just pull up a *.zip or *.jar file and just report the name of the plug-in and the author.
Plugin "loaders" are not magic. They are ridiculously simple. The fact that those behind Mods/FML and so forth think it's some magic pixie programming speaks volumes about just how inexperienced they are. I wrote a class-loader almost by accident for a on-off forum solution in 2010, and I had never even programmed in Java for more than a minute before that, and I'm certainly not a wizard.
Given that- the question is, why isn't it added?
Because they need an API first. Plugin "Loaders" like this need to know what to look for; in the case of my one-off program, it looks for classes with a static main() method and calls all of them with a time limit. However a Plugin Loader- looks for either classes that derive from an API base class, or classes that implement an interface. Risagumi's Mod Loader uses "BaseMod"; FML uses some ridiculous method involving annotations that is about as well-designed as a Swedish End-Table. (This is partly why it's such garbage). Bukkit uses a 'JavaPlugin' base class.
The ability to add custom recipes (not even custom blocks) would be a bonus even if that is all the API would do right now.
They can't do this without causing more issues. It is a bad idea to release a partly finished API; because that means, by definition, it is going to change in the future, defeating the entire purpose of the API. For example, if they write the basic interface/class loader/reflection search logic and find implementations or derivations of their plugin class/interface, that means they will be starting with a very basic interface, or a basic Abstract class. Once it changes, all plugins will break. This is easier to deal with using abstract classes instead of interfaces, but then you have the problem of what if you add a Method to your abstract base class with the same name as something the plugin has already? fundamentally, doing it this way changes the API from a solid base into a house of cards; features are stapled on separately to avoid breaking existing code, and you end up with a bunch of legacy API classes and methods that you need to keep around for those mods that might have stopped being updated since.
Basically, until the Plugin API is finished, it shouldn't 'exist' at all (that is, in terms of snapshots).
Its jeb's game. Mods are add-ons to the game. There's no copyright on the mods (but there is on the game) So technically, Mojang owns all the mods and can add what they want with no worries.
There are often copyrights on the mods...
Rollback Post to RevisionRollBack
Quote from Fermat »
I have discovered a truly remarkable proof of this, which this margin is too small to contain.
[;/quote]
No. I'm just unable to understand the viewpoint of people that think such a terribly designed excuse for an API is something that should even be mentioned in a positive light here. That said, you can learn a lot about how to make a worthwhile Plugin API by looking at how Forge does it, and doing the opposite. For example, instead of using magical Java Annotations on fields and methods to indicate special methods in a class, one could do something totally insane like- I dunno- use the OO features built into the language for exactly that purpose. "gee, we want to allow plugins to have these methods, let's use annotations to magically mark those methods, with no outward documentation about the various annotations or the appropriate signatures thereof instead of using an abstract base class which is designed for exactly this purpose." Seems to be their strategy. It's certainly a... unique- strategy, sort of like driving backwards to work to avoid rear-ending somebody.
Mojang has been in contact with the developers of Bukkit and Forge and have great discussion with them in regards to the details of the projects, on what features need to exist and faults in the previous APIs that absolutely cannot exist in an official API (Dinnerbone and Grum have been the first to admit that they made plenty of mistakes in the development of Bukkit). While Forge absolutely will not be an official part of Minecraft ever, there has been communication with the team behind it in order to better understand more of the nuances of a well-developed API.
Forge is definitely a good API, but as an official one, it would be rubbish. It's not built to be an official API; it's been cobbled together over time to suite the needs of an ever-changing game. An official API needs to be a flat platform that can adapt with the game without turning into the jigsaw puzzle that is Forge today. Forge is built on top of the game engine, so it can never fully adapt to changes in it. An official API would roughly be a new interface with the engine and change as it changes, allowing a stable platform for development. That's what's needed, not just taking an API built on top of it all.
Because forge isn't anything near what a true plugin API can be. Forge goes in and sinks its hooks into most of the class files to expose functionality to mods, this is what we call "hacking" (not the bad kind, that is cracking). All of what Minecraft is still exists in those class files, but forge can override/replace/block sections of it, by messing with variables and functions to do whatever they want. This is a problem, all this add-on code is stapled in wherever it can be put, witch is a mess, and a nightmare to maintain.
What we need is a game designed completely for expandability. Basically you break it all down into base parts, and the lowest level stuff like the engine its self, the rendering engine, and the physics engine, are the base, each with certain perimeters that can be tweaked by API calls. Then on top you get the game engine that handles the basics of how the game run, on top of that are things like world gen and entity physics, and on that we have things like block properties and items, then we have high level functionality like crafting and smelting, and combat with health and speed and armor.
Each level has a section of API dedicated to it, and each level on top of it USES THAT API! That means even core game features are merely plugins! Worldgen? A plugin! Creepers? plugin. Redstone? Yep, plugin. That means not only can the core functionality be renovated without needing the whole game to update, it also means that plugins that do not have anything to do with the change are unaffected! And even those that do probably will not be, as long as the API layer is not changed, as all the methods they use will remain.
And each of the 'core modules' (the plugins that are part of the default distribution) can also have its own API layer, so that redstone can have plugins on top of it, and even 3rd party plugins can have an API layer, allowing for meta-plugins.
OR You can strip the game down, don't like creepers? Turn em off, never use redstone? Disable! Can't stand taiga? Get rid of it! And modders could even tear it down further and create almost completely different games within the same engine.
All without needing to modify any of the Mojang code, without having to edit the minecraft.jar, and in a way so user friendly that the mod users will never have to ask "der, how to install mod? how to get WinROR?".
ALSO: The launcher can hash check the jar, and all the plugin jars! If any of it is old-school modded (edited the class files) then servers can choose not to allow your client to join, thus only server approved plugins can be used, cheat clients and Xray (while still possible as plugins) can be blocked with near 100% accuracy. And you don't need to be kicked for having a Xray plugin installed, it will simply be disabled while connected to that server.
Like?
Who cares? It's not their property.
That is very true
Mostly moved on. May check back a few times a year.
Image Removed
This is patently not true. There is a copyright on mods, at least with the mod developers. And no, Mojang does not "own" any mod at all, although there is a general assumption that those who are modding the game do so with the understanding that Mojang can copy ideas used in the mods and incorporate that into the main game. Sort of a gentleman's agreement here with mod developers, even though it doesn't fit with copyright law and can't strictly be enforced in a courtroom.
The game is also Notch's to do with as he would, although Jeb is admittedly the main gatekeeper at the moment in terms of deciding what goes into Minecraft. That is also why Notch stepped out from development as he really put Jeb in a weird position for awhile where Notch was "working" for Jeb as the lead developer, but Notch could technically fire him at any time since Notch owned the company as a whole.
Ideally Mojang needs to come out with a plug-in developer's license that spells out exactly what a plug-in developer can and can't do... and offer a little more support beyond just the API (such as a plug-in shop like an app store). Definitely some authentication that the mod author who claims to have written the mod really is the guy who made it and some kind of reputation metric to show established mods and root out potential malware.
As for Forge being directly included in vanilla Minecraft, I seriously doubt that is going to happen and at Minecon as well as magazine interviews and other comments (including twitter as well as the forums here) they have definitely said that the API is going to be a clean-sheet design that won't be depend on pre-existing API libraries... including Bukkit I might add (in part because of copyright issues). It will be something very much like Forge though, and I hope that some of the better ideas in Forge are put into vanilla Minecraft.
I would love to see at the very least, in version 1.6 if not later, a basic plug-in loader even if all it does is just pull up a *.zip or *.jar file and just report the name of the plug-in and the author. The ability to add custom recipes (not even custom blocks) would be a bonus even if that is all the API would do right now.
Version 2.1 now updated for MC 1.6.2
If Forge was added to the game, I would ragequit all future versions of the game. We want a Mod API- Forge does not come close to being an API. it's designed by amateur Modders that like to think they have an understanding of Java and API design, but everything they've learned they got from "Learn Java in 21 Days".
Ideas cannot be stolen. IP laws protect tangible Intellectual Property, not 'ideas'.
The only things that were based on existing ideas directly that I recall are Pistons. (Horses don't count at all because the premise is simple and the implementations will be vastly different, just as was the case with wolves). Very few mods I've tried over time actually provide a cohesive whole. The only one I can think of off-hand is "Better Than Wolves".
the ToS are quite clear on this. Forge is just a mod; The ToS agreement regarding Modifications is that Mojang will not pursue any litigation against Modders as long as they adhere to specific rules; one of those is basically that they can use anything that is modded onto the original game. They have been very gracious and have asked mod authors before they attempt any vanilla addition that is based on a mod; Mostly because they want the ideas and experience that the Modder has on the issue. Usually they go with a completely different implementation.
Forge is not a Mod API, it's a terrible excuse for a Modding platform.
I remember this, it was an interview a few years back; apparently one fabrication- by whom, is unknown- was that Jeb directly offered Eloraam a Job. This is particularly unlikely given that Jeb_ doesn't actually have direct hiring capacity; he can recommend offering somebody a Job, but I do not think he can just go offering them. Additionally, this is allegedly before they approached Bukkit; basically, somebody has decided that Eloraam was the "first choice".
However, I could not and cannot find any first-hand evidence from Mojang employees on this; All I can find are some old forum posts that say they learned from a "reliable source" that Eloraam was offered the Job. None of them are particularly encouraging as actually taking place. I found this. In particular:
Worth noting, is that, on IRC, you can assume any Nick you want. Nothing seems to indicate, clearly, that this is actually Jeb. I find it doubtful that he would be in the #RedPower Channel; particularly since he has since pleaded ignorance to the existence of several basic RedPower features.
Basically, I can find NOTHING that actually cites this; none of the interview content I can find regarding the addition of the Bukkit Team members to Mojang goes "oh, we did ask Eloraam first" In fact, I recall several mentions that the bukkit team was their first choice. Sounds more like Envy on the side of the Forge people trying to make themselves feel better by building themselves up with a reality distortion field; the only mentions of it I can find are on Pro-Forge Forums and sites. There is no actual evidence that leads me to conclude that the <jeb> IRC nick is in fact the real one.
Are you mad at Forge or something?
This only protects the work from others. It doesn't protect them from Mojang because the existence of Mods and modding to begin with is only because Mojang allows it; it's a concession as part of their ToS; Modding is allowed, but we aren't going to tiptoe and avoid overlapping new functionality with existing Mods, is generally what they are going for. The legalese is a bit more upfront and basically states that the Copyright on derivative works- Something that can be controlled by the upstream- waives any possible copyright claim against the original authors.
Definitely Poor wording. The Modders definitely own their own work; however, they are limited by the upstream license. In much the same way as how you cannot take a GPL work, mod it, and then discard the GPL, so too must Mod Authors meet the ToS of Minecraft in how they operate; part of that ToS is that Mojang reserves the right to use their downstream.
Arguably, there are some big exceptions: First off, if the mod does not actually contain any Mojang code or is otherwise separated by an API- for example, Bukkit Plugins do not apply as something Mojang can blanket use- then your plugin/mod is safe. It's pretty close to impossible to make any non-trivial Forge Mod without modifying the core files, but if you can, then your Forge Mod is probably 'protected' from Mojang.
Both of these can and have been and in fact have judicial precedence set forth by the Electronic Frontier Foundations enforcements of GPL downstream requirements. one of the requirements of using GPL code in your own applications or programs is that whatever you put it into must also be GPL. In much the same way, anything that uses the Minecraft code must allow Mojang to do whatever they want with it. it's not "unfair" because Modders ought to understand what they are getting into to begin with. Thankfully, Mojang always asks first. My best analogy is that it's very much similar to how Weird Al works; under copyright law, he can make a parody of any song he wants, regardless of whether he has permission from the original artist. However, he always asks them first, simply out of courtesy but also as a 'warning' :P.
Notch stopped working on Minecraft actively at the same time Jeb took on the lead developer role. Notch's contributions at that point were mostly explaining how something worked to Jeb or adding small bits of code where Jeb needed help. This happened Dec 2011, between the Release version (1.0.0) and 1.1. Before that they were collaborators and Notch was lead developer.
https://minecraft.net/brand
As a side note, once the Plugin API is about, they will almost certainly have a Terms of Use for the API itself, which will probably flesh out the details.
Based on what they said at their Minecon Panel, this is their intention- in fact they touch on all of these points in the panel. What this means is that they are building far more than just a Plugin API- they are creating practically an entire service, and it will heavily involve most of the Mojang team. It's likely the Web-folks they have will have just as much work implementing it as those working on Minecraft itself.
I certainly hope not. Forge is the saddest excuse for an "API" I have ever used in any language in my entire programming career.
Plugin "loaders" are not magic. They are ridiculously simple. The fact that those behind Mods/FML and so forth think it's some magic pixie programming speaks volumes about just how inexperienced they are. I wrote a class-loader almost by accident for a on-off forum solution in 2010, and I had never even programmed in Java for more than a minute before that, and I'm certainly not a wizard.
Given that- the question is, why isn't it added?
Because they need an API first. Plugin "Loaders" like this need to know what to look for; in the case of my one-off program, it looks for classes with a static main() method and calls all of them with a time limit. However a Plugin Loader- looks for either classes that derive from an API base class, or classes that implement an interface. Risagumi's Mod Loader uses "BaseMod"; FML uses some ridiculous method involving annotations that is about as well-designed as a Swedish End-Table. (This is partly why it's such garbage). Bukkit uses a 'JavaPlugin' base class.
They can't do this without causing more issues. It is a bad idea to release a partly finished API; because that means, by definition, it is going to change in the future, defeating the entire purpose of the API. For example, if they write the basic interface/class loader/reflection search logic and find implementations or derivations of their plugin class/interface, that means they will be starting with a very basic interface, or a basic Abstract class. Once it changes, all plugins will break. This is easier to deal with using abstract classes instead of interfaces, but then you have the problem of what if you add a Method to your abstract base class with the same name as something the plugin has already? fundamentally, doing it this way changes the API from a solid base into a house of cards; features are stapled on separately to avoid breaking existing code, and you end up with a bunch of legacy API classes and methods that you need to keep around for those mods that might have stopped being updated since.
Basically, until the Plugin API is finished, it shouldn't 'exist' at all (that is, in terms of snapshots).
There are often copyrights on the mods...
No. I'm just unable to understand the viewpoint of people that think such a terribly designed excuse for an API is something that should even be mentioned in a positive light here. That said, you can learn a lot about how to make a worthwhile Plugin API by looking at how Forge does it, and doing the opposite. For example, instead of using magical Java Annotations on fields and methods to indicate special methods in a class, one could do something totally insane like- I dunno- use the OO features built into the language for exactly that purpose. "gee, we want to allow plugins to have these methods, let's use annotations to magically mark those methods, with no outward documentation about the various annotations or the appropriate signatures thereof instead of using an abstract base class which is designed for exactly this purpose." Seems to be their strategy. It's certainly a... unique- strategy, sort of like driving backwards to work to avoid rear-ending somebody.
Forge is definitely a good API, but as an official one, it would be rubbish. It's not built to be an official API; it's been cobbled together over time to suite the needs of an ever-changing game. An official API needs to be a flat platform that can adapt with the game without turning into the jigsaw puzzle that is Forge today. Forge is built on top of the game engine, so it can never fully adapt to changes in it. An official API would roughly be a new interface with the engine and change as it changes, allowing a stable platform for development. That's what's needed, not just taking an API built on top of it all.
Let me just go ahead a quote myself (original)