Lighting problems are still there... chunk loading errors still there, lag when the sound initializes is still there, monster and npc's falling into the ground still there, Swiss cheese worlds still there, twitches when you place water/lava still there.
I love all the new sounds except making walking on gravel/sand...
It really sounds almost like the sound slimes make when bouncing around..really tricks me when playing on superflat world presets...>_<
And in deserts lol
I almost forgot the sound problems... they finally fixed the "stomping chickens" with a clicking sound... talk about lazy LOL and the zombies sound like you're stirring mac n cheese when they walk, and so do the spiders
AARGH! How do you download it? Do I Take out my 1.3.2 jar and put the 1.4 jar in there? I have mods that can't use META-INF (I belive that is what it's called) so do I delete META-INF in the 1.4 Jar? Thanks!
-supermario2902
I'm so confused by mojang. It makes no sense for them to keep adding new content that is hit and miss instead of focusing purely on the mod api. I'd understand it we were talking about EA or someone else who would be concerned about loss of DLC sales.
Guys, please at least STFU about the API! If they add it, it will change the game a lot because it may mean you are expected to have mods. There should be a compromise: the API only works for Mojang approved/created (if they started making some) mods.
I said earlier that people complaining about the API were clueless about what it actually does.
Mojang seems a little lost about the integration of bukkit and the API. So let's get this straight: you put everything under a server shell, which causes a serious ding to performance, and then do nothing that required any change. Here's what you will have to do, like it or not:
1) Create an web-based interface for mods with a specific format and search ability so that servers can rapidly access and upload required third party content.
The formal recommendation to get this accomplished can be found here:
You are welcome to participate in that discussion, although it seems to have a very fractured set of views for how it will eventually work. In other words, I doubt consensus is going to happen any time soon without Notch directly getting into the mess or the Mojang dev team simply declaring a course of action and moving on. It also involves legal and financial issues that will end up involving nearly the entire company before it can be implemented.
2) Create a common format for all mods, virtually guaranteeing that all mods must be hosted on a specified site, and most likely frustrating mod programmers and no doubt convincing some of them to take their skills elsewhere.
See also the above proposal, but also note that the purpose of the API is to establish a "common format" for plug-ins (the correct term, as "mods" are for "modifications" of the game code itself... which these are not doing if they stick with the API alone to talk with Minecraft).
I do agree that some mod programmers will likely be frustrated with the changes. For those that can't adapt to simply using an API instead of the old ways of making stuff, I have little sympathy. Those programmers who are challenged on a philosophical basis because they won't be able to share their extensions (both genuine mods and plug-ins) to Minecraft because they want to either earn some money on the side (aka adfly income or even simply charging money for the plug-in) or because they want to stick to an open source software license (like the GPL) and Mojang won't let them.... those kind of developers will be driven out of the community. It seems likely both kinds of developers will be driven out if things continue on its current course.
I really don't know who will be left if you drive out both the libertarians and hard-core capitalists from the mod development community, but it won't be pretty if that really happens.
3) Create a security protocol to monitor and protect the upload/download links to prevent viruses and hackers from accessing sensitive information about connecting servers ports and protocols.
Also discussed in the above link, but dismissed with a handwave that I think needs some extra attention. That software sent through upload/download links will by necessity conform to the API before it will work provides some sort of security. Malicious mods can and even are being written at the moment, but you are correct it can get worse.
4) Actually integrate the Bukkit team this time.
The Bukkit team is integrated into Mojang. It takes time, so I'm not really sure what you are referring to here with this statement. Bukkit will not become the API, but due to the experience these guys have with Bukkit there will certainly be many features of that 3rd party API which will likely be integrated into Minecraft.... with a whole bunch of other features. It is a clean-sheet reimplementation though, so existing API libraries will not be supported directly.
so much for "bug fixes" lol
If you don't have internet, how did you post that comment? Or even get on minecraft forums?
I'm sure it comes out in November...
I use the internet from my android it very awsome sadly I cant use it to teather
It really sounds almost like the sound slimes make when bouncing around..really tricks me when playing on superflat world presets...>_<
And in deserts lol
I almost forgot the sound problems... they finally fixed the "stomping chickens" with a clicking sound... talk about lazy LOL and the zombies sound like you're stirring mac n cheese when they walk, and so do the spiders
-supermario2902
I said earlier that people complaining about the API were clueless about what it actually does.
Q.E.D.
The formal recommendation to get this accomplished can be found here:
https://mojang.atlas...rowse/MCAPI-102
You are welcome to participate in that discussion, although it seems to have a very fractured set of views for how it will eventually work. In other words, I doubt consensus is going to happen any time soon without Notch directly getting into the mess or the Mojang dev team simply declaring a course of action and moving on. It also involves legal and financial issues that will end up involving nearly the entire company before it can be implemented.
See also the above proposal, but also note that the purpose of the API is to establish a "common format" for plug-ins (the correct term, as "mods" are for "modifications" of the game code itself... which these are not doing if they stick with the API alone to talk with Minecraft).
I do agree that some mod programmers will likely be frustrated with the changes. For those that can't adapt to simply using an API instead of the old ways of making stuff, I have little sympathy. Those programmers who are challenged on a philosophical basis because they won't be able to share their extensions (both genuine mods and plug-ins) to Minecraft because they want to either earn some money on the side (aka adfly income or even simply charging money for the plug-in) or because they want to stick to an open source software license (like the GPL) and Mojang won't let them.... those kind of developers will be driven out of the community. It seems likely both kinds of developers will be driven out if things continue on its current course.
I really don't know who will be left if you drive out both the libertarians and hard-core capitalists from the mod development community, but it won't be pretty if that really happens.
Also discussed in the above link, but dismissed with a handwave that I think needs some extra attention. That software sent through upload/download links will by necessity conform to the API before it will work provides some sort of security. Malicious mods can and even are being written at the moment, but you are correct it can get worse.
The Bukkit team is integrated into Mojang. It takes time, so I'm not really sure what you are referring to here with this statement. Bukkit will not become the API, but due to the experience these guys have with Bukkit there will certainly be many features of that 3rd party API which will likely be integrated into Minecraft.... with a whole bunch of other features. It is a clean-sheet reimplementation though, so existing API libraries will not be supported directly.
Version 2.1 now updated for MC 1.6.2