One suggestion I would like to make is a little of what @madcrazydrama said, pull modders together but how about modders that add the same kind of things to minecraft and have them together to iron out incompatibilities because that is what I believe is very important, but besides that good f**king job mojang
Thoughts and feedback on this process are greatly appreciated. We'll be constantly revising this system based on the lessons we learn from it being used and your input will help us with that immensely.
I would be excited if you could put in a system like the IETF system for RFCs. I have to presume that is what you intend, but it should be something where the MAPs are collaboratively written and vetted from within the community, where the individual MAP gets extensive review by all interested parties and that some sort of community system is established for writing these documents.
To me, it seems almost a perfect system for having a wiki to develop these kind of MAPs though, where active development of the MAP would have the threshold for editing the document to be rather low in terms of technical barrier to contribute ideas towards a specific MAP. Discussions could go on (and perhaps even rage) between various developers over the best way to develop the specific extension of the API. After it has gone through that development process, some sort of community vetting process is then established which has the mod development community giving thumbs up or down on the proposal (not necessarily voting for popularity, but evaluating the need and technical merits of the proposal to see if it passes muster or if it is redundant to previous MAPs and a waste of time).
The purpose of the vetting process is to mainly cut down on the work that Mojang staff needs to perform with this process. Only once a fully vetted proposal is "ready for prime time" and ready for presentation, a member of the Mojang staff can give approval or reject the idea with possibly suggestions on how to fix the proposal and have the community restart the process all over again to clean it up.
I hate to say this because it might be taken the wrong way, but what is really being proposed here is very similar to developing legislation, and for many of the same reasons. An API is developing rules for interaction between multiple people... essentially laws for developing plug-ins. If you want to see successful ways that this has been developed for humanity in the past, following a standard for developing legislation and turning ideas into laws is not a bad way to look at it. You have nearly a hundred thousand software developers who are very active in making changes to Minecraft (currently), and if you do the API properly that could climb to over a million different developers. I am being completely serious here in terms of the breadth of the community that you are going to need to work with. Somehow you need to set up a system so that out of that huge mass of people everybody will have a chance to be heard, and nearly all of those million plug-in developers will have at least some idea to add as an API.
By comparison, English Wikipedia has only about 30 thousand active participants that contribute on a day to day basis... and you only need to go to a typical page and see the arguments that come from collaborative development of the articles (such as this discussion page: http://en.wikipedia.org/wiki/Talk:Barack_Obama ) I would expect that some MAP proposals could have similar kinds of raging discussions, particularly if there are multiple approaches to the same basic idea being developed.
Regardless, thank you very much for being open to new ideas, and this is something I very much wanted to see Mojang implement in a formal manner. The idea of a MAP proposal gives some structure and framework for making changes to the game in a very substantive manner and is something that will be a very real innovation in the industry. I think it will give some steam to Minecraft that will push it forward in ways that will be amazing and show how the mod development community has just barely begun to develop content for the game.
The Plug-in API (they really won't be modifications of the original Minecraft software, although I think the term "mod" is still going to stick) is a system that allows you to get custom new content that is designed by people other than Mojang... and have that custom content officially supported by Mojang.
Until now, the "mods" that you see in the Mod section of this forum and elsewhere are really "hacks" as in "hacking" and "hackers" in a very real sense. They are people who have studied the game to such detail that they know the internal structure of the game and how it has been coded, and have made changes to the raw structure of the game. I hope I don't need to go into more details about what a mod actually does, other than it allows you to do something different than the standard version of Minecraft (usually called "vanilla Minecraft" by mod developers).
Instead, what you will be able to do is to download or otherwise acquire a piece of software that the only thing you will need to do is to put that software into a special folder in the game (no need to install Mod Loader or other software). Even more important, once you have installed that software into the game, even when the game updates and changes that software will continue to work. You no longer will need to worry about updating your version of Minecraft if you have one of these plug-ins and are using it for your worlds.... for the most part. There could be times when parts of the API will break, but I will give credit to Mojang that they will keep that to a minimum and such changes will be extremely rare.
Sooooo, it will make it so that mods don't break every update?
The feature I desire most is to specify a list (XML for example) with classes to be compiled along with the originals for easy, fast, full modding set ups. The hardest part right now is getting Minecraft to compile your custom classes.
Some other stuff:
Terrain generator modification. Biome size, biome spawn frequency, tree spawn per biome, maximum elevation, floating terrain quantity, water amount, lava amount, ravine depth/length/spawn frequency, structure spawn frequency and per biome likely-hood, cave length/radius range/occurrence frequency, those kinds of things (and possibly a way to add your own biome, vague).
Also it would be great, wicked, awesome and an absolute pain in the *ss for Mojang but: 1 texture file for the gui. As a texture designer we draw 1 item slot, the arrow graphic, furnace fire graphic, brewing bubble graphic, background texture ect. which will then be applied all over the game. This way, texture pack makers wont have to bother that much with making texture packs for mods, as the guis auto-update. Plus, it will be a lot easier to check wether it looks good, instead of editing/comparing one texture, then changing it all and playing for a while only to realize it's not good enough and needing to start over. Of course stuff like the HUD and loot graphics will remain unchanged, merging those would be rather impractical.
Utterly vague and overly obvious requests:
- adding blocks
- adding entity blocks like crafting tables/furnaces
- adding entities (mobs, making liquid concrete fall like sand and gravel)
- adding tools (e.g. adding emerald tools)
- changing mob health/strength and weapon damage
There will no longer be modifications of Minecraft class files or decompilation of Minecraft.
Seems perfectly reasonable, though I wouldn't bother inventing the terms "MAP" and "MAPR" - just call them proposals and pull requests.
Do you have an issue type called Proposal in JIRA? If not, you probably want to specify the issue type used. Also I assume you will at least have a Bug issue type. Do you want to provide some guidelines of how to write proper Bugs? Any other issue types (personally I recommend as few as possible - my experience is people will be confused)?
Do you prefer proposals come with pull requests, or at least some code examples?
Seems orthogonal to this discussion, which is more a "how to write a good issue description" than "how to write a good API". But certainly any proposal should consider performance.
I think the traditional Git pull request system (or a similar system) is going to break down in a real hurry and cause problems because of the sheer crush of ideas and participants. It may have worked for Bukkit and certainly does work for smaller groups of developers, but the crush of participants here is going to be huge, by far larger than you can directly imagine. There is also going to be a horrible S/N ratio on proposals for API changes that will need to be vetted and I don't think any paid staff will have the time to review those proposals in any sane fashion without some sort of community filtering process.
I know that Linus Torvalds has been able to stay on top of changes to the Linux kernel, but he has been forced into making that a full-time job by itself, and the process of contributing to the Linux kernel is not something a relatively new software developer will ever be involved with doing. I suppose it could get to that point with a number of very skilled and talented developers could be a part of that core group of volunteers who review MAP ideas, but there are some difference with what is being proposed at this point.
Sooooo, it will make it so that mods don't break every update?
Yes. If that is the one thing you take out of this discussion, it is the reason why this whole idea of an API is such a big deal. The purpose of the MAP proposals is to make sure that you have plug-ins which do something more than turn dirt into diamonds as a special crafting recipe.
yes, i think its good.. we should do a talk article, but it would be flooded with random crap, and wikipedia would just remove it. Trust me, its happened to me a couple times
Wikipedia has about a thousand new articles which are created every day (give or take a few). About 80%-90% of those are just random garbage such as an article about a Minecraft server world or some kid's elementary school classroom teacher... assuming that there is something serious about the article in the first place and not just random garbage from a keyboard smash. I would expect the same ratio of garbage to serious proposals happen with this MAP system.
The thing is, however, about 10%-20% of those proposals will be real gems that need to be seriously considered, and some of them will be needed by somebody making a really awesome plug-in/mod that could significantly change the way people play the game. About 0.1% of the proposals will be things very much needed by the community and be outstanding proposals. If there is a huge technical barrier to introducing such a proposal, that 0.1% of the proposals will get lost in the noise and likely never developed.
I think the traditional Git pull request system (or a similar system) is going to break down in a real hurry and cause problems because of the sheer crush of ideas and participants. It may have worked for Bukkit and certainly does work for smaller groups of developers, but the crush of participants here is going to be huge, by far larger than you can directly imagine. There is also going to be a horrible S/N ratio on proposals for API changes that will need to be vetted and I don't think any paid staff will have the time to review those proposals in any sane fashion without some sort of community filtering process.
I know that Linus Torvalds has been able to stay on top of changes to the Linux kernel, but he has been forced into making that a full-time job by itself, and the process of contributing to the Linux kernel is not something a relatively new software developer will ever be involved with doing. I suppose it could get to that point with a number of very skilled and talented developers could be a part of that core group of volunteers who review MAP ideas, but there are some difference with what is being proposed at this point.
Yes. If that is the one thing you take out of this discussion, it is the reason why this whole idea of an API is such a big deal. The purpose of the MAP proposals is to make sure that you have plug-ins which do something more than turn dirt into diamonds as a special crafting recipe.
Yes, I definitely agree. All of the pull requests may be too much for this. I know that myself and many others I know will be participating, (50+), and that's a very small chunk of the community...
Okay, so here's the problem with a modding API: More seperation of mods from vanilla Minecraft will result in less options for modders. Less options for modders will result in more third party software that will allow for access to modding capabilities.
From what I've seen of your intentions for this API, it seems that you wish to prevent modders editing the Minecraft classes themselves. Well, unfortunately, that's not how it works. When a modder plans to modify, they modify. They don't "plug it in", as is the case for the Bukkit API. The problem is that no matter how comprehensive your API is, somebody is going to want to step outside the boundaries of what it can do.
The only thing you can do for such a person is provide options for them so that they don't HAVE to edit Minecraft classes. Forcing them to use a plug-in type system is just going to backfire and cause them to employ third party software to do what can't be done with the API.
I know the plug-in system works well for Bukkit, but servers are completely different from clients. When running a server, you don't add or change anything. If you do, you would need players to download a custom client. In the case of custom clients and servers, Bukkit is completely useless as the modder would need to do the work himself/herself anyway. In short, plug-ins aren't mods and never will be, and so mods will always exist.
I can make you the perfect API right now: Official support of MCP, inclusion of ModLoader (or something similar) in vanilla Minecraft, javadocs and no more obfuscation. Doing those four things would provide modders with everything they need and help them make their mods more compatible. You can't force a modder to use an API, but you can provide them with the opportunites to make better and more compatible mods.
What I'm trying to say is that you should support modding instead of regulating it. After all, Minecraft was built by the community as well as Mojang. The more that is taken from modders, the less they can give in return.
Are you going to add MCP as an official tool for modding or make a custom built decompiler for source code? Because with that decision I think we can help adding in code a bit more.
Okay, so here's the problem with a modding API: More seperation of mods from vanilla Minecraft will result in less options for modders. Less options for modders will result in more third party software that will allow for access to modding capabilities.
From what I've seen of your intentions for this API, it seems that you wish to prevent modders editing the Minecraft classes themselves. Well, unfortunately, that's not how it works. When a modder plans to modify, they modify. They don't "plug it in", as is the case for the Bukkit API. The problem is that no matter how comprehensive your API is, somebody is going to want to step outside the boundaries of what it can do.
While well intentioned, I think you miss the whole point of this discussion.
I understand your concern here, so far as any mod that is worthy of the title and does something original is very likely going to crack into the minecraft.jar file and bypass even the current user-created API libraries that exist. I've had to do that myself with the mod that links to my sig below.
The point of the MAP proposal process is to hopefully set up a standard way for adding in hooks into the Minecraft code so once those hooks have been established and added into the code base, that 3rd party developers will have their "plug-ins" be considered standard features in the game. You also completely miss the point of an API in the first place here.
There is some separation between the vanilla Minecraft and the plug-in developer because such discipline is necessary. In fact, I've been professional involved with much larger projects than Minecraft where my relatively small development team (about a dozen software developers + support staff) still had to come up with an API. Doing that not only sped up development time (the projects we were doing simply couldn't have been done otherwise) but in the long run made our software much more stable.
I can't emphasize this enough, raw modding needs to be made something of the past. Long time Minecraft players can testify over the problems of mod conflicts where one mod is fighting with another one over changes made in the game. This still is a problem if you have multiple mods changing the same base classes in the minecraft.jar file or classes that have dependencies. You say that Mojang is trying to stop people from editing those class files in the minecraft.jar file, and you hit it square on: the only people who should be changing those classes are the Mojang staff. If you want to play nice with other developers, you need to give up on the notion that you have raw access to everything in the game.
I'll put it this way. Prior to the development of the current community-developed API libraries (Mod Loader, Forge, Bukkit, and others) you most likely couldn't put more than a couple of mods together in the same version of Minecraft before you had conflicts. Now, with those various (and sometimes competing) API libraries you can have as many as perhaps a dozen mods running before you start to run into conflicts between mods. The hope is here that you might have perhaps even a hundred different mods running at the same time... something that currently is impossible to do at the moment.
The old way of doing things will still be available if you want to go it alone and ignore the rest of the 3rd party development community, but using a formal API is really a better way to get things accomplished. Those who insist upon actual "modifications" to the game in a raw way without going through the API will find themselves marginalized and very likely will be ignored by the player community as a whole... particularly because such raw "mods" will conflict with the API system and players will get tired of having to wait for those old fashion mod developers trying to play catch-up after each major release.
My first thoughts:
1. What is a JIRA?
2. What is a MAP?
3.
The description of the MAP should contain detailed and justified specifications and challenges faced.
Very often, that will be impossible to determine initially.
Let me backtrack several YEARS here. Perhaps you've heard of a system called "Tor"? Well, it has a number of performance issues. At one point, I tried to contribute with ideas for improving it.
The problem? The Tor developers/mailing lists wanted all ideas separated into individual proposals, and you had to do security analysis of your proposal. And these were (approximately) 4 different ideas that were intended to work together, and made no sense individually. On top of that, I had no idea HOW to do security analysis, never mind no idea of any risk factors nor how to begin determining risk factors.
To this day, Tor remains slow, and the solutions are as simple as the solutions that make independent implementations of bittorrent fast while commercial ones like Blizzard's downloader are (were) painfully slow. Etc.
What is the point? Do Not Make It Hard To Submit Ideas!
4. What you need is more than one level.
Lots of people have ideas.
*MANY* people have ideas and want to contribute it.
Some good ideas will come from people who are unknown to the mod community, very possibly with no mod experience at all, but who want multiple mods to work together when they currently do not.
Someone compared this to legislation. Let me give you my view on this. I'm very concerned, politics-wise. (Personal blog on this: http://StrictConstitution.BlogSpot.com). I grew up with "Don't bother, no one will trust it coming from an undergraduate" when I had an idea to improve the computer experience/system at UCLA where a high-end, state of the art system that had to be available to group A when needed went unused most of the time -- even though UCLA at that time was running a high-end, state-of-the-art (in fact, defining the art) distributed operating system.
From the viewpoint of someone who asks, "What would I do if I were president of the USA?", the number one point of importance is listening. Imagine a question so powerful, so important, that you need to consider that there are potentially 7 billion people who might have an answer, and at least 1.5 billion who will want to submit an answer. Imagine having to try to design a system to deal with a response load like that?
Imagine someone who looks at the SCOTUS ("Supreme Court of the United States") as a group that constantly breaks the constitution, and gets away with it because it has no oversight, and asks, "How can we put some oversight onto the organization that, by fiat, has the final say on matters of law and fact?".
I don't even begin to think I have the best, or even close to final answer here. But what I do see, every time I come back to this, is to have multiple reviewer groups, and have any one review group be able to give a go-ahead.
For this specific system, I am proposing something along these lines:
1. Anyone who has an idea can submit an idea. An idea tracking system (very similar to existing bug or issue tracking systems) keeps track of things.
2. A minimum of three review teams look at each idea. Review teams should be at least three people. It does not need to be the same three people each time on a given team; the assignment of teams does not need to be the same (So, just because teams 3, 14, and 16 worked on idea #1138, does not mean that those same three teams will work together on the next idea they work with, nor that the same people will be on each team.)
3. The number one goal of the teams is to understand the point, purpose, and intent behind the idea. The number two goal is to have the incoming idea re-written into the format that you want inside the mod proposal system -- that JIRA/MAP system that you indicated.
The number three goal is to vet or reject the idea. If at least one of the teams looking at it thinks that it is worth follow-up on, then it advances.
4. If this results in too many ideas/proposals advancing, then another round of review teams looks at what is coming in, and filters those.
It seems to me that the first thing should be the goal ("A trading API would allow developers to construct a sophisticated merchant system using the chest container."), not the desired implementation features. And, if possible, high-level psuedo-code that would demonstrate the intended use of the desired specific features.
I still remember an early programming assignment, end of first year college computer science, where we were implementing a game AI. We were told that -- actually part of the assignment -- that we had to implement various tree manipulation routines and that they would be needed to handle the game; we were told that we HAD to base the board evaluation and scoring based around a certain manner, etc. I never used any of the tree routines that I had to write (I used a list-based system), and the board evaluation (static look at the position of the pieces and static values of pieces at location) was a disaster, as the real value of a piece at a spot depended on other spots and pieces, yet that was against the rules for that assignment. Turns out the best program just ignored all that and did it right anyways.)
My point here: Do not focus on the low-level details; focus on the goals, and high-level overview.
===
Finally: Make it much easier than it currently is for someone to provide ideas/code/mods/implementations.
This is coming from someone who looks at Java-5 as the valid supported language level for Minecraft, has two machines that now play acceptably well with J5, who has been happy with RML (Risugami's mod loader) working in J5, and frustrated by FML not. From someone who tried to get MCP to decompile 1.1, only to have it utterly fail on J5 (does not run), got it decompiled on a friend's PC (J6) only to find that it had all sorts of error messages and recompilation failures, and was unable to get any assistance any place I asked.
If you have no one helping people get started, you cannot get enough people involved.
The state of documentation for the existing MCP system stinks.
Notch, in the AMA, had a very interesting reason for liking Java: Hot swapping of code in a running program. I knew that this was a big potential for Java from day 1 (a big part of the language design goal, in fact), but I had never seen how to do it. So how does Notch do it?
Eclipse.
I see lots of people recommending Eclipse for working with Java.
I see MCP pretty much seems like it wants/needs to work with Eclipse.
But ... where is "How to use Eclipse"?
Try this: Pretend that you are someone that uses command-line editors (your choice: Vi, Ex, Emacs, or Pico), are familiar with Gui-systems (Wordpad/TextEdit, Word/Word Perfect/etc), and are looking at the Eclipse window for the very first time, in it's default configuration. Do you have any clue what you're doing?
Now assume that you have vision issues, use a default font size of 16 points, and are seeing what looks like 10 point fonts.
It has to be made easier for people to get started helping out.
Looks decent, but I really think performance should be one of the key factors, the better you can get performance the more features you can end up packing in in the long run, it'll open up room to do more things.
Premature optimization is a bad thing in about 95%+ of situations.
Get it working, get it working right, get it working fast. That order.
I know the plug-in system works well for Bukkit, but servers are completely different from clients. When running a server, you don't add or change anything. If you do, you would need players to download a custom client. In the case of custom clients and servers, Bukkit is completely useless as the modder would need to do the work himself/herself anyway. In short, plug-ins aren't mods and never will be, and so mods will always exist.
I can make you the perfect API right now: Official support of MCP, inclusion of ModLoader (or something similar) in vanilla Minecraft, javadocs and no more obfuscation. Doing those four things would provide modders with everything they need and help them make their mods more compatible. You can't force a modder to use an API, but you can provide them with the opportunites to make better and more compatible mods.
Either I am misunderstanding you, or this is a complete fail.
I run servers for myself and friends. I've got one using bukkit, primarily so I can use a good tree chopper (three different ones to choose from), and "OtherDrops" so I can play with things.
But lets say I want to add in a custom ore? Or a custom dimension (Twilight Forest)? Or a bunch of them (Mystcraft)? Then I need to use vanilla, because I want to run a server and add or change things. And bukkit fails for that.
Equally, official support of MCP/etc fails as soon as two different mods want to modify the same base class. That is why an API is needed -- to reduce the amount of base class conflicts. And when someone needs to edit a base class, that's when they need to be able to submit an idea to the mod API development process.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I can't emphasize this enough, raw modding needs to be made something of the past. Long time Minecraft players can testify over the problems of mod conflicts where one mod is fighting with another one over changes made in the game. This still is a problem if you have multiple mods changing the same base classes in the minecraft.jar file or classes that have dependencies. You say that Mojang is trying to stop people from editing those class files in the minecraft.jar file, and you hit it square on: the only people who should be changing those classes are the Mojang staff. If you want to play nice with other developers, you need to give up on the notion that you have raw access to everything in the game.
I'll put it this way. Prior to the development of the current community-developed API libraries (Mod Loader, Forge, Bukkit, and others) you most likely couldn't put more than a couple of mods together in the same version of Minecraft before you had conflicts. Now, with those various (and sometimes competing) API libraries you can have as many as perhaps a dozen mods running before you start to run into conflicts between mods. The hope is here that you might have perhaps even a hundred different mods running at the same time... something that currently is impossible to do at the moment.
Have a robust API will be much better in the long run for people who are building mods. There should be no reason for people to keep overlaying classes when plugging into the app will be available.
I for one get annoyed when you need to wait for modders to update their code after a new release.
while they API won't solve that problem 100%, it will get you 95% there.
So these MAPs don't actually contain any code? They're just suggestions about what to put into the API? If so, then that's okay. If they are supposed to contain code (like in a pull request) however, I would appreciate being able to see the unobfuscated source code.
So these MAPs don't actually contain any code? They're just suggestions about what to put into the API? If so, then that's okay. If they are supposed to contain code (like in a pull request) however, I would appreciate being able to see the unobfuscated source code.
As I understand it the MAP is just an api feature suggestion, and the pull request is made after that. And the pull request shouldn't need to see the source code; Mojang will be the ones implementing it, we just suggest what we want implemented. For example Bukkit is the api whereas Craftbukkit is the implementation.
Bukkit: https://github.com/B...lock/Block.java
Craftbukkit: https://github.com/B...CraftBlock.java
In this case the api is well.. the api, and Minecraft will be the implementation. So really all the pull requests should be are interfaces, and abstract classes. At least that's how I understand it.
I would be excited if you could put in a system like the IETF system for RFCs. I have to presume that is what you intend, but it should be something where the MAPs are collaboratively written and vetted from within the community, where the individual MAP gets extensive review by all interested parties and that some sort of community system is established for writing these documents.
To me, it seems almost a perfect system for having a wiki to develop these kind of MAPs though, where active development of the MAP would have the threshold for editing the document to be rather low in terms of technical barrier to contribute ideas towards a specific MAP. Discussions could go on (and perhaps even rage) between various developers over the best way to develop the specific extension of the API. After it has gone through that development process, some sort of community vetting process is then established which has the mod development community giving thumbs up or down on the proposal (not necessarily voting for popularity, but evaluating the need and technical merits of the proposal to see if it passes muster or if it is redundant to previous MAPs and a waste of time).
The purpose of the vetting process is to mainly cut down on the work that Mojang staff needs to perform with this process. Only once a fully vetted proposal is "ready for prime time" and ready for presentation, a member of the Mojang staff can give approval or reject the idea with possibly suggestions on how to fix the proposal and have the community restart the process all over again to clean it up.
I hate to say this because it might be taken the wrong way, but what is really being proposed here is very similar to developing legislation, and for many of the same reasons. An API is developing rules for interaction between multiple people... essentially laws for developing plug-ins. If you want to see successful ways that this has been developed for humanity in the past, following a standard for developing legislation and turning ideas into laws is not a bad way to look at it. You have nearly a hundred thousand software developers who are very active in making changes to Minecraft (currently), and if you do the API properly that could climb to over a million different developers. I am being completely serious here in terms of the breadth of the community that you are going to need to work with. Somehow you need to set up a system so that out of that huge mass of people everybody will have a chance to be heard, and nearly all of those million plug-in developers will have at least some idea to add as an API.
By comparison, English Wikipedia has only about 30 thousand active participants that contribute on a day to day basis... and you only need to go to a typical page and see the arguments that come from collaborative development of the articles (such as this discussion page: http://en.wikipedia.org/wiki/Talk:Barack_Obama ) I would expect that some MAP proposals could have similar kinds of raging discussions, particularly if there are multiple approaches to the same basic idea being developed.
Regardless, thank you very much for being open to new ideas, and this is something I very much wanted to see Mojang implement in a formal manner. The idea of a MAP proposal gives some structure and framework for making changes to the game in a very substantive manner and is something that will be a very real innovation in the industry. I think it will give some steam to Minecraft that will push it forward in ways that will be amazing and show how the mod development community has just barely begun to develop content for the game.
Version 2.1 now updated for MC 1.6.2
Sooooo, it will make it so that mods don't break every update?
There will no longer be modifications of Minecraft class files or decompilation of Minecraft.
I think the traditional Git pull request system (or a similar system) is going to break down in a real hurry and cause problems because of the sheer crush of ideas and participants. It may have worked for Bukkit and certainly does work for smaller groups of developers, but the crush of participants here is going to be huge, by far larger than you can directly imagine. There is also going to be a horrible S/N ratio on proposals for API changes that will need to be vetted and I don't think any paid staff will have the time to review those proposals in any sane fashion without some sort of community filtering process.
I know that Linus Torvalds has been able to stay on top of changes to the Linux kernel, but he has been forced into making that a full-time job by itself, and the process of contributing to the Linux kernel is not something a relatively new software developer will ever be involved with doing. I suppose it could get to that point with a number of very skilled and talented developers could be a part of that core group of volunteers who review MAP ideas, but there are some difference with what is being proposed at this point.
Yes. If that is the one thing you take out of this discussion, it is the reason why this whole idea of an API is such a big deal. The purpose of the MAP proposals is to make sure that you have plug-ins which do something more than turn dirt into diamonds as a special crafting recipe.
Wikipedia has about a thousand new articles which are created every day (give or take a few). About 80%-90% of those are just random garbage such as an article about a Minecraft server world or some kid's elementary school classroom teacher... assuming that there is something serious about the article in the first place and not just random garbage from a keyboard smash. I would expect the same ratio of garbage to serious proposals happen with this MAP system.
The thing is, however, about 10%-20% of those proposals will be real gems that need to be seriously considered, and some of them will be needed by somebody making a really awesome plug-in/mod that could significantly change the way people play the game. About 0.1% of the proposals will be things very much needed by the community and be outstanding proposals. If there is a huge technical barrier to introducing such a proposal, that 0.1% of the proposals will get lost in the noise and likely never developed.
Version 2.1 now updated for MC 1.6.2
Yes, I definitely agree. All of the pull requests may be too much for this. I know that myself and many others I know will be participating, (50+), and that's a very small chunk of the community...
Step 1:
Develop a time machine
Step 2:
??????
Step 3:
Profit
From what I've seen of your intentions for this API, it seems that you wish to prevent modders editing the Minecraft classes themselves. Well, unfortunately, that's not how it works. When a modder plans to modify, they modify. They don't "plug it in", as is the case for the Bukkit API. The problem is that no matter how comprehensive your API is, somebody is going to want to step outside the boundaries of what it can do.
The only thing you can do for such a person is provide options for them so that they don't HAVE to edit Minecraft classes. Forcing them to use a plug-in type system is just going to backfire and cause them to employ third party software to do what can't be done with the API.
I know the plug-in system works well for Bukkit, but servers are completely different from clients. When running a server, you don't add or change anything. If you do, you would need players to download a custom client. In the case of custom clients and servers, Bukkit is completely useless as the modder would need to do the work himself/herself anyway. In short, plug-ins aren't mods and never will be, and so mods will always exist.
I can make you the perfect API right now: Official support of MCP, inclusion of ModLoader (or something similar) in vanilla Minecraft, javadocs and no more obfuscation. Doing those four things would provide modders with everything they need and help them make their mods more compatible. You can't force a modder to use an API, but you can provide them with the opportunites to make better and more compatible mods.
What I'm trying to say is that you should support modding instead of regulating it. After all, Minecraft was built by the community as well as Mojang. The more that is taken from modders, the less they can give in return.
While well intentioned, I think you miss the whole point of this discussion.
I understand your concern here, so far as any mod that is worthy of the title and does something original is very likely going to crack into the minecraft.jar file and bypass even the current user-created API libraries that exist. I've had to do that myself with the mod that links to my sig below.
The point of the MAP proposal process is to hopefully set up a standard way for adding in hooks into the Minecraft code so once those hooks have been established and added into the code base, that 3rd party developers will have their "plug-ins" be considered standard features in the game. You also completely miss the point of an API in the first place here.
There is some separation between the vanilla Minecraft and the plug-in developer because such discipline is necessary. In fact, I've been professional involved with much larger projects than Minecraft where my relatively small development team (about a dozen software developers + support staff) still had to come up with an API. Doing that not only sped up development time (the projects we were doing simply couldn't have been done otherwise) but in the long run made our software much more stable.
I can't emphasize this enough, raw modding needs to be made something of the past. Long time Minecraft players can testify over the problems of mod conflicts where one mod is fighting with another one over changes made in the game. This still is a problem if you have multiple mods changing the same base classes in the minecraft.jar file or classes that have dependencies. You say that Mojang is trying to stop people from editing those class files in the minecraft.jar file, and you hit it square on: the only people who should be changing those classes are the Mojang staff. If you want to play nice with other developers, you need to give up on the notion that you have raw access to everything in the game.
I'll put it this way. Prior to the development of the current community-developed API libraries (Mod Loader, Forge, Bukkit, and others) you most likely couldn't put more than a couple of mods together in the same version of Minecraft before you had conflicts. Now, with those various (and sometimes competing) API libraries you can have as many as perhaps a dozen mods running before you start to run into conflicts between mods. The hope is here that you might have perhaps even a hundred different mods running at the same time... something that currently is impossible to do at the moment.
The old way of doing things will still be available if you want to go it alone and ignore the rest of the 3rd party development community, but using a formal API is really a better way to get things accomplished. Those who insist upon actual "modifications" to the game in a raw way without going through the API will find themselves marginalized and very likely will be ignored by the player community as a whole... particularly because such raw "mods" will conflict with the API system and players will get tired of having to wait for those old fashion mod developers trying to play catch-up after each major release.
Version 2.1 now updated for MC 1.6.2
1. What is a JIRA?
2. What is a MAP?
3.
Very often, that will be impossible to determine initially.
Let me backtrack several YEARS here. Perhaps you've heard of a system called "Tor"? Well, it has a number of performance issues. At one point, I tried to contribute with ideas for improving it.
The problem? The Tor developers/mailing lists wanted all ideas separated into individual proposals, and you had to do security analysis of your proposal. And these were (approximately) 4 different ideas that were intended to work together, and made no sense individually. On top of that, I had no idea HOW to do security analysis, never mind no idea of any risk factors nor how to begin determining risk factors.
To this day, Tor remains slow, and the solutions are as simple as the solutions that make independent implementations of bittorrent fast while commercial ones like Blizzard's downloader are (were) painfully slow. Etc.
What is the point?
Do Not Make It Hard To Submit Ideas!
4. What you need is more than one level.
Lots of people have ideas.
*MANY* people have ideas and want to contribute it.
Some good ideas will come from people who are unknown to the mod community, very possibly with no mod experience at all, but who want multiple mods to work together when they currently do not.
Someone compared this to legislation. Let me give you my view on this. I'm very concerned, politics-wise. (Personal blog on this: http://StrictConstitution.BlogSpot.com). I grew up with "Don't bother, no one will trust it coming from an undergraduate" when I had an idea to improve the computer experience/system at UCLA where a high-end, state of the art system that had to be available to group A when needed went unused most of the time -- even though UCLA at that time was running a high-end, state-of-the-art (in fact, defining the art) distributed operating system.
From the viewpoint of someone who asks, "What would I do if I were president of the USA?", the number one point of importance is listening. Imagine a question so powerful, so important, that you need to consider that there are potentially 7 billion people who might have an answer, and at least 1.5 billion who will want to submit an answer. Imagine having to try to design a system to deal with a response load like that?
Imagine someone who looks at the SCOTUS ("Supreme Court of the United States") as a group that constantly breaks the constitution, and gets away with it because it has no oversight, and asks, "How can we put some oversight onto the organization that, by fiat, has the final say on matters of law and fact?".
I don't even begin to think I have the best, or even close to final answer here. But what I do see, every time I come back to this, is to have multiple reviewer groups, and have any one review group be able to give a go-ahead.
For this specific system, I am proposing something along these lines:
1. Anyone who has an idea can submit an idea. An idea tracking system (very similar to existing bug or issue tracking systems) keeps track of things.
2. A minimum of three review teams look at each idea. Review teams should be at least three people. It does not need to be the same three people each time on a given team; the assignment of teams does not need to be the same (So, just because teams 3, 14, and 16 worked on idea #1138, does not mean that those same three teams will work together on the next idea they work with, nor that the same people will be on each team.)
3. The number one goal of the teams is to understand the point, purpose, and intent behind the idea. The number two goal is to have the incoming idea re-written into the format that you want inside the mod proposal system -- that JIRA/MAP system that you indicated.
The number three goal is to vet or reject the idea. If at least one of the teams looking at it thinks that it is worth follow-up on, then it advances.
4. If this results in too many ideas/proposals advancing, then another round of review teams looks at what is coming in, and filters those.
===
Now, looking at the specific example of the MAP you gave on trading (background here: http://www.minecraft...s-and-concerns/, http://www.minecraft.../#entry12330837, http://www.minecraft...5#entry15823395):
It looks backwards to me.
It seems to me that the first thing should be the goal ("A trading API would allow developers to construct a sophisticated merchant system using the chest container."), not the desired implementation features. And, if possible, high-level psuedo-code that would demonstrate the intended use of the desired specific features.
I still remember an early programming assignment, end of first year college computer science, where we were implementing a game AI. We were told that -- actually part of the assignment -- that we had to implement various tree manipulation routines and that they would be needed to handle the game; we were told that we HAD to base the board evaluation and scoring based around a certain manner, etc. I never used any of the tree routines that I had to write (I used a list-based system), and the board evaluation (static look at the position of the pieces and static values of pieces at location) was a disaster, as the real value of a piece at a spot depended on other spots and pieces, yet that was against the rules for that assignment. Turns out the best program just ignored all that and did it right anyways.)
My point here: Do not focus on the low-level details; focus on the goals, and high-level overview.
===
Finally: Make it much easier than it currently is for someone to provide ideas/code/mods/implementations.
This is coming from someone who looks at Java-5 as the valid supported language level for Minecraft, has two machines that now play acceptably well with J5, who has been happy with RML (Risugami's mod loader) working in J5, and frustrated by FML not. From someone who tried to get MCP to decompile 1.1, only to have it utterly fail on J5 (does not run), got it decompiled on a friend's PC (J6) only to find that it had all sorts of error messages and recompilation failures, and was unable to get any assistance any place I asked.
If you have no one helping people get started, you cannot get enough people involved.
The state of documentation for the existing MCP system stinks.
Notch, in the AMA, had a very interesting reason for liking Java: Hot swapping of code in a running program. I knew that this was a big potential for Java from day 1 (a big part of the language design goal, in fact), but I had never seen how to do it. So how does Notch do it?
Eclipse.
I see lots of people recommending Eclipse for working with Java.
I see MCP pretty much seems like it wants/needs to work with Eclipse.
But ... where is "How to use Eclipse"?
Try this: Pretend that you are someone that uses command-line editors (your choice: Vi, Ex, Emacs, or Pico), are familiar with Gui-systems (Wordpad/TextEdit, Word/Word Perfect/etc), and are looking at the Eclipse window for the very first time, in it's default configuration. Do you have any clue what you're doing?
Now assume that you have vision issues, use a default font size of 16 points, and are seeing what looks like 10 point fonts.
It has to be made easier for people to get started helping out.
===
Premature optimization is a bad thing in about 95%+ of situations.
Get it working, get it working right, get it working fast. That order.
Either I am misunderstanding you, or this is a complete fail.
I run servers for myself and friends. I've got one using bukkit, primarily so I can use a good tree chopper (three different ones to choose from), and "OtherDrops" so I can play with things.
But lets say I want to add in a custom ore? Or a custom dimension (Twilight Forest)? Or a bunch of them (Mystcraft)? Then I need to use vanilla, because I want to run a server and add or change things. And bukkit fails for that.
Equally, official support of MCP/etc fails as soon as two different mods want to modify the same base class. That is why an API is needed -- to reduce the amount of base class conflicts. And when someone needs to edit a base class, that's when they need to be able to submit an idea to the mod API development process.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
The server is probally not updated yet, you'll just to wait a while.
I agree with King Korihor
Have a robust API will be much better in the long run for people who are building mods. There should be no reason for people to keep overlaying classes when plugging into the app will be available.
I for one get annoyed when you need to wait for modders to update their code after a new release.
while they API won't solve that problem 100%, it will get you 95% there.
So these MAPs don't actually contain any code? They're just suggestions about what to put into the API? If so, then that's okay. If they are supposed to contain code (like in a pull request) however, I would appreciate being able to see the unobfuscated source code.
As I understand it the MAP is just an api feature suggestion, and the pull request is made after that. And the pull request shouldn't need to see the source code; Mojang will be the ones implementing it, we just suggest what we want implemented. For example Bukkit is the api whereas Craftbukkit is the implementation.
Bukkit: https://github.com/B...lock/Block.java
Craftbukkit: https://github.com/B...CraftBlock.java
In this case the api is well.. the api, and Minecraft will be the implementation. So really all the pull requests should be are interfaces, and abstract classes. At least that's how I understand it.