One of the issues with letting the community know about the upcoming Mod API (and other development-related projects) has been the sheer number of places that information can be posted, often only to be read by a specific group of people in that particular community. In the interests of making life easier for everyone interested in developer talk, Mojang now has an official Minecraft Developer Blog!
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.
...Minecraft Forge is already THE Modding API, and there's no way Mojang will ever develop an API as good as Forge...
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.
I'd rather have Mojang enhance Minecrafts engine, such as creating support for colored lights (and I mean really colored lights, not that half-assed thing Notch put there in 1.8) and moving lights (like a move-able light emitting entity) and leave modding to modders.
Minecraft Forge is already THE Modding API, and there's no way Mojang will ever develop an API as good as Forge, both because Forge already has a lot of time in advance, and because of the coding skills gap between them. Anyone who sets up MCP and compares Mojang's code vs Forge's notices the difference.
In the end, all you'll end up doing is load Minecraft with more code, that besides not being used by most people (seriously, you can't expect a first release to beat Forge's history, and modders to just move from Forge to MC API just because it's new and ''official''), will be slowing the game down even more, which will affect low-end machine users.
Also, you'll just be wasting a release to give players something they already have, or give them a worse version of it, while doing what you've been doing since Beta 1.7: Waste a release to implement something that has already been done in a Mod, but buggier. And besides a buggier implementation of what has already been made, you're turning your amazing Sandbox game into an RPG.
(1.7: Pistons, already existed, 1.8: Villages, it's 1.3.2 and Millenaire's are still better; 1.9: enchantments: been done before; 1.2: jungles, cats: more biomes and more creatures? where have I seen that before?)
Also remember that not everyone wants an RPG. Minecraft gained popularity as a Sandbox game. If players want RPG features, more animals, more biomes, machines, there are mods that do that. Having those 'optional' features being there by default isn't as optional as it could, mainly on SMP (the fun part of MC), where other players can take advantage of them over players that don't feel like using them. Even mods allow to disable features we don't want from that mod...
You should just focus on making the game run on less CPU cost, and probably move some rendering stuff to the graphics card. Maybe use a greater version of OpenGL? with 1.1 it can run on machines from the late 90's, but no machine from that time has the CPU power to run this game, so it kind of defeats the purpose...
And those were my 2 cents.
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.
Originally, maybe, but it got pushed out to 1.4 and now by the sounds of it, we won't see it until 1.5.
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
I'd rather have Mojang enhance Minecrafts engine, such as creating support for colored lights (and I mean really colored lights, not that half-assed thing Notch put there in 1.8) and moving lights (like a move-able light emitting entity) and leave modding to modders.
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).
Minecraft Forge is already THE Modding API, and there's no way Mojang will ever develop an API as good as Forge, both because Forge already has a lot of time in advance, and because of the coding skills gap between them. Anyone who sets up MCP and compares Mojang's code vs Forge's notices the difference.
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.
In the end, all you'll end up doing is load Minecraft with more code, that besides not being used by most people (seriously, you can't expect a first release to beat Forge's history, and modders to just move from Forge to MC API just because it's new and ''official''), will be slowing the game down even more, which will affect low-end machine users.
Also, you'll just be wasting a release to give players something they already have, or give them a worse version of it, while doing what you've been doing since Beta 1.7: Waste a release to implement something that has already been done in a Mod, but buggier. And besides a buggier implementation of what has already been made, you're turning your amazing Sandbox game into an RPG.
(1.7: Pistons, already existed, 1.8: Villages, it's 1.3.2 and Millenaire's are still better; 1.9: enchantments: been done before; 1.2: jungles, cats: more biomes and more creatures? where have I seen that before?)
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).
Also remember that not everyone wants an RPG. Minecraft gained popularity as a Sandbox game. If players want RPG features, more animals, more biomes, machines, there are mods that do that. Having those 'optional' features being there by default isn't as optional as it could, mainly on SMP (the fun part of MC), where other players can take advantage of them over players that don't feel like using them. Even mods allow to disable features we don't want from that mod...
You should just focus on making the game run on less CPU cost, and probably move some rendering stuff to the graphics card. Maybe use a greater version of OpenGL? with 1.1 it can run on machines from the late 90's, but no machine from that time has the CPU power to run this game, so it kind of defeats the purpose...
And those were my 2 cents.
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.
Finally they are making Modding API now. I've been waiting for this so long, so i could make my own upcoming mod. This is gonna be brilliant, brilliant i say. All we have to do is sit and wait.
They've BEEN working on it, they didn't just start.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWhat does this mean? Well, in the words of Warren "EvilSeph" Loo:
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
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThanks mojang
Zombiecraft Maps!
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...
Did you know I write Science Fiction? Well I do. Check it out at http://planetretcon.com/books/
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.