Searge was definitely hired for this purpose. I'll also say I heard directly from someone who isn't supposed to say much about it that Searge's work would drastically change how we discover, install, and play mods.
That leads me to think it's going to be fully-integrated into MC like with Steam Workshop. Assuming the team does a good job with the API, it's going to make it a lot easier for mod devs to update their stuff to new versions, too.
Sounds like it's worth waiting for.
Agreed 100% - worth waiting for regardless of how it works.
However, Mojang's lack of communication (shutting down all API sites, no updates, etc.) is not the best way to go about things. They need to support and communicate with the modders out there who have greatly helped Minecraft become the success it is today.
Just a little hint, not mutch.
We have been told, that the sizes on the modells are floats, not integers(after it was discovered, i think Grum, not sure)
Fiddle around with the new snapshots, you may find something whats never told, tell them that you found this, they will tell you what you need to know.
Explain what they will tell us that you know and no one in here seems to know.
Rollback Post to RevisionRollBack
I was trying to think of a signature and this is what came up.
theory is that the inventory re write is for the plugin API.
I dont understand why, but it makes some sense in how dynamic items can be stored now.
Alot of the inventory changes are not actual visual changes and more of something that you wont even notice.
could this possibly be for the plugin API?
its a theory
Yes for the API, as Dinnerbone keeps mentioning in tweets and sometimes when snapshots are released.
Makes no difference what they're doing - every mod out there is about to break and will need to be recoded.
It does make a difference when though, so modders aren't wasting their time recoding their mods twice back-to-back - that's why I think Mojang should give everyone some sort of an idea when it will come out, and not put modders in that position.
Mojang just doesn't have the staff to do things in a timely manner. Hiring Searge is great, but he's only capable of so much just like everyone else.
Find something first. I still just can come with the example above. The coordinates wasn't integers with 16 being the whole block (now it is), and we have been told.
As i said, find something. Search.
Right. Your fudge tactics just won't work. You are -- it seems you have forgotten -- talking with actual intelligent people. Not the gullible you apparently deal with in a daily basis, if you expect that weak attempt of yours to work.
There's nothing to search for, because there is nothing that has been told about those particular changes in relation to the Plugin API that will calm the doubts expressed in this thread. You are just essentially forging evidence by giving the false idea that we are not in possession of all the information. Let me tell you son, there's very little (and possibly nothing at all) you can tell us that we don't know already about Mojang work on Minecraft.
So now, please, leave us adults to the conversation and you go try fool someone else in another neighborhood. Because at least in here, even those that may disagree do it with with respect and don't try to forge evidence to support their arguments.
Find something first. I still just can come with the example above. The coordinates wasn't integers with 16 being the whole block (now it is), and we have been told.
As i said, find something. Search.
I think you are missing the point here Frontrider . Mod dev's should not have to search and fumble to find what they need, nor should Mojang provide us with a bible on how to do things.
Mod dev's are bright people, they'll figure things out, but this cannot be done with just 'we're working on it'. That's not enough, and Mojang is shooting themselves in the foot being secretive like they are - that's never good for any company and they are taking away the confidence of a lot of people that support them.
As mentioned in previous posts, Mojang should tap into the community and get those bright minds to help them out - people will do that for free because the enjoy it and support Mojang.
What support has Mojang given to them? Right - they've changed the code so many times and wasted so much time of so many people because we're doing exactly what you asked - we're searching for answers that are just not there.
The API is supposed to abstract the underlying code so we don't have to search or recode our mods every time they fix something - that's the point.
Well, aswering to the topic: Yes it is in development, and you are probably already using it.
We have Resource Packs and Shaders that is the proof that it is in development. Also, if you work with command Blocks, you can notice some hints of it like minecraft.stone (that's an example, and yes, i know that that is not precise).
No. A side effect for ordinary Minecraft players and server owners is that a "mod" or extended content created by 3rd parties can be added to Minecraft by simply dropping them into a folder like you do texture packs at the moment. Even better, these "mods" or plug-ins will work for multiple versions of Minecraft... so you won't need to wait for mod developers to update each time Mojang updates Minecraft.
The main point of the API though is to help people who write these plug-ins and mods to be able to write the changes and things they want without having to rewrite core parts of the game.
Either way, I'm confused where all these Mojang "experts" are coming from and am curious what hidden secret insider knowledge they have that can be shared with us.
Some people have actually decompiled the source code for Minecraft and understand how to program in Java. That isn't exactly secret insider knowledge, but not everybody has the time to read every tweet and Reddit post made by Mojang staff either.... although surprisingly some people do take that kind of time.
That isn't a dark secret, but it does take some people with experience. Please enlighten us with your arcane knowledge about this subject to which you have so eloquently written.
I just found something interesting; I decided to see what Beta 1.0 was like and I noticed this on the title screen (third button):
So, it really does look like they had been planning on a mod/plugin API for a LONG time now... Beta 1.0 was over three years ago... and still no real results (i.e. an actual working API).
(That said, exactly what did "Mods" mean here; did the game try to load in class files placed in a folder, if only replacing base classes? Clicking the button just gives me a texture pack selection screen)
Instead of searching the update bullet points for the string "API", try reading between the bullet points. There have been changes that clearly show work on the Mod API in every 14w-- snapshot so far (save for the latest one, 14w08?) - and if you'd look a little harder, I honestly think they should be readily apparent to anyone with a programming background.
Why do you think there are so many new commands, just to amuse map-makers and give Sethbling new material? They don't have to explicitly state that something is part of the API because they'd copy paste that statement five times per snapshot.
Examples: Clone and Fill commands and Testforblocks can be used together as core functions for creating multi-block structures. Allowing dataTags in the summon command also means that various aspects of summoning mobs can be tested and bug-fixed before releasing the first version of the API. The same goes for allowing more complex dataTags on items, or on setblock, or allowing the nesting of dataTags (dataTags on an item that is part of the DataTag for a chest or a mob, for example).
Especially: The /execute command will obviously be very important to mod developers when it comes time to summon projectile entities from a custom weapon, as well as uses too multitudinous to enumerate here. The ability to target any entity with @selectors is clearly majorly important when a mod developer wants to change the properties of an entity on use of a given item or under certain circumstances. Having players bug-find pre-API in regards to the new scoreboard functions that essentially serve as the most open-ended variable tracking system available to developers is crucial. Need I really go on?
All of these changes to commands clearly indicate changes to the way the internal code actually works and the necessity of allowing that code (which will obviously be VERY important to mod developers to get maximum functionality) to be tested and bug-fixed BEFORE the release of the first public version of the API.
Yes, they are working on the Mod API. To imply otherwise is simply short-sighted, or perhaps ignorant, or perhaps misinformed.
For even more evidence, look no further than the 14w08 snapshot news post on the front page:
Mojang has been working on major rewrites (inventories/menus/block models) for the upcoming API still, but here’s a bugfixy snapshot in the meantime!
Okay, so what has changed about inventories, menus, or block models in the last handful of snapshots? Inventories: In 14w07a, the following two changes are significant examples:
BlockItem instances can now hold a custom NBT tag that is merged into a block entity when it’s placed In creative mode, players can create a copy of a BlockEntity in their hotbar, including all NBT data, with ctrl+[PICK_KEY] (usually ctrl+middle mouse button)
This means that a technically unlimited amount of data can be stored in inventory spaces (within the confines of Java and/or your machine), as well as transferred to a block when placed in the world. If I have to explain the implications further, you honestly have no right to assume anything about the Mod API.
Block Models: In 14w06a, the ability was added to define irregular block model shapes using resource packs. This is obviously a test-run for part of the API that defines block models for added mod blocks.
The features listed above are not just "new additions" to Minecraft. ALL of them involve significant rewrites of the code and they point in only one direction: "Features" that are added for the sole purpose of testing Mod API functionality.
I hope I don't come off as rude, but I don't see how anyone who knows what they're talking about could possibly imagine that the API is not being worked on. The implications of changes even just from 14w01 had the coding portion of my mind racing.
In closing, keep this in mind:A new command or feature does not have to be activated by complex code or be a direct interface into the core of the application to be calling functions that were developed or re-coded solely for the purpose of giving Mod developers more flexibility. Please tell me you understand that?
Rollback Post to RevisionRollBack
▲▲ 6,000+ subs looking for Creators with 2k+ to collab - Click to visit my channel! ▲▲
Why do you think there are so many new commands, just to amuse map-makers and give Sethbling new material? They don't have to explicitly state that something is part of the API because they'd copy paste that statement five times per snapshot.
If the API gets accessed through a home-brew interpreted language (which is what the command line is), it will be an unmitigated disaster because of terrible performance.
The attached NBT tag would certainly be useful for modding. I just had to give up on an option to place the variant stone stairs from my add-on to Underground Biomes in villages precisely because there's no good way to send the NBT tag through the Forge hook for changing blocks.
The issue is not so much whether the API is being "worked on". It's been "worked on" for 4 years now - things like the SSP/SMP merge are certainly relevant - but still no API. The question is, how much longer do we wait?
Incidentally, an API does not have to be released entire. You can *add* to an API without any problems. The problems happen if you *change* it although generally speaking even a wobbly API would be an improvement over the current situation. But, for example, they could put out the API for block access, probably right now, and that would mean that at least block access could be written in final, stable form by modders right now. Again, a big improvement over the current situation.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
The issue is not so much whether the API is being "worked on". It's been "worked on" for 4 years now - things like the SSP/SMP merge are certainly relevant - but still no API. The question is, how much longer do we wait?
Exactly! I'd rather spend my time adding/expanding to my mods instead of recoding them every time a major update is released.
If Mojang is just now really digging into this with their 2 recent new hires, then the wait will be substantial and the advancement of modding will kind of be at a standstill until they do release.
It's a shame that company Pres. Carl Manneh didn't do something about this a long time ago, and I can only imagine the pressure that Dinnerbone, Jeb, etc. are under to get this done.
So now the lead of MCP has been brought onboard, which likely means no new advances - we're probably stuck at 1.7.2 for a while.
Instead of searching the update bullet points for the string "API", try reading between the bullet points. There have been changes that clearly show work on the Mod API in every 14w-- snapshot so far (save for the latest one, 14w08?) - and if you'd look a little harder, I honestly think they should be readily apparent to anyone with a programming background.
Have you considered that people have read between the lines, as you put it, and simply come to a different conclusion? Many people in this thread have programming backgrounds and Minecraft modding experience specifically, and they've laid out arguments doing exactly that.
Examples: Clone and Fill commands and Testforblocks
-- are poor substitutes for even the most basic loops and conditionals already built into the Java language. Then there are the IDEs, debuggers, profilers, tons of third-party libraries, and a knowledge base that come with the language. Say, if only there were a way for modders to use such well-established tools and save Mojang the trouble of reinventing the wheel. Some sort of "interface" for "programmers" to develop "applications".
Especially: The /execute command will obviously be very important to mod developers when it comes time to summon projectile entities from a custom weapon, as well as uses too multitudinous to enumerate here. The ability to target any entity with @selectors is clearly majorly important when a mod developer wants to change the properties of an entity on use of a given item or under certain circumstances.
Again you're describing stuff that is natural to express in Java. All I need is a way to bridge the gap between my code and theirs. I don't need or want this ad hoc, looks-like-CSS-tripped-and-fell-on-a-belt-sander command block language.
All of these changes to commands clearly indicate changes to the way the internal code actually works and the necessity of allowing that code (which will obviously be VERY important to mod developers to get maximum functionality) to be tested and bug-fixed BEFORE the release of the first public version of the API.
Yes, we know Mojang is making internal changes to the way the code works. I've been updating my mod for the 1.8 snapshots, so I'm well aware of what those changes are. What I claim is that they are mostly incidental or outright irrelevant to having a useable Java programming interface in modders' hands sometime this decade.
This means that a technically unlimited amount of data can be stored in inventory spaces (within the confines of Java and/or your machine), as well as transferred to a block when placed in the world. If I have to explain the implications further, you honestly have no right to assume anything about the Mod API.
Other than killing performance by turning every block into a potential tile entity? Can this add entirely new blocks with their own IDs, recipes, textures, material properties, etc., etc. to the game? What about new mobs, new biomes, new dimensions, new weather patterns, new cave generation, new AI? Are modders any closer to doing any of that than they were four years ago?
Block Models: In 14w06a, the ability was added to define irregular block model shapes using resource packs. This is obviously a test-run for part of the API that defines block models for added mod blocks.
As explained earlier, the old block rendering system is still in the code and will likely never go away. The new system can't feasibly represent dynamic blocks like glass panes, fences, or flowing liquids. Block models are great news for artists who don't write code, but they aren't needed for an API.
In fact, if we had an API that exposed the existing block rendering system, modders could have built their own model data format on top of it. Same goes for command blocks actually. An API would allow either Mojang or the community to build them as a separate plugin. Especially for a team as small as Mojang's, it's simply unbelievable that they're putting so much time and effort into these distractions.
-- are poor substitutes for even the most basic loops and conditionals already built into the Java language. Then there are the IDEs, debuggers, profilers, tons of third-party libraries, and a knowledge base that come with the language. Say, if only there were a way for modders to use such well-established tools and save Mojang the trouble of reinventing the wheel. Some sort of "interface" for "programmers" to develop "applications".
Again you're describing stuff that is natural to express in Java. All I need is a way to bridge the gap between my code and theirs. I don't need or want this ad hoc, looks-like-CSS-tripped-and-fell-on-a-belt-sander command block language.
Yes, we know Mojang is making internal changes to the way the code works. I've been updating my mod for the 1.8 snapshots, so I'm well aware of what those changes are. What I claim is that they are mostly incidental or outright irrelevant to having a useable Java programming interface in modders' hands sometime this decade.
I don't think you get what I am saying. Simply allowing access to the current block model system for example may not work because perhaps it is only able to handle certain kinds of models. It doesn't matter what you build on top of it when you're calling a function that only accepts a handle to define whether it's cubic, 1/8 increments, or stairs. Now to be fair I haven't dabbled in the source code (waiting for the API, personally), but isn't it better to have fully-featured functions? Before 1.8, was it possible to have a block model that is transparent on the outside with a non-opaque core (slime blocks) without having to rewrite the block model function that everything in the game and every mod-to-be relies on? The point of the API is to allow for expansion on the game without a modder having to change those core functions. If things mod developers want to do are impossible, you'll wind up with a split in the developer community - one side deals with the limitations of the Mod API and the other side says "Screw it" and continues to modify the source code (making the two schools of mods incompatible with each other).
Other than killing performance by turning every block into a potential tile entity? Can this add entirely new blocks with their own IDs, recipes, textures, material properties, etc., etc. to the game? What about new mobs, new biomes, new dimensions, new weather patterns, new cave generation, new AI? Are modders any closer to doing any of that than they were four years ago?
As explained earlier, the old block rendering system is still in the code and will likely never go away. The new system can't feasibly represent dynamic blocks like glass panes, fences, or flowing liquids. Block models are great news for artists who don't write code, but they aren't needed for an API.
In fact, if we had an API that exposed the existing block rendering system, modders could have built their own model data format on top of it. Same goes for command blocks actually. An API would allow either Mojang or the community to build them as a separate plugin. Especially for a team as small as Mojang's, it's simply unbelievable that they're putting so much time and effort into these distractions.
How do you eat an elephant?
One byte at a time.
"Distractions"? Mojang continues to add new content to vanilla minecraft because vanilla players want that. They continue working on the API because the mod-using/developing community wants that. How fast do you want "a team as small as Mojang's" to get finished?
My entire post was based on only what I saw on the first page, since I have other things to do than read 11 pages of bickering between people with some knowledge and people who are blissfully ignorant. You may be someone more "in the know" than many, but you missed the entire point of my post: I didn't say that it was coming soon or that it was their primary focus or that they're making lots of progress or even doing a good job. I only wanted to affirm that Yes, it is still being worked on, and no number of topics asking whether it's being worked on will make it happen any faster. You have pretty decent points and I don't necessarily disagree with you but your post is only relevant to the OP tangentially at best - the topic creator asked if it was being worked on. I think you actually agree with me that slowly but surely work is being done on it. Remember this is Mojang we're talking about - how long did it take them to actually release Minecraft 1.0? And now they've hired yet another hand who I infer from this topic is intended primarily to work on the API - oh, and who also added the /execute command that I mentioned in my previous post.
Rollback Post to RevisionRollBack
▲▲ 6,000+ subs looking for Creators with 2k+ to collab - Click to visit my channel! ▲▲
As explained earlier, the old block rendering system is still in the code and will likely never go away. The new system can't feasibly represent dynamic blocks like glass panes, fences, or flowing liquids. Block models are great news for artists who don't write code, but they aren't needed for an API.
In fact, if we had an API that exposed the existing block rendering system, modders could have built their own model data format on top of it. Same goes for command blocks actually. An API would allow either Mojang or the community to build them as a separate plugin. Especially for a team as small as Mojang's, it's simply unbelievable that they're putting so much time and effort into these distractions.
You and many others on this thread act like you know everything about the API but in actually fact many of you don't even know the basic requirements for the API stated by Mojang many times like there can't be any client side plugin code. So the new system has to be able represent those dynamic block models(I can see how they are probable planning to do it within the block model json files) and the block models are required for API.
I think they are slowly working on the API, they want to do the API properly so it is fast(performance wise) and powerful and doesn't break with every update like forge and bukkit(which are hacked together as they can't distribute minecraft.jar). I think they don't mind that much that it is taking this long as they know when it is released, if good it will bring a lot of players back/attract new players. Although i wish they tell us more information like there road map(what they sill need to do) and some specifics about the API.
You and many others on this thread act like you know everything about the API but in actually fact many of you don't even know the basic requirements for the API stated by Mojang many times like there can't be any client side plugin code. So the new system has to be able represent those dynamic block models(I can see how they are probable planning to do it within the block model json files) and the block models are required for API.
That is not a requirement for the API, even if it may be a goal for Mojang. The issue you are talking about is for players who want to join a server and face problems connecting to that server if they lack a given client-side plug-in at the same time. Minecraft players have been working with the current need for client-side mods/plug-ins for many servers so I don't see that as a hard requirement.
In many ways it seems like some folks such as yourself are over thinking all of the technical requirements needed for the API. A goal like this is a nice piece of polish and makes the API incredibly useful, as well as simplifying the experience for novice players who may not want to mess with installing plug-ins themselves, but it most definitely is not necessary for the API. The new system (or even the need for a new system) certainly does not need anything you are suggesting here. I'm not saying this shouldn't happen, but it is not necessary for a proper API and certainly not needed for a basic API to get the mod community away from cracking open the minecraft.jar file as has been happening until now.
I think they are slowly working on the API, they want to do the API properly so it is fast(performance wise) and powerful and doesn't break with every update like forge and bukkit(which are hacked together as they can't distribute minecraft.jar). I think they don't mind that much that it is taking this long as they know when it is released, if good it will bring a lot of players back/attract new players. Although i wish they tell us more information like there road map(what they sill need to do) and some specifics about the API.
What breaks with every update is the obfuscation that Mojang insists upon when they distribute the minecraft.jar file. Even then, it only breaks when the class names change as a result of adding a new class or having the obfuscation shift around a bit more unpredictably.
Again, I think you are way over thinking what is really needed for at least the kernel and start of an API. It certainly doesn't need to be a full featured set of interfaces at the beginning and should be something seen as a work in progress by itself... and at the moment there isn't even a kernel of an API to suggest what it is that Mojang is even working on.
I'll admit that I don't know what the final API is going to look like for Minecraft, but I do know a thing or two about API architectures (having written a few myself) and at the moment Minecraft has almost nothing in terms of an API of any kind other than what the mod community has developed. The point of this thread is to even go so far as to suggest Mojang hasn't even realistically started any sort of API development work of any kind and really doesn't have a clear roadmap in terms of what they want the API to eventually look like.
An API for 3rd party content developers seeking to extend Minecraft is a definite long-term goal, and the Mojang staff (including Notch) certainly understand that the modding community is a key part of their success, but converting that support from the modding community into a more mainstream supported experience for novice players through a plug-in API needs some more attention and something that currently seems lacking almost to the point of not even really existing at the moment. It certainly seems like previous attempts at creating the API have been completely abandoned so at this point it can at best be considered a blank sheet of paper with the words "Plugin API" written at the top is all that currently exists.
That is not a requirement for the API, even if it may be a goal for Mojang. The issue you are talking about is for players who want to join a server and face problems connecting to that server if they lack a given client-side plug-in at the same time. Minecraft players have been working with the current need for client-side mods/plug-ins for many servers so I don't see that as a hard requirement.
Mojang stated they won't support client-sided plugins only assets client-side due to a security risk of code. So there is no "client-side plug-in" the client can have, outside modding. So for the API to support a block like glass panes or even an anvil they do need the block models.
Personally i think having client-side plugins would be better, but for mojang to achieve the API theywant they need block models.
What breaks with every update is the obfuscation that Mojang insists upon when they distribute the minecraft.jar file. Even then, it only breaks when the class names change as a result of adding a new class or having the obfuscation shift around a bit more unpredictably.
Again, I think you are way over thinking what is really needed for at least the kernel and start of an API. It certainly doesn't need to be a full featured set of interfaces at the beginning and should be something seen as a work in progress by itself... and at the moment there isn't even a kernel of an API to suggest what it is that Mojang is even working on.
Yes forge and bukkit break every update because of obfuscation as well as changes in the underlying code so they are baseing there API off code that can change so therefore the API will break every update. By "hacked together" i mean is how they patch the minecraft.jar. It would be very hard to produce a full-functional consistent API under those circumstances by the community.
I think mojang doesn't want to release a small API at first and then take ages to expand on it because they are reworking the code, i think they want to do the reworking first, at least that how it seems.
During the minecon 2012 plugin API panel they stated they won't support client-sided plugins only assets client-side due to a security risk of code. So there is no "client-side plug-in" the client can have, outside modding. So for the API to support a block like glass panes or even an anvil they do need the block models.
Personally i think having client-side plugins would be better, but for mojang to achieve the API theywant they need block models.
I think mojang doesn't want to release a small API at first and then take ages to expand on it because they are reworking the code, i think they want to do the reworking first, at least that how it seems.
If Mojang isn't going to put out an API unless it's server-only and complete, then we'll never see it. It can't be done. Minecraft is at its core a SSP game and they would really have to rewrite everything to do it all server-side. And worse, Minecraft is a demanding game and the server is not going to be able to do it all. They could, in a reasonable length of time, release a universal API which is relatively complete; or they could release a limited API which works server-side. But not both.
Agreed 100% - worth waiting for regardless of how it works.
However, Mojang's lack of communication (shutting down all API sites, no updates, etc.) is not the best way to go about things. They need to support and communicate with the modders out there who have greatly helped Minecraft become the success it is today.
Explain what they will tell us that you know and no one in here seems to know.
I dont understand why, but it makes some sense in how dynamic items can be stored now.
Alot of the inventory changes are not actual visual changes and more of something that you wont even notice.
could this possibly be for the plugin API?
its a theory
Makes no difference what they're doing - every mod out there is about to break and will need to be recoded.
It does make a difference when though, so modders aren't wasting their time recoding their mods twice back-to-back - that's why I think Mojang should give everyone some sort of an idea when it will come out, and not put modders in that position.
Mojang just doesn't have the staff to do things in a timely manner. Hiring Searge is great, but he's only capable of so much just like everyone else.
Right. Your fudge tactics just won't work. You are -- it seems you have forgotten -- talking with actual intelligent people. Not the gullible you apparently deal with in a daily basis, if you expect that weak attempt of yours to work.
There's nothing to search for, because there is nothing that has been told about those particular changes in relation to the Plugin API that will calm the doubts expressed in this thread. You are just essentially forging evidence by giving the false idea that we are not in possession of all the information. Let me tell you son, there's very little (and possibly nothing at all) you can tell us that we don't know already about Mojang work on Minecraft.
So now, please, leave us adults to the conversation and you go try fool someone else in another neighborhood. Because at least in here, even those that may disagree do it with with respect and don't try to forge evidence to support their arguments.
I think you are missing the point here Frontrider . Mod dev's should not have to search and fumble to find what they need, nor should Mojang provide us with a bible on how to do things.
Mod dev's are bright people, they'll figure things out, but this cannot be done with just 'we're working on it'. That's not enough, and Mojang is shooting themselves in the foot being secretive like they are - that's never good for any company and they are taking away the confidence of a lot of people that support them.
As mentioned in previous posts, Mojang should tap into the community and get those bright minds to help them out - people will do that for free because the enjoy it and support Mojang.
What support has Mojang given to them? Right - they've changed the code so many times and wasted so much time of so many people because we're doing exactly what you asked - we're searching for answers that are just not there.
The API is supposed to abstract the underlying code so we don't have to search or recode our mods every time they fix something - that's the point.
Link RemovedWIP 128x 64x, SEUS support, Mod support in the pipeline TEKKIT, FTB, the more support the more mods!
We have Resource Packs and Shaders that is the proof that it is in development. Also, if you work with command Blocks, you can notice some hints of it like minecraft.stone (that's an example, and yes, i know that that is not precise).
I can't see the point of these topics.
So, will it allow you to install mods?
Link RemovedWIP 128x 64x, SEUS support, Mod support in the pipeline TEKKIT, FTB, the more support the more mods!
No. A side effect for ordinary Minecraft players and server owners is that a "mod" or extended content created by 3rd parties can be added to Minecraft by simply dropping them into a folder like you do texture packs at the moment. Even better, these "mods" or plug-ins will work for multiple versions of Minecraft... so you won't need to wait for mod developers to update each time Mojang updates Minecraft.
The main point of the API though is to help people who write these plug-ins and mods to be able to write the changes and things they want without having to rewrite core parts of the game.
Some people have actually decompiled the source code for Minecraft and understand how to program in Java. That isn't exactly secret insider knowledge, but not everybody has the time to read every tweet and Reddit post made by Mojang staff either.... although surprisingly some people do take that kind of time.
That isn't a dark secret, but it does take some people with experience. Please enlighten us with your arcane knowledge about this subject to which you have so eloquently written.
Version 2.1 now updated for MC 1.6.2
So, it really does look like they had been planning on a mod/plugin API for a LONG time now... Beta 1.0 was over three years ago... and still no real results (i.e. an actual working API).
(That said, exactly what did "Mods" mean here; did the game try to load in class files placed in a folder, if only replacing base classes? Clicking the button just gives me a texture pack selection screen)
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Why do you think there are so many new commands, just to amuse map-makers and give Sethbling new material? They don't have to explicitly state that something is part of the API because they'd copy paste that statement five times per snapshot.
Examples: Clone and Fill commands and Testforblocks can be used together as core functions for creating multi-block structures. Allowing dataTags in the summon command also means that various aspects of summoning mobs can be tested and bug-fixed before releasing the first version of the API. The same goes for allowing more complex dataTags on items, or on setblock, or allowing the nesting of dataTags (dataTags on an item that is part of the DataTag for a chest or a mob, for example).
Especially: The /execute command will obviously be very important to mod developers when it comes time to summon projectile entities from a custom weapon, as well as uses too multitudinous to enumerate here. The ability to target any entity with @selectors is clearly majorly important when a mod developer wants to change the properties of an entity on use of a given item or under certain circumstances. Having players bug-find pre-API in regards to the new scoreboard functions that essentially serve as the most open-ended variable tracking system available to developers is crucial. Need I really go on?
All of these changes to commands clearly indicate changes to the way the internal code actually works and the necessity of allowing that code (which will obviously be VERY important to mod developers to get maximum functionality) to be tested and bug-fixed BEFORE the release of the first public version of the API.
Yes, they are working on the Mod API. To imply otherwise is simply short-sighted, or perhaps ignorant, or perhaps misinformed.
For even more evidence, look no further than the 14w08 snapshot news post on the front page:
Okay, so what has changed about inventories, menus, or block models in the last handful of snapshots?
Inventories: In 14w07a, the following two changes are significant examples:
This means that a technically unlimited amount of data can be stored in inventory spaces (within the confines of Java and/or your machine), as well as transferred to a block when placed in the world. If I have to explain the implications further, you honestly have no right to assume anything about the Mod API.
Block Models: In 14w06a, the ability was added to define irregular block model shapes using resource packs. This is obviously a test-run for part of the API that defines block models for added mod blocks.
The features listed above are not just "new additions" to Minecraft. ALL of them involve significant rewrites of the code and they point in only one direction: "Features" that are added for the sole purpose of testing Mod API functionality.
I hope I don't come off as rude, but I don't see how anyone who knows what they're talking about could possibly imagine that the API is not being worked on. The implications of changes even just from 14w01 had the coding portion of my mind racing.
In closing, keep this in mind: A new command or feature does not have to be activated by complex code or be a direct interface into the core of the application to be calling functions that were developed or re-coded solely for the purpose of giving Mod developers more flexibility. Please tell me you understand that?
▲▲ 6,000+ subs looking for Creators with 2k+ to collab - Click to visit my channel! ▲▲
If the API gets accessed through a home-brew interpreted language (which is what the command line is), it will be an unmitigated disaster because of terrible performance.
The attached NBT tag would certainly be useful for modding. I just had to give up on an option to place the variant stone stairs from my add-on to Underground Biomes in villages precisely because there's no good way to send the NBT tag through the Forge hook for changing blocks.
The issue is not so much whether the API is being "worked on". It's been "worked on" for 4 years now - things like the SSP/SMP merge are certainly relevant - but still no API. The question is, how much longer do we wait?
Incidentally, an API does not have to be released entire. You can *add* to an API without any problems. The problems happen if you *change* it although generally speaking even a wobbly API would be an improvement over the current situation. But, for example, they could put out the API for block access, probably right now, and that would mean that at least block access could be written in final, stable form by modders right now. Again, a big improvement over the current situation.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Exactly! I'd rather spend my time adding/expanding to my mods instead of recoding them every time a major update is released.
If Mojang is just now really digging into this with their 2 recent new hires, then the wait will be substantial and the advancement of modding will kind of be at a standstill until they do release.
It's a shame that company Pres. Carl Manneh didn't do something about this a long time ago, and I can only imagine the pressure that Dinnerbone, Jeb, etc. are under to get this done.
So now the lead of MCP has been brought onboard, which likely means no new advances - we're probably stuck at 1.7.2 for a while.
Have you considered that people have read between the lines, as you put it, and simply come to a different conclusion? Many people in this thread have programming backgrounds and Minecraft modding experience specifically, and they've laid out arguments doing exactly that.
-- are poor substitutes for even the most basic loops and conditionals already built into the Java language. Then there are the IDEs, debuggers, profilers, tons of third-party libraries, and a knowledge base that come with the language. Say, if only there were a way for modders to use such well-established tools and save Mojang the trouble of reinventing the wheel. Some sort of "interface" for "programmers" to develop "applications".
Again you're describing stuff that is natural to express in Java. All I need is a way to bridge the gap between my code and theirs. I don't need or want this ad hoc, looks-like-CSS-tripped-and-fell-on-a-belt-sander command block language.
Yes, we know Mojang is making internal changes to the way the code works. I've been updating my mod for the 1.8 snapshots, so I'm well aware of what those changes are. What I claim is that they are mostly incidental or outright irrelevant to having a useable Java programming interface in modders' hands sometime this decade.
Other than killing performance by turning every block into a potential tile entity? Can this add entirely new blocks with their own IDs, recipes, textures, material properties, etc., etc. to the game? What about new mobs, new biomes, new dimensions, new weather patterns, new cave generation, new AI? Are modders any closer to doing any of that than they were four years ago?
As explained earlier, the old block rendering system is still in the code and will likely never go away. The new system can't feasibly represent dynamic blocks like glass panes, fences, or flowing liquids. Block models are great news for artists who don't write code, but they aren't needed for an API.
In fact, if we had an API that exposed the existing block rendering system, modders could have built their own model data format on top of it. Same goes for command blocks actually. An API would allow either Mojang or the community to build them as a separate plugin. Especially for a team as small as Mojang's, it's simply unbelievable that they're putting so much time and effort into these distractions.
I don't think you get what I am saying. Simply allowing access to the current block model system for example may not work because perhaps it is only able to handle certain kinds of models. It doesn't matter what you build on top of it when you're calling a function that only accepts a handle to define whether it's cubic, 1/8 increments, or stairs. Now to be fair I haven't dabbled in the source code (waiting for the API, personally), but isn't it better to have fully-featured functions? Before 1.8, was it possible to have a block model that is transparent on the outside with a non-opaque core (slime blocks) without having to rewrite the block model function that everything in the game and every mod-to-be relies on? The point of the API is to allow for expansion on the game without a modder having to change those core functions. If things mod developers want to do are impossible, you'll wind up with a split in the developer community - one side deals with the limitations of the Mod API and the other side says "Screw it" and continues to modify the source code (making the two schools of mods incompatible with each other).
How do you eat an elephant?
One byte at a time.
"Distractions"? Mojang continues to add new content to vanilla minecraft because vanilla players want that. They continue working on the API because the mod-using/developing community wants that. How fast do you want "a team as small as Mojang's" to get finished?
My entire post was based on only what I saw on the first page, since I have other things to do than read 11 pages of bickering between people with some knowledge and people who are blissfully ignorant. You may be someone more "in the know" than many, but you missed the entire point of my post: I didn't say that it was coming soon or that it was their primary focus or that they're making lots of progress or even doing a good job. I only wanted to affirm that Yes, it is still being worked on, and no number of topics asking whether it's being worked on will make it happen any faster. You have pretty decent points and I don't necessarily disagree with you but your post is only relevant to the OP tangentially at best - the topic creator asked if it was being worked on. I think you actually agree with me that slowly but surely work is being done on it. Remember this is Mojang we're talking about - how long did it take them to actually release Minecraft 1.0? And now they've hired yet another hand who I infer from this topic is intended primarily to work on the API - oh, and who also added the /execute command that I mentioned in my previous post.
▲▲ 6,000+ subs looking for Creators with 2k+ to collab - Click to visit my channel! ▲▲
You and many others on this thread act like you know everything about the API but in actually fact many of you don't even know the basic requirements for the API stated by Mojang many times like there can't be any client side plugin code. So the new system has to be able represent those dynamic block models(I can see how they are probable planning to do it within the block model json files) and the block models are required for API.
I think they are slowly working on the API, they want to do the API properly so it is fast(performance wise) and powerful and doesn't break with every update like forge and bukkit(which are hacked together as they can't distribute minecraft.jar). I think they don't mind that much that it is taking this long as they know when it is released, if good it will bring a lot of players back/attract new players. Although i wish they tell us more information like there road map(what they sill need to do) and some specifics about the API.
That is not a requirement for the API, even if it may be a goal for Mojang. The issue you are talking about is for players who want to join a server and face problems connecting to that server if they lack a given client-side plug-in at the same time. Minecraft players have been working with the current need for client-side mods/plug-ins for many servers so I don't see that as a hard requirement.
In many ways it seems like some folks such as yourself are over thinking all of the technical requirements needed for the API. A goal like this is a nice piece of polish and makes the API incredibly useful, as well as simplifying the experience for novice players who may not want to mess with installing plug-ins themselves, but it most definitely is not necessary for the API. The new system (or even the need for a new system) certainly does not need anything you are suggesting here. I'm not saying this shouldn't happen, but it is not necessary for a proper API and certainly not needed for a basic API to get the mod community away from cracking open the minecraft.jar file as has been happening until now.
What breaks with every update is the obfuscation that Mojang insists upon when they distribute the minecraft.jar file. Even then, it only breaks when the class names change as a result of adding a new class or having the obfuscation shift around a bit more unpredictably.
Again, I think you are way over thinking what is really needed for at least the kernel and start of an API. It certainly doesn't need to be a full featured set of interfaces at the beginning and should be something seen as a work in progress by itself... and at the moment there isn't even a kernel of an API to suggest what it is that Mojang is even working on.
I'll admit that I don't know what the final API is going to look like for Minecraft, but I do know a thing or two about API architectures (having written a few myself) and at the moment Minecraft has almost nothing in terms of an API of any kind other than what the mod community has developed. The point of this thread is to even go so far as to suggest Mojang hasn't even realistically started any sort of API development work of any kind and really doesn't have a clear roadmap in terms of what they want the API to eventually look like.
An API for 3rd party content developers seeking to extend Minecraft is a definite long-term goal, and the Mojang staff (including Notch) certainly understand that the modding community is a key part of their success, but converting that support from the modding community into a more mainstream supported experience for novice players through a plug-in API needs some more attention and something that currently seems lacking almost to the point of not even really existing at the moment. It certainly seems like previous attempts at creating the API have been completely abandoned so at this point it can at best be considered a blank sheet of paper with the words "Plugin API" written at the top is all that currently exists.
Version 2.1 now updated for MC 1.6.2
Mojang stated they won't support client-sided plugins only assets client-side due to a security risk of code. So there is no "client-side plug-in" the client can have, outside modding. So for the API to support a block like glass panes or even an anvil they do need the block models.
Personally i think having client-side plugins would be better, but for mojang to achieve the API they want they need block models.
Yes forge and bukkit break every update because of obfuscation as well as changes in the underlying code so they are baseing there API off code that can change so therefore the API will break every update. By "hacked together" i mean is how they patch the minecraft.jar. It would be very hard to produce a full-functional consistent API under those circumstances by the community.
I think mojang doesn't want to release a small API at first and then take ages to expand on it because they are reworking the code, i think they want to do the reworking first, at least that how it seems.
If Mojang isn't going to put out an API unless it's server-only and complete, then we'll never see it. It can't be done. Minecraft is at its core a SSP game and they would really have to rewrite everything to do it all server-side. And worse, Minecraft is a demanding game and the server is not going to be able to do it all. They could, in a reasonable length of time, release a universal API which is relatively complete; or they could release a limited API which works server-side. But not both.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.