What does this mean? Well, in the words of Warren "EvilSeph" Loo:
(The Developer Blog) will be our space to let loose and nerd out. Posts made by us will be technical and developer focused, ranging from technical write ups on a new feature to information on the Minecraft API and things surrounding it.
I am excited to continue working to bring useful and powerful resources to the Minecraft developer community! This blog and the Minecraft API proposal system is just the beginning of my work to better involve and support the Minecraft developer community.
In the interests of keeping developers in the Minecraft community as involved as possible, the new blog will serve as a repository for all things API, such as planning for meetings, getting feedback on the system, and progress they are making on it, to name a few. No longer will it be necessary to scan every Twitter account, website and other forms of communication to get tidbits on the Mod API - it is all centralized, so you need only stop by the blog to read about (and possibly help with) the Mod API.
Interested in seeing the blog? You can check it out here: Official Minecraft Developer Blog - Click Here
Thanks mojang
I haven't been following the Modding API discussion much, but my understanding was that it would replace Bukkit AND have the ability to enable and disable mods on the client-side to match what was running on the server-side. Meaning server operators would be able to run a vanilla jar file and thus update immediately instead of waiting a week for a Bukkit recommended build, etc.
At best...
Don't worry, mod api will be in 1.8 at the latest.
sarcasm
Go complain somewhere else.
Well, just downgrade Minecraft, and your problem is solved.
ok, I have had so much trouble with finding the correct version of forge for each mod that a centralized API would be great.
as far as the RPG vs. sandbox, THEY HAVE NOT REMOVED OR EVEN DEGRADED THE SANDBOX ASPECT OF THE GAME. quit complaining.
and pistons, the fact that there was a mod for it doesn't matter. mods are uncooperative brats that often won't work together. the fewer mods you can use for the same results the better. (and no, I am not saying mods are bad, just that it's a pain to get them to work together and that this would be compounded by having to use lot's of small mods instead of a few good big ones.)
and this is my favorite. first you complain that the villages are to simple, and then you complain that it's turning into an RPG.
overall, I think that your post was an unnecessary waste of fourm space.
I still don't see what this has to do with multicolored Slimes! But this API could be at least worth the wait.
Hell I remember when mojang promised official modding support right after BETA 1.5 was released. Here it is a year and a half later and still no modding support.
This just proves that mojang really doesnt know what they want in the API so they are asking us for the answers. This also leads me to believe that very very little has been done on the API as of date.
And while I agree that there is a definant need for a centralized API many of us in the modding community do not have faith in Mojang to give it to us.
When (if) mojang finishes the API the Doctor Who Client Mod will split off from minecrafts version system and we will develop at our own pace to avoid any other major changes that they decide to throw in for the lolz that dont add much benefit to either the player or the developer.
Mod Development on minecraft has always been a whirlwind of uncertainty and despite the advantage of having a centralized API it probably always will be
a scheme used in my own engine (which also has MC-like voxels), for colored lights, was basically to use 4 bits to encode the color (so, 4-bit light level, and 4-bit light color). this is using a slightly modified 16-color palette, and the light blending calculations use blend-tables.
similar would be cool if added to Minecraft, if they can find a few bits to add the color into.
+1 if they add colored glass (say: red-glass ceiling to make a red room, ...).
in my case, for colors there are:
6 pure-saturation colors;
6 partial-saturation colors;
3 composite colors
orangish-tint (red=1, green=.66, blue=.33)
greenish-tint (red=.66, green=1, blue=.33)
bluish tint (red=.33, green=.66, blue=1);
white/gray.
(the reason here is that usually a 16-color palette has 4 shades of white/gray/black, but for chroma only 1 is needed, as the difference between white/gray/black is purely a matter of luminance).
the big downside of forge though is that it is a pain to get it working and AFAIK doesn't work with snapshots.
this means that likely a major advantage of a Mojang API is that mods may still work with snapshots, and probably less likely to break with each new MC version, which would be convenient.
possibly, it could mean a split:
simpler mods using the official API, and more advanced mods using Forge or similar.
more code doesn't automatically mean more slowness, usually this is only really an issue if the code is in the direct execution path, which can usually be avoided if the code is well written.
often a bigger codebase can actually be faster (say, if the additional code is related to optimizations or a more efficient implementation strategy).
I can run MC, if slowly, on an older laptop of mine, which only does OpenGL 1.5...
similar goes for a newer laptop using a terrible Intel chipset (the laptop is 2009, but doesn't get decent performance for much of anything newer than Half-Life, yes, the first one, not HL2, which lags pretty hard...). yeah, it requires using tiny render distance and still kind of lags...
but, it is common for renderers to treat newer features as optional, and then use different rendering paths for different generations of hardware:
say, a simple fixed-function pipeline path for older/slower hardware (no shaders, ...);
a vertex-arrays or VBOs + shaders path for newer hardware.
this way, newer features can be used without breaking compatibility with older cards.
They've BEEN working on it, they didn't just start.