It's being worked on. There's a lot of changes that need to happen internally that normal people won't see, which have been going with the patches that have already been released. Mojang just wants to give people some more content to play with in the mean time and give modders time to slowly adapt to some of the new changes rather than going off the radar for several months and then forcing every mod to radically change all at once.
Because adding hooks for a versatile API is easy for a developed game! Actually, contrary to belief, it's totally not. People need to be patient; Mojang are working on it.
Seriously? Another one of these threads? People really need to be patient. Rushing Mojang with it will not make it any better.
Even if you are just wondering about the progress on the Modding API, that's not how you ask; you sound quite demanding.
It seems that they are adding random mods to the game, which makes me wonder if Modding API will become nigh-useless in the future. I know that they're currently borrowing from RailCraft and other mods to please the majority of the Reddit community, which apparently care more for having dogs afraid of fireworks rather than being able to mod the game.
Mod api? Didn't you guys learn after a year of waiting to just go about life? I hope the optifine vanilla/less laggy restone/light/render doesn't get dropped for a year+
It seems that they are adding random mods to the game, which makes me wonder if Modding API will become nigh-useless in the future. I know that they're currently borrowing from RailCraft and other mods to please the majority of the Reddit community, which apparently care more for having dogs afraid of fireworks rather than being able to mod the game.
It is already possible to mod the game. I also find your repeated comments that speak of the "reddit community" as if it was a pejorative term curious. Evidently you would prefer that they aligned themselves with a community that shared your views on what the game has, which evidently conflicts with some of the reddit community. I wasn't able to find any semi-recent posts that backup your claims regarding wolves reacting to fireworks taking a priority in most of that communities perspective than the Modding API. It is, however, worth noting, that unless people either use or play mods, the Modding API is completely useless to them anyway.
Additionally the features shown in the twitter images regarding improvements to minecarts and/or rails are in no way consistent with features found in Railcraft, which takes the entire thing to an extreme that is probably too excessive for the vanilla game. to my knowledge Railcraft does have more items that can be in carts (including a TNT cart) but there are quite a few critical differences in the implementation that can be discerned fairly easily, so I don't think anything is really being borrowed. Rather, the modder behind Railcraft came to some of the same obvious conclusions as to how the rail systems can be improved as Mojang. The Railcraft mod went further, adding and changing existing recipes, and adding more steps and requirements, and making using rails both a pain in the ass as well as functionally rewarding. Mojang, however, is currently focussed on general improvements to the use of rails, which have slowly become less garbage since they were added. People that feel "nostalgic" about the days when you had to exploit a glitch to make a cart move more than a few meters on level terrain need to give their head a shake.
It is already possible to mod the game. I also find your repeated comments that speak of the "reddit community" as if it was a pejorative term curious. Evidently you would prefer that they aligned themselves with a community that shared your views on what the game has, which evidently conflicts with some of the reddit community. I wasn't able to find any semi-recent posts that backup your claims regarding wolves reacting to fireworks taking a priority in most of that communities perspective than the Modding API. It is, however, worth noting, that unless people either use or play mods.
Additionally the features shown in the twitter images regarding improvements to minecarts and/or rails are in no way consistent with features found in Railcraft, which takes the entire thing to an extreme that is probably too excessive for the vanilla game. to my knowledge Railcraft does have more items that can be in carts (including a TNT cart) but there are quite a few critical differences in the implementation that can be discerned fairly easily, so I don't think anything is really being borrowed. Rather, the modder behind Railcraft came to some of the same obvious conclusions as to how the rail systems can be improved as Mojang. The Railcraft mod went further, adding and changing existing recipes, and adding more steps and requirements, and making using rails both a pain in the ass as well as functionally rewarding. Mojang, however, is currently focussed on general improvements to the use of rails, which have slowly become less garbage since they were added. People that feel "nostalgic" about the days when you had to exploit a glitch to make a cart move more than a few meters on level terrain need to give their head a shake.
Not going to comment on the first part
I can't say much about rails and am glad to see they are getting an improvement.
Fixed the last sentence of the first paragraph there.
Basically, The Modding API is only going to be useful to two sets of people: Modders, and, by extension, people that use mods. If this corrects the problems that keep me from using mods- such as ID conflicts, or ids that change between versions of a modification basically making existing worlds obsolete, then I'm all for it. But since I hardly use mods, personally, I honestly don't give a damn about the Mod API.
Of course, if they do make it, I think they should make it right. Last thing we need is an API that is fractured or changes over time, because that would eliminate all the benefits of it to begin with.
The best way to present the difficulty in creating the API is that an API is not a "modloader"; it's not even the same as forge, or even bukkit. What's the difference? Well, none of those are really made properly in terms of an API (with the possible exception of bukkit, though they introduce their own breaking changes over time, but that's another subject).
Mostly, what you end up getting access to in a Mod, are the inadulterated classes from within the game. In the actual classes, the names are obfuscated. the MCP team works to remap the obfuscated names with their actual names, or find out what they do and give them a name. At that point, base mods usually update. And subsequently, mods that use that base mod can usually update as well.
But the mods are still accessing the pure, unadulterated internal classes of the game. Even if we ignore obfuscation, the fact is that the classes could have methods added, removed, or parameter types changed. Mojang currently can't be held back with the interest of "golly, if I add this feature, will some unknown mod that I can't possibly predict as existing be depending on the parameter list to this routine?".
Some might argue that it is as simple as unobfuscating the Minecraft jarfile. And, to a point, this makes sense. If we ignore the threat to the IP entirely, since that is something of a different subject altogether. But then we come into the same difficult territory, in that mod code is now bound directly to the internal code of the game, and maintaining compatibility requires careful work within the game. Now, if this was planned as it is from the get go- that is, "just expose the game classes" then we can assume it would be worked into the design, but since it isn't, there are going to be issues with that. Over the course of engineering a game, methods get removed; method parameters change number or type, etc. That is the way it works. An API, however, by definition, must remain constant.
I believe the idea they are going for here is to have a separate jar file that Mods link to, which itself references the actual game. the API's external, public interface will remain the same, but each version is updated with a new API jar that calls the appropriate obfuscated code in the game jar. This will eliminate the existing issues regarding obfuscated names, as well as further issues regarding the changes in parameter types. In the latter case, the API can have the same method it had before, but also posess an overload with the extra parameters. In addition, it could easily possess basic wrapper code to make the entire thing easier to work with. Just as the API has to know of the core game classes, though, I believe the game itself will need to be aware of the API. I don't know if there is an eventing system in place within the game, or whether that is something added helpfully by the authors of base modifications, but I think the core game will be aware of the API and call back into it where appropriate and/or necessary.
Nonetheless, the task is monumental, which is why it was delayed through various core fixes and refactorings. It was started some time ago, but these things take time. Assuming that just because we can't see it, it doesn't exist, is silly- absence of evidence is not evidence of absence, after all. I don't believe they have ever revealed all of their plans for the game, regardless of how much of their community is self-entitled to know such things because they gave them a few dollars a few years ago.
Mod api? Didn't you guys learn after a year of waiting to just go about life? I hope the optifine vanilla/less laggy restone/light/render doesn't get dropped for a year+
So you mean that you think that all of 1.5 could be dropped for a year, when it is very close to completion already?
And here I thought I was pessimistic.
Rollback Post to RevisionRollBack
The Internet is a big place, friend. I've been places you've n͍̺e̩v̦e̦̰͍͓̩ͅr̜̭̝̬̬͉̤̬ ͙ịm̖͇a͍͇̤͙̥g̤̘i͔͖̤̼̪̬n͖͔̳̬̯e̩̘ḓ͈͔̠̙͇̼̯.͎
Even if you are just wondering about the progress on the Modding API, that's not how you ask; you sound quite demanding.
It isn't out yet -__-
January
It's only the 9th -__-
Just wait, it will come
Hey everyone, I'm back!
More like Half Life 3 and the API. Duke Nukem Forever was finally released. (And was not impressive.)
...but that's just like, my opinion, man.
(or at least that's the main component of where things are being done.)
It is already possible to mod the game. I also find your repeated comments that speak of the "reddit community" as if it was a pejorative term curious. Evidently you would prefer that they aligned themselves with a community that shared your views on what the game has, which evidently conflicts with some of the reddit community. I wasn't able to find any semi-recent posts that backup your claims regarding wolves reacting to fireworks taking a priority in most of that communities perspective than the Modding API. It is, however, worth noting, that unless people either use or play mods, the Modding API is completely useless to them anyway.
Additionally the features shown in the twitter images regarding improvements to minecarts and/or rails are in no way consistent with features found in Railcraft, which takes the entire thing to an extreme that is probably too excessive for the vanilla game. to my knowledge Railcraft does have more items that can be in carts (including a TNT cart) but there are quite a few critical differences in the implementation that can be discerned fairly easily, so I don't think anything is really being borrowed. Rather, the modder behind Railcraft came to some of the same obvious conclusions as to how the rail systems can be improved as Mojang. The Railcraft mod went further, adding and changing existing recipes, and adding more steps and requirements, and making using rails both a pain in the ass as well as functionally rewarding. Mojang, however, is currently focussed on general improvements to the use of rails, which have slowly become less garbage since they were added. People that feel "nostalgic" about the days when you had to exploit a glitch to make a cart move more than a few meters on level terrain need to give their head a shake.
Not going to comment on the first part
I can't say much about rails and am glad to see they are getting an improvement.
I think they still are working on it, albeit at a lesser priority than it deserves.
Basically, The Modding API is only going to be useful to two sets of people: Modders, and, by extension, people that use mods. If this corrects the problems that keep me from using mods- such as ID conflicts, or ids that change between versions of a modification basically making existing worlds obsolete, then I'm all for it. But since I hardly use mods, personally, I honestly don't give a damn about the Mod API.
Of course, if they do make it, I think they should make it right. Last thing we need is an API that is fractured or changes over time, because that would eliminate all the benefits of it to begin with.
The best way to present the difficulty in creating the API is that an API is not a "modloader"; it's not even the same as forge, or even bukkit. What's the difference? Well, none of those are really made properly in terms of an API (with the possible exception of bukkit, though they introduce their own breaking changes over time, but that's another subject).
Mostly, what you end up getting access to in a Mod, are the inadulterated classes from within the game. In the actual classes, the names are obfuscated. the MCP team works to remap the obfuscated names with their actual names, or find out what they do and give them a name. At that point, base mods usually update. And subsequently, mods that use that base mod can usually update as well.
But the mods are still accessing the pure, unadulterated internal classes of the game. Even if we ignore obfuscation, the fact is that the classes could have methods added, removed, or parameter types changed. Mojang currently can't be held back with the interest of "golly, if I add this feature, will some unknown mod that I can't possibly predict as existing be depending on the parameter list to this routine?".
Some might argue that it is as simple as unobfuscating the Minecraft jarfile. And, to a point, this makes sense. If we ignore the threat to the IP entirely, since that is something of a different subject altogether. But then we come into the same difficult territory, in that mod code is now bound directly to the internal code of the game, and maintaining compatibility requires careful work within the game. Now, if this was planned as it is from the get go- that is, "just expose the game classes" then we can assume it would be worked into the design, but since it isn't, there are going to be issues with that. Over the course of engineering a game, methods get removed; method parameters change number or type, etc. That is the way it works. An API, however, by definition, must remain constant.
I believe the idea they are going for here is to have a separate jar file that Mods link to, which itself references the actual game. the API's external, public interface will remain the same, but each version is updated with a new API jar that calls the appropriate obfuscated code in the game jar. This will eliminate the existing issues regarding obfuscated names, as well as further issues regarding the changes in parameter types. In the latter case, the API can have the same method it had before, but also posess an overload with the extra parameters. In addition, it could easily possess basic wrapper code to make the entire thing easier to work with. Just as the API has to know of the core game classes, though, I believe the game itself will need to be aware of the API. I don't know if there is an eventing system in place within the game, or whether that is something added helpfully by the authors of base modifications, but I think the core game will be aware of the API and call back into it where appropriate and/or necessary.
Nonetheless, the task is monumental, which is why it was delayed through various core fixes and refactorings. It was started some time ago, but these things take time. Assuming that just because we can't see it, it doesn't exist, is silly- absence of evidence is not evidence of absence, after all. I don't believe they have ever revealed all of their plans for the game, regardless of how much of their community is self-entitled to know such things because they gave them a few dollars a few years ago.
So you mean that you think that all of 1.5 could be dropped for a year, when it is very close to completion already?
And here I thought I was pessimistic.