The Meaning of Life, the Universe, and Everything.
Join Date:
9/21/2011
Posts:
47
Member Details
Hm, so everytime someone has an idea, they have to make a proposal, get it approved and a developer there has to implement an API for it? That seems like a much worse system than what we have currently.
And if someone else re-implements the API, then they will have a re-implementation of minecraft that can use other people's mods.
This is wrong. I made a mistake. For everyone who says that base class edits are needed, and an API cannot be enough, read this description of my error.
Right now, we have about 100-some blocks, about 200-some items, about 170-some recipes, and so on.
We are used to thinking of base class edits as ways to change these behaviors.
What if every one of these was actually provided by plug-ins, rather than being part of the base game?
What if the base game had no knowledge of any blocks, no knowledge of any redstone, etc. All of that was provided by plug-ins.
With one very large plug-in package provided by Mojang.
That's the idea of an API complete enough to cover everything. And this is not my idea from nothing -- this comes from the log of the first API discussion IRC chat.
(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?
Hm, so everytime someone has an idea, they have to make a proposal, get it approved and a developer there has to implement an API for it? That seems like a much worse system than what we have currently.
How would this be a worse system? What is going to happen is that the API will be built into the game itself, so there won't be a need to wait for the independently developed APIs like Mod Loader and Forge or even Bukkit to get their acts together and release a new version compatible with the current version of Minecraft. It also means that mods that use the official API will not need to be updated when there is an update for Minecraft.
Is that awful? I suppose people love to see their maps get broken simply because they "accidentally" update Minecraft but forgot to update the mods they used on that map or even love taking a week or two break from playing the game because the mods they like to use haven't updated yet. And mod developers just love to program so much that they enjoy repeating the same task over and over again simply to stay current with the latest version of the game instead of programming something new and original that extends the game. I guess you love whiny little snits complaining on mod threads about the fact that some mod hasn't updated yet as well (in spite of being specifically against forum rules).
What I don't understand is why this thread has turned into a "let's dump on the concept of an API in the first place" thread. If you really hate the very idea of an API, why are you posting here? What we currently have is a very chaotic system of conflicting APIs and people pretty much doing whatever they want to do along with all of the problems I outlined above.
Regardless, all of this dumping on the concept of an API does nothing to help EvilSeph get the feedback he wants, other than to throw in the towel and say the whole idea of an API is getting so much resistance that it shouldn't be done at all. If you want to use MCP (or something like it) and directly modify the game outside of the API, nobody is stopping you. I just promise you that nobody will use your mods once the official API is out, or at least it will be a very small minority in the overall Minecraft extension developer community.
The current system is that there is no feedback from those who want to made plug-ins/mods to the Mojang developer staff, and the other alternative is simply creating an API of your own and doing the sort of hurry up and everybody screaming that you haven't got it done yet kind of thing that Risugami is getting right now.
Here is to tell what is happening to those who cannot log on to a server. If you cannot log onto a server right now and you updated to 1.3.1 then you cannot go on any server until Minecraft bukkit is updated to 1.3.1, bukkit is what runs a lot of servers 24/7, bukkit is huge. The only problem is that bukkit 1.3.1 is still be modified for the update (make sure everything is working on it and looking for bugs etc.) So the only way that you can play on a server right now is by degrading back to 1.2.5, but it is real compicated. There is a link on the Killion Detention Center Server topic of a video on how to degrade from 1.3.1 to 1.2.5, but there is 1 problem. You would have to have 1.2.5 as a file (you have to do that manually because Minecraft doesn't do that for your computer when downloaded) so you would have to already make 1.2.5 a file before you updated which I kinda doubt any of you guys that want to get on a server did. So that is basically it. Bukkit is supposed to be updated tomorrow though.
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.
I share your fears, though I think it will be the issues in JIRA which will become overwhelming. However, if pull requests can work for Linux, they can certainly work for Minecraft! I believe the Linux kernel is managed by having separate (trusted) maintainers for different portions of the kernel. Pull requests are given to the maintainers, not Linus. Linus then only needs to pull from his few maintainers.
The question is whether the developers have the experience and discipline to establish and maintain an effective process, and to evolve that process as necessary. I have seen larger teams with far fewer issues utterly fail in this regard.
I strongly recommend establishing a process for quickly triaging newly created issues. Those with insufficient description or simply poor proposals must be rejected right away, otherwise they will pile up and become overwhelming. Atlassian (makers of JIRA) have a recent blog post with some interesting ideas.
JIRA allows the default assignee to be set per-component, so that could provide some easy division of labor.
Enabling voting in JIRA (the default) would also provide an easy way for developers to see what is very important to the community.
If JIRA's GreenHopper plugin is installed, I recommend setting up a Rapid Board so the community can see what's being worked on / expected to be worked on soon. The Scrum-style board seems a natural fit to Minecraft's weekly snapshots (i.e. weekly iterations), but the Kanban-style board would work well too.
I also recommend the developers have some way to indicate issues which they are prepared to work on themselves, versus those they would like community input on. Perhaps a custom field, or maybe simply some status. I suppose there is also nothing to prevent Mojang from giving some / all users the ability to be assigned to issues, so some of the work can be directly farmed out to the community. Of course this will still require a pull request and a review by Mojang. As you suggested, perhaps some trusted community members could also be granted the ability to triage the issues.
I will hate when this comes out. I understand that Mojang wants to be nice to all the people currently joining MC and want mods, but for people like me who learned java and have like 10 mods out, an API will complicate updating/converting and make it possible for every noob out there that wants a mod but doesn't know how to code to have one. I say drop the API, keep Modloader and forge.
Yes I know, I probaly just got put as #1 on the to-kill list of the MC Community. I spoke my mind, that's all
I read the OP more then a few times and most of the follow up pages and I still do not know where ideas are submitted to.
It's not time to submit your ideas yet. This is just a discussion of how idea submissions will be handled. Once that's ironed out, a site will be created where you can submit your ideas.
This sounds great. Also, sayin, Keep away from Vechz
Rollback Post to RevisionRollBack
GENERATION 9002: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment http://www.youtube.com/user/sidorakh
first things first, minecraft should have an inbuilt plug-ins folder like bukkit that works across all versions. You place your mods into that folder and if a class inside the plugin has been modified since the last version it will ignore the plugin. Second for mod development you should have a GUI editor that lets you set up a background image, buttons and stuff like that. There should also be a mob animation and model editor as well as a code browser and editor. Finally there should be a button to add a new mob as well as one for a new gui, a new item or new block that adds all the required classes for that new object, e.g. adding a new mob will make the mob class, the model class, the render class and a mymod_mod class that adds it to the render list and spawn list. I know it would be hard to program, but if you were to modify eclipse or visual studio it could be simple.
yes yes yes !!!! i want the mod api soooooooooooooo bad hope its in the next update
no no no!!! I learned java, the api will no doubt be based around java and thus modding will be the same, but with less work compiling and decompiling.
It is readily apparent from reading this thread who the actual programmers are and who the frauds are. As the developer chat indicated, the intention is to evolve MC into a fully modular installation with a dumb client. Given this end goal, an API isn't simply a luxery, it is a necessity. The brute force method of cracking the jar will not only be shunned by the community as a whole given cross-mod incompatibilities and update/installation difficulties, it will become extemely limited in scope as the main jar would simply be a core with all other features being written as single-scope plugins with the API.
Examples:
Terrain generation in the core, each biome (1st and 3rd party) as a seperate plugin that can be turned on or off with a GUI or config file.
Mob spawning in the core, each mob (1st and 3rd party) as a seperate plugin that can be turned on or off with a GUI or a config file.
As far as the initial proposal in the OP, that methodology seems pretty par the course for a project like this. That said, I would encourage some sort of vetting process on future discussion threads for keeping out the riff raff that can't differentiate between an object-oriented language and qBasic.
Here's a quick idea for how to do this. If you want the community to determine which are good ideas and which are bad, why don't you establish a forum-type structure where people can give up and down votes on the requests. That way you can sort all the suggestions as "highly liked", "highly viewed" and "% liked". It would save you from having to search through them all as you can just look at those ones.
The system will work but if you get too many spam it could get overloaded and well not work you should make the map's parts have a min amount of words accept for the Summary, Specific features, Affects Versions, Components and Labels.
Other then that it looks good
Everything I write is just an opinion, but I have some experience desiging software interfaces, so if you disagree with anything I write - please explain what you disagree with, and why, and what is your counter-suggestion.
There are two separate issues:
1. The mod loader - a feature that has to be build-in into minecraft, and perform the same basic function as the ModLoader or other similar mods. It has to provide the user with functionality to select from a list of available mods (already downloaded to a certain directory, maybe downloading them from a pre-configured location as well), select which mods the user wants to use, make sure there are no incompatibilities, and start the game. The mod loader must also provide the mods with block and item IDs - mods should use "local" IDs, which are mapped to global IDs during mod loading.
2. The modding API itself - a piece of code *specification* (that is, java interfaces) and instructions on how to compile/package them, so the mod loader is able to use them. This is the biggest part of the work.
Modding API must provide the mod with access to "the rest of the world".
I can see at least the following mod features:
- New block - the modder should provide the basic block type (translucent/glass-like/stone/etc), texture ID (with option to include the images in the mod itself), how it interacts with the player (which tools affect it, and how, which items/mobs are dropped if a tool is applied to it, how the tools are used/damaged, etc)
- New Item - which types of blocks and mobs it affects, and how (for example a 'placeable block' item's right-click interaction is creating a block there, and reducing the inventory count by 1)
- New mob - how it interacts with each mob and block type, etc
Note that if there are two mods, one providing block B, and another providing tool T there can't be code defining their relation.
Assuming (arbitrarily, I admit) that there are less items types then there are blocks, the game core will execute T's effect as it's define for the base block on B.
Assuming that many of the new features in a mod will behave in many ways identically to existing features, the API must provide all the default behaviour "out of the box". The easiest way to achieve this is to have hierarchies.
Block types: completely static (no need to check during ticks), liquids, affected by gravity, affected by redstone, affected by proximity, need occasional updates (furnace, leafs, etc)
For example, simplest kind of mod I can think of is a new decorative block. The modder should just inherit the completely static block type, provide the texture, and be done.
Most of minecraft's core features should also be rewritten as a mod. this mod will be bundled as a part of minecraft.jar and always loaded by the mod loader.
There are other important features that I want to write my about later:
- Other aspects for the game which should be moddable: world generation (including other dimentions), weather, physics, GUI
- Mods conflict, and how mod loader detects them and avoids loading conflicting mods
- modifying/removing existing blocks/items/mobs (may be the major reason for the conflicts).
- Types of block interaction (for example, a few existing mods have the concent of 'mechanical power' which ideally should be transfered to blocks of other mods, in the same way redstone is transfered - but it has to be somehow done through the API.
Please let me know if I'm barking up the right tree, and if so - I would like to keep revisioning my opinions, improving them based on relevant comments - and hopefuly eventually come up with a useful set of MAPs.
Hello evilseph I am ultimo100 and I love the idea of modding API but I'm alittle unsure of what it's will do and in 1.3.1 I'm confused about LAN and mods like for eg if I have tropicraft and I open I LAN and my friend didn't have the mod what happens? Yours sincerely ultimo100
This is wrong. I made a mistake. For everyone who says that base class edits are needed, and an API cannot be enough, read this description of my error.
Right now, we have about 100-some blocks, about 200-some items, about 170-some recipes, and so on.
We are used to thinking of base class edits as ways to change these behaviors.
What if every one of these was actually provided by plug-ins, rather than being part of the base game?
What if the base game had no knowledge of any blocks, no knowledge of any redstone, etc. All of that was provided by plug-ins.
With one very large plug-in package provided by Mojang.
That's the idea of an API complete enough to cover everything. And this is not my idea from nothing -- this comes from the log of the first API discussion IRC chat.
* 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?
How would this be a worse system? What is going to happen is that the API will be built into the game itself, so there won't be a need to wait for the independently developed APIs like Mod Loader and Forge or even Bukkit to get their acts together and release a new version compatible with the current version of Minecraft. It also means that mods that use the official API will not need to be updated when there is an update for Minecraft.
Is that awful? I suppose people love to see their maps get broken simply because they "accidentally" update Minecraft but forgot to update the mods they used on that map or even love taking a week or two break from playing the game because the mods they like to use haven't updated yet. And mod developers just love to program so much that they enjoy repeating the same task over and over again simply to stay current with the latest version of the game instead of programming something new and original that extends the game. I guess you love whiny little snits complaining on mod threads about the fact that some mod hasn't updated yet as well (in spite of being specifically against forum rules).
What I don't understand is why this thread has turned into a "let's dump on the concept of an API in the first place" thread. If you really hate the very idea of an API, why are you posting here? What we currently have is a very chaotic system of conflicting APIs and people pretty much doing whatever they want to do along with all of the problems I outlined above.
Regardless, all of this dumping on the concept of an API does nothing to help EvilSeph get the feedback he wants, other than to throw in the towel and say the whole idea of an API is getting so much resistance that it shouldn't be done at all. If you want to use MCP (or something like it) and directly modify the game outside of the API, nobody is stopping you. I just promise you that nobody will use your mods once the official API is out, or at least it will be a very small minority in the overall Minecraft extension developer community.
The current system is that there is no feedback from those who want to made plug-ins/mods to the Mojang developer staff, and the other alternative is simply creating an API of your own and doing the sort of hurry up and everybody screaming that you haven't got it done yet kind of thing that Risugami is getting right now.
Version 2.1 now updated for MC 1.6.2
I share your fears, though I think it will be the issues in JIRA which will become overwhelming. However, if pull requests can work for Linux, they can certainly work for Minecraft! I believe the Linux kernel is managed by having separate (trusted) maintainers for different portions of the kernel. Pull requests are given to the maintainers, not Linus. Linus then only needs to pull from his few maintainers.
The question is whether the developers have the experience and discipline to establish and maintain an effective process, and to evolve that process as necessary. I have seen larger teams with far fewer issues utterly fail in this regard.
I strongly recommend establishing a process for quickly triaging newly created issues. Those with insufficient description or simply poor proposals must be rejected right away, otherwise they will pile up and become overwhelming. Atlassian (makers of JIRA) have a recent blog post with some interesting ideas.
JIRA allows the default assignee to be set per-component, so that could provide some easy division of labor.
Enabling voting in JIRA (the default) would also provide an easy way for developers to see what is very important to the community.
If JIRA's GreenHopper plugin is installed, I recommend setting up a Rapid Board so the community can see what's being worked on / expected to be worked on soon. The Scrum-style board seems a natural fit to Minecraft's weekly snapshots (i.e. weekly iterations), but the Kanban-style board would work well too.
I also recommend the developers have some way to indicate issues which they are prepared to work on themselves, versus those they would like community input on. Perhaps a custom field, or maybe simply some status. I suppose there is also nothing to prevent Mojang from giving some / all users the ability to be assigned to issues, so some of the work can be directly farmed out to the community. Of course this will still require a pull request and a review by Mojang. As you suggested, perhaps some trusted community members could also be granted the ability to triage the issues.
Yes I know, I probaly just got put as #1 on the to-kill list of the MC Community. I spoke my mind, that's all
It's not time to submit your ideas yet. This is just a discussion of how idea submissions will be handled. Once that's ironed out, a site will be created where you can submit your ideas.
http://www.youtube.com/user/sidorakh
no no no!!! I learned java, the api will no doubt be based around java and thus modding will be the same, but with less work compiling and decompiling.
Examples:
Terrain generation in the core, each biome (1st and 3rd party) as a seperate plugin that can be turned on or off with a GUI or config file.
Mob spawning in the core, each mob (1st and 3rd party) as a seperate plugin that can be turned on or off with a GUI or a config file.
As far as the initial proposal in the OP, that methodology seems pretty par the course for a project like this. That said, I would encourage some sort of vetting process on future discussion threads for keeping out the riff raff that can't differentiate between an object-oriented language and qBasic.
Other then that it looks good
Everything I write is just an opinion, but I have some experience desiging software interfaces, so if you disagree with anything I write - please explain what you disagree with, and why, and what is your counter-suggestion.
There are two separate issues:
1. The mod loader - a feature that has to be build-in into minecraft, and perform the same basic function as the ModLoader or other similar mods. It has to provide the user with functionality to select from a list of available mods (already downloaded to a certain directory, maybe downloading them from a pre-configured location as well), select which mods the user wants to use, make sure there are no incompatibilities, and start the game. The mod loader must also provide the mods with block and item IDs - mods should use "local" IDs, which are mapped to global IDs during mod loading.
2. The modding API itself - a piece of code *specification* (that is, java interfaces) and instructions on how to compile/package them, so the mod loader is able to use them. This is the biggest part of the work.
Modding API must provide the mod with access to "the rest of the world".
I can see at least the following mod features:
- New block - the modder should provide the basic block type (translucent/glass-like/stone/etc), texture ID (with option to include the images in the mod itself), how it interacts with the player (which tools affect it, and how, which items/mobs are dropped if a tool is applied to it, how the tools are used/damaged, etc)
- New Item - which types of blocks and mobs it affects, and how (for example a 'placeable block' item's right-click interaction is creating a block there, and reducing the inventory count by 1)
- New mob - how it interacts with each mob and block type, etc
Note that if there are two mods, one providing block B, and another providing tool T there can't be code defining their relation.
Assuming (arbitrarily, I admit) that there are less items types then there are blocks, the game core will execute T's effect as it's define for the base block on B.
Assuming that many of the new features in a mod will behave in many ways identically to existing features, the API must provide all the default behaviour "out of the box". The easiest way to achieve this is to have hierarchies.
Block types: completely static (no need to check during ticks), liquids, affected by gravity, affected by redstone, affected by proximity, need occasional updates (furnace, leafs, etc)
For example, simplest kind of mod I can think of is a new decorative block. The modder should just inherit the completely static block type, provide the texture, and be done.
Most of minecraft's core features should also be rewritten as a mod. this mod will be bundled as a part of minecraft.jar and always loaded by the mod loader.
There are other important features that I want to write my about later:
- Other aspects for the game which should be moddable: world generation (including other dimentions), weather, physics, GUI
- Mods conflict, and how mod loader detects them and avoids loading conflicting mods
- modifying/removing existing blocks/items/mobs (may be the major reason for the conflicts).
- Types of block interaction (for example, a few existing mods have the concent of 'mechanical power' which ideally should be transfered to blocks of other mods, in the same way redstone is transfered - but it has to be somehow done through the API.
Please let me know if I'm barking up the right tree, and if so - I would like to keep revisioning my opinions, improving them based on relevant comments - and hopefuly eventually come up with a useful set of MAPs.