All the API needs to do is alllow server admins to apply mods (server and client side typemods) to the server and have the option for clients to automatically download them on a server by server basis. Make the system as flexable as possible so it can incorporate a very broad range of mod types.
I dont get the rest of the this mumbo jumbo stuff, there is nothing else for the api to do. And it should have been done a year ago instead of playing around with villages and that "the End" thing...
Good idea but i agree with egoburn.
Minecraft is already openscource because of mcp and there allways be modmakers who prefer to adjust the existing classes.
but here's my idea:
There should be something like a modloader inside the original client to import mods. I think that just a system like the texturepack system would be great. A standard folder in the .minecraft folder for mods and a gui like the gui for texturepacks where you can enable/disable mods which are in the folder and import mods to the folder, they could also be sorted at kind of api used for the mod (eg: trading, rails, mobs, core (core mods that could be extended and just add a bunch of new stuff(like, bc, ic2 or rp), adds (this should be the extending of the core mods and misc).
I don't think you understand the role of an API if you think we shouldn't have an API yet Mojang should support including something like Mod Loader. What do you think Mod Loader actually is, if it isn't an API?
If you think MCP turns Minecraft into an open soruce project, you also don't understand the first thing about "open source" software, licensing issues, or what exactly MCP does. The real feature of an "open source" software project is the legal licensing terms (typicaly GPL, BSD, or MIT licenses or something similar) and the collaborative way that the software can be changed and made official. Minecraft most certainly does not have such licensing terms, and in fact the ability to make modifications to the game is technically illegal although tolerated by Mojang. Just because a bunch of guys have helped out in decompiling the obfuscated class names does not give you license to freely redistribute Minecraft, even if you happen to have added some extra features to the game.
The official API, as written by Dinnerbone, is very much similar to ModLoader + Bukkit right now anyway, so proposing that it should be added to the API is like saying cobblestone blocks need to be added to Minecraft.
For those continuing this line of discussion, please read first:
and educate yourselves about what an API is really all about. I'll say it again in perhaps a more blunt and better way: If you insist upon sticking to the old ways of developing mods and using MCP to modify base classes in the minecraft.jar file without using the official API, nobody will download your extension or at least very few people will. On top of that, it will be incompatible with other plug-ins that other people will be developing that will be using the official API.
I'm just doing a face palm here reading how there are people complaining that an API shouldn't even exist when at the same time they are demanding that an API needs to be added to the game.
I dont get the rest of the this mumbo jumbo stuff, there is nothing else for the api to do. And it should have been done a year ago instead of playing around with villages and that "the End" thing...
The purpose of this Mumbo Jumbo stuff is to allow the official API to be developed and expanded when the community sees a need to grow the API. At the moment, the only way ModLoader will get changed is if Risugami decides it should be changed (usually due to his own mods and needs of those mods). Forge is a little bit different, but even Forge has its problems.
What the point of this thread is all about is to describe how those changes to the API should take place and how proposals for making those changes should be initiated. If you think the current API as it exists in the specification that Dinnerbone has put together on Github is sufficient to take care of every possible plug-in that anybody will ever dream up, I suppose you can be critical of this process. I think that is just silly and foolish, but you are certainly entitled to your opinion.
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.
So how is this any different than Skyrim mods? yeah there are conflicts. Then you avoid them. I think we are smart enough to do that. Even the modders get together to work out the complexities. Simple, over controling the situation I think is going to just get people flustrated and moving on.
The Meaning of Life, the Universe, and Everything.
Join Date:
6/18/2011
Posts:
45
Minecraft:
deathmarin
Xbox:
d3athmarine
Member Details
So other than what you have on github. What has been proposed? What is on the table? Link to JIRA? Considering I could say.. well EntityAPI, and we need objects to extend EntityAPI, and then we need a WorldAPI and an EventAPI and a ServerAPI, a scheduling system. Hell there is a lot that you need. I'd say start with Events before objects. But I never built an api.
So how is this any different than Skyrim mods? yeah there are conflicts. Then you avoid them. I think we are smart enough to do that. Even the modders get together to work out the complexities. Simple, over controling the situation I think is going to just get people flustrated and moving on.
This is to try and avoid conflicts between plug-ins. Yes, this is like Skyrim mods or other kinds of mods, but I am just beside myself trying to understand why there are so many people even attacking the notion of an API without understanding what it does.
What is being proposed is a way for mod developers to work together and sort out those complexities in a systematic fashion, just as you are describing. What else do you think this is for?
I am excited about the new api, although im horrified to see all the servers die during the switch from bukkit to the api, having to use new mods, having to redo significant amounts of there servers, all the fresh starts.... When this comes it will be great for the future, but the transition will be brutal.
While I enjoy the idea of a more unified endeaver to make Minecraft code/capabilities more transparent for modders and the community as a whole; I think this whole thing boils down to a way to save face when it comes to MC liscensing and a quasi-political gambit to keep from getting into more largely trouted lawsuits.
Other than that, I plan to withhold my opinion until I actually see something come out of it. Good luck!
thanks for that wikipedia link, it helped me a lot understanding this all.
you're right about the thing that mods which dont use the api, simply don't will be used. But i think that a gui based system to add mods to minecraft would be a great advantage for mod users, and the id system i suggested previously would be a great way to avoid id clashes between mods.
An in-game GUI that would allow you to add mods directly to the game would be awesome, as would several other features that expanded the plug-in system including some way to avoid ID conflicts.
The thing is what is being discussed in this thread is an attempt to come up with such proposals and to make it work, not the proposals themselves. The idea behind the MAP concept is to allow you to make such a proposal as a GUI interface for loading mods and how that should happen.
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.
So you, for some odd reason, want to use a version of the compiler set that is two releases old, are using a third party tool to deobfuscate the jar into source files, and was unable to recompile... and this was Mojang's fault?
Quote from »
If you have no one helping people get started, you cannot get enough people involved.
Why would they help with unsupported third party tools? There is a reason the jar is obfuscated.
The state of documentation for the existing MCP system stinks.
I agree. Mojang didn't create MCP though. MCP is in fact working around the measures Mojang added to prevent messing around with the jar.
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?
Really? Edit & Continue is the biggest "potential" for java? Edit & Continue is a useful tool and capability provided in a lot of languages (Visual Basic had it from day one, and QuickBASIC,QBASIC, Turbo Pascal, etc. had some similar capabilities.). The thing is though that Edit & Continue on it's own doesn't really help with finding bugs. Debugging is a last resort and debugging is not about using a debugger, but about understanding the difference between what you did write and what you should have written.
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"?
It's the help page that shows up if you press F1 while running Eclipse.
I think the idea is that a person who wants to mod should already now how to use the language as well as an IDE Most IDE's share a lot in common (VS, MonoDevelop, Code::Blocks, Eclipse, Netbeans, etc.).
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?
Probably not. But if they have no idea what they are doing they shouldn't be trying to make a mod in the first place.
You know this discussion about what to change and where to change is great and all. But... I am not a moder. I like mods, and what they do, but honestly, I will never make one nor do I care to.. I just want to play and if someone out there has something neat to add great. But it needs to be easy to install, create no conflicts with what I already have going. Half this discussion is beyond me, and if you try and explain it, I will say that is nice, and now let us discuss the various propogation techniques of the Phicus tree in varius tropical and sub-tropical climates.
All the API needs to do is alllow server admins to apply mods (server and client side typemods) to the server and have the option for clients to automatically download them on a server by server basis. Make the system as flexable as possible so it can incorporate a very broad range of mod types.
Ive seen this suggested before, and its a nice idea, but what happens when the malicious server ops installs a virus mod onto every connecting client? Mass chaos, and then nobody will ever trust a server that installs mods again, no matter how trustworthy the owner seems.
I dont get the rest of the this mumbo jumbo stuff, there is nothing else for the api to do. And it should have been done a year ago instead of playing around with villages and that "the End" thing...
I don't think you understand the role of an API if you think we shouldn't have an API yet Mojang should support including something like Mod Loader. What do you think Mod Loader actually is, if it isn't an API?
If you think MCP turns Minecraft into an open soruce project, you also don't understand the first thing about "open source" software, licensing issues, or what exactly MCP does. The real feature of an "open source" software project is the legal licensing terms (typicaly GPL, BSD, or MIT licenses or something similar) and the collaborative way that the software can be changed and made official. Minecraft most certainly does not have such licensing terms, and in fact the ability to make modifications to the game is technically illegal although tolerated by Mojang. Just because a bunch of guys have helped out in decompiling the obfuscated class names does not give you license to freely redistribute Minecraft, even if you happen to have added some extra features to the game.
The official API, as written by Dinnerbone, is very much similar to ModLoader + Bukkit right now anyway, so proposing that it should be added to the API is like saying cobblestone blocks need to be added to Minecraft.
For those continuing this line of discussion, please read first:
http://en.wikipedia....mming_interface
and educate yourselves about what an API is really all about. I'll say it again in perhaps a more blunt and better way: If you insist upon sticking to the old ways of developing mods and using MCP to modify base classes in the minecraft.jar file without using the official API, nobody will download your extension or at least very few people will. On top of that, it will be incompatible with other plug-ins that other people will be developing that will be using the official API.
I'm just doing a face palm here reading how there are people complaining that an API shouldn't even exist when at the same time they are demanding that an API needs to be added to the game.
The purpose of this Mumbo Jumbo stuff is to allow the official API to be developed and expanded when the community sees a need to grow the API. At the moment, the only way ModLoader will get changed is if Risugami decides it should be changed (usually due to his own mods and needs of those mods). Forge is a little bit different, but even Forge has its problems.
What the point of this thread is all about is to describe how those changes to the API should take place and how proposals for making those changes should be initiated. If you think the current API as it exists in the specification that Dinnerbone has put together on Github is sufficient to take care of every possible plug-in that anybody will ever dream up, I suppose you can be critical of this process. I think that is just silly and foolish, but you are certainly entitled to your opinion.
Version 2.1 now updated for MC 1.6.2
So how is this any different than Skyrim mods? yeah there are conflicts. Then you avoid them. I think we are smart enough to do that. Even the modders get together to work out the complexities. Simple, over controling the situation I think is going to just get people flustrated and moving on.
Bukkit Plugins on Github
Version 2.1 now updated for MC 1.6.2
What is being proposed is a proposal for how to make proposals. This is a meta-discussion about proposals, not the proposals themselves.
This is to try and avoid conflicts between plug-ins. Yes, this is like Skyrim mods or other kinds of mods, but I am just beside myself trying to understand why there are so many people even attacking the notion of an API without understanding what it does.
What is being proposed is a way for mod developers to work together and sort out those complexities in a systematic fashion, just as you are describing. What else do you think this is for?
Version 2.1 now updated for MC 1.6.2
Really cool and it should be made!
Other than that, I plan to withhold my opinion until I actually see something come out of it. Good luck!
An in-game GUI that would allow you to add mods directly to the game would be awesome, as would several other features that expanded the plug-in system including some way to avoid ID conflicts.
The thing is what is being discussed in this thread is an attempt to come up with such proposals and to make it work, not the proposals themselves. The idea behind the MAP concept is to allow you to make such a proposal as a GUI interface for loading mods and how that should happen.
Version 2.1 now updated for MC 1.6.2
So you, for some odd reason, want to use a version of the compiler set that is two releases old, are using a third party tool to deobfuscate the jar into source files, and was unable to recompile... and this was Mojang's fault?
Why would they help with unsupported third party tools? There is a reason the jar is obfuscated.
I agree. Mojang didn't create MCP though. MCP is in fact working around the measures Mojang added to prevent messing around with the jar.
Really? Edit & Continue is the biggest "potential" for java? Edit & Continue is a useful tool and capability provided in a lot of languages (Visual Basic had it from day one, and QuickBASIC,QBASIC, Turbo Pascal, etc. had some similar capabilities.). The thing is though that Edit & Continue on it's own doesn't really help with finding bugs. Debugging is a last resort and debugging is not about using a debugger, but about understanding the difference between what you did write and what you should have written.
It's the help page that shows up if you press F1 while running Eclipse.
I think the idea is that a person who wants to mod should already now how to use the language as well as an IDE Most IDE's share a lot in common (VS, MonoDevelop, Code::Blocks, Eclipse, Netbeans, etc.).
Probably not. But if they have no idea what they are doing they shouldn't be trying to make a mod in the first place.
Image Removed
Ive seen this suggested before, and its a nice idea, but what happens when the malicious server ops installs a virus mod onto every connecting client? Mass chaos, and then nobody will ever trust a server that installs mods again, no matter how trustworthy the owner seems.