Hi everyone!
While we continue working on the foundation of Minecraft itself, we'd like to get started on our promise to involve the community in shaping the official API by having our first planned Minecraft API discussion. This Saturday we're hoping to have an informal discussion on the community's thoughts and ideas on what they feel the API should provide and how it should be shaped. We already have some topics in mind of our own that we'd like to cover, but we encourage you to prepare some of your own topics of interest for the discussion for you and us to get the most out of the opportunity.
To keep things manageable, we'll most likely have to limit the amount of people that are able to talk. As such, we'll be giving representatives from modding groups that develop a modding platform, like Bukkit, Spout, etc. priority when selecting who will be provided with voice. If you're a part of a group that is interested in attending, please elect two representatives (one backup in case the first can't make it) and RSVP in a post below.
If we feel that more participants will be manageable, we'll provide other modders with the ability to participate. We wish we could just let everyone talk, but that would be a bit too crazy, sorry. If you believe that there is a better way to go about doing this, feel free to mention it in a post below and we'll take it into consideration.
If you're interested in joining us for the discussion, we're planning to hold the meeting this Saturday at 20:00 CEST on the Esper IRC network in the channel #minecraftdev. If you can't make it, we'll be providing logs of the meeting after the fact. For people who won't be actively participating in the meeting, we'll have another channel #minecraftdev-discuss where anyone is able to discuss the current topic in the meeting.
Who:
To keep things manageable, we'll most likely have to limit the amount of people that are able to talk. As such, we'll be giving representatives from modding groups that develop a modding platform, like Bukkit, Spout, etc. priority when selecting who will be provided with voice. If we feel that more participants will be manageable, we'll provide other modders with the ability to participate. We wish we could just let everyone talk, but that would be a bit too crazy, sorry.
If you're a part of a group that is interested in attending, please elect two representatives (one backup in case the first can't make it) and RSVP in a post below.
What:
An informal discussion to get an idea for what future discussions should be about, a feel for what ideas people have regarding the API and so on.
When:
This Saturday, June 30th 2012, at 20:00 CEST (check what time this is in your time zone).
Where:
Moderating meeting will take place in #minecraftdev on the Esper IRC network, irc.esper.net. Regular discussion will be taking place in #minecraftdev-discuss.
List of Attendees:
- Afforess from Spout
- Searge from MCP
- Amaranth from Bukkit
- UltraMoogleMan of WEDGE fame
- RoyAwesome of Spout GUI fame
- TkTech of #mcdevs and MCEdit fame
- Jarvix from Canary
- LexManos from Minecraft Forge
- FlowerChild of Better Than Wolves fame
- ShaRose of GuiAPI and ID Resolver fame
- Cojo of Tropicraft fame
- Corosus of ZombieCraft and Tropicraft fame
- medsouz of SocialMiner fame
- Xie of Xie's Mods fame
- Snowl of MCForge (classic) and LibMinecraft fame
- DV8FromTheWorld from Minecraft Port Central
- Kulttuuri from MinecraftEDU
- Eloraam of Minecraft Forge and RedPower fame
- sk89q of WorldEdit, WorldGuard and CraftBook fame
Agenda:
- Our plans for involving the community in the API development process for the future.
- Our considerations on how we might handle contributions.
- Our plans for keeping the community in the loop.
- The direction we're taking to prepare for the API.
- General Q&A.
Hope to see you there!
// The Minecraft Team
I will start with this topic thread:
http://www.minecraftforum.net/topic/1127382-mod-api-ideas-and-concerns
PLEASE, NO.
Forge is great for most computers and systems.
But FML is a disaster for older systems.
===
RML (Risugami's Mod Loader) works (-ed?) fine, and happily, on java 5 machines. And some machines cannot do more than java 5. There are dual core G5 high-end video processing systems out there, that are more than capable of playing this game. There are plenty of G4 laptops and desktops that can do an acceptable job of playing.
RML works in J5.
Forge relies heavily on generics, that are J6 only -- so forge mods cannot work in J5 systems.
FML currently is J6, and if/when I get a development environment set up (given that my current focus is on Lets Play's, that will not be fast, and given the apparent complete lack of documentation on getting started that I can find, even slower) it should not be hard to port FML to J5. But the people who know it consider that to be pointless, and won't even consider it.
The combination of FML + forge dictionaries -- ores, leaves, etc (Water? Fluids? I know, off topic here.) -- is enough for many interesting mods. It won't cover everything, obviously. But it's a subset of the full system that could run on all machines.
And this is the key observation. Subsets.
One API subset that is able to run on all clients, based around a J5 modloader, that is able to handle the display of new blocks and items, and new recipes.
One API subset that runs on all servers, based around a J5 API subset, that has the ability to implement new blocks and recipes on the server -- including single player server.
And an API superset that runs on some servers, based around the J6 API.
But the key point is strict subset/superset. Any mod can start as being written to the J5 section. Any mod that only uses the J5 section can be compiled to J5, without needing to be J6.
===
Major API concern to toss out, for you to think about: At the same time that the whole "single player server" system was supposed to eliminate the code differences between the two versions, you actually introduce new differences. Some of the multiplayer commands are not the same as the single player commands. The "all in one process" model helps performance, but results in slightly different behavior than two separate processes. No idea where to go from that observation.
===
And before you insist "A g4 laptop? Dude, that's way too old", recall that 1.42 GHz, with a dedicated 3d card (NVidia 9200 for older desktops, 9550 for newer laptops, and even better for the next generation I didn't get), is well over the minimum requirements, and almost the full recommended.
Equally, any pretense that "Separate server requires more processing power" should read this post (as well as the discussion on the prior pages):
http://www.minecraftforum.net/topic/1209332-sspsmp-merge-what-it-means-for-you/page__view__findpost__p__16027994
Quick Summary: The server has a hard-coded tick rate, and will not slow down. It can be taught to be on a leash easily, and can learn to adjust its tick rate down (that's less easy :-).
it means that theyre gonna make it easier to mod and download mods and use outdated mods on new versions and stuff like that
i think...
...it'd be like a noise meter at a sporting event, except with a "like vs. dislike" meter
Surely there is room for both. As an end-user I hope that the end result includes the big four mods, and a few others like them being available as plugins that are easy to install. I enjoy the enhancement to the minecraft experience provided by the technical type mods, but it is currently hard to get them all installed. I am a developer myself, and I have had to spend hours reconciling block ids, researching what mod are compatible, and what prerequisites they have, and troubleshooting crash bugs resulting from mod conflicts. Currently, this makes the modded minecraft experience less accessible to users without a technical background. It would make me very sad if the only mod content made available in game as plugins are bukkit plugins like iconomy. These things are helpful for SMP, i just really want to be able to share with my friends how awesome it is to be able to set up an automated ore processing facility, decoreate a house with microblocks, build an amazing frames machine, or an autocrafting network, or to play with the amazing endgame toys in EE. Obviously, MCP has done amazing work behind the scenes to make this all possible, I just want to see Mojang put a high priority on making this high quality content available to everybody.
I haven't forgotten Thaumcraft2. Ananor is also a genius level modder, I agree. I focused on mentioning the "Big Four" because they were the pioneers in my mind. Of course I would also love to see Thaumcraft2 available as a plugin, but if I go there I would also want to mention Forestry, Railcraft, Steve's Carts, etc. My point was more that I'm not sure if any of this stuff is what Mojang intends to support. I would be sad if they focus only on SMP bukkit type stuff.
<shrug> I can understand them wanting to restrict this to API developers as it can be assumed that most modder API requests have already filtered through them.
I suspect I'll just wait for the logs and see what happens. If they arrange one of these to talk to the authors of the big mods at some point, I might join in then.
Sure it does man. Compatibility isn't an all or nothing affair, nor do you need to eliminate *all* base class mods to ensure compatibility with others. For example, even when I was with the Forge, I was still making base-class changes, and slowly migrating them into the API as needed, and when it was common enough functionality that it seemed it would benefit modders in general. Still, BTW remained compatible with the other Forge mods at the time.
The really important part is the common functionality that virtually all mods require and which basically forces each of us to modify the same base class files to get the job done. Stuff like extended texture indexes and blockIDs, and then extending into more obscure functionality. Already, if Mojang would take care of those aspects, it would make a huge difference to the modding scene, and that doesn't even require a full-fledged API.
Less used functionality can definitely wait and has very little impact on mod compatibility. For example, who gives a damn if I'm modifying EntityCow? I don't think there are too many cow mods out there that it would cause problems with.
So yeah...don't write off the benefit of an official API just because it can't feasibly do absolutely everything out of the gate.
The revamp of the Event System in Bukkit was a nice step up. It would be wonderful to see a change that has even more impact with the mod API.
I know that with just the right kind of discussion, the API can be molded to conform to each developers needsd. I will try to be there for a part of this discussion.
Alblaka of IndustrialCraft
DrZhark of Mo'Creatures
Kinniken of Millenaire
Eloraam of RedPower
Pahimar and X3n0ph0b3 of Equivalent Exchange
FlowerChild of BetterThanWolves
Risugami of Risugami's Mods
seagoingmanatee of Pokemobs
Krapht and Sengir of Buildcraft
Flan of Flan's mods
Simo_415 of SinglePlayerCommands
sp614x of Optifine
Azanor of Thaumcraft
iChun of PortalGun
ScottyDoesKnow of SDK's mods
I'd understand if I'd not be allowed considering I don't have too much to show for my work, but it'd be nice.
I think many of the really extensive mods will *never* be plug-ins man. I already accepted weeks ago that BTW likely never would be given the number of base-class changes I make, but that doesn't make an API any less valuable, nor does it prevent such mods from being compatible with plug-ins.
Mojang seems to understand this, as it's already been publicly stated that they view mods in MC separating into two distinct categories in the future: mods and plug-ins. To think that the most extensive mods out there would fit into the plug-in category just isn't realistic IMO.
Going off number of MCF forum posts to indicate popularity is flawed in itself, as a number of the mods mentioned have their own forums separate from that, which will inevitably reduce MCF traffic in the related threads.
I don't think there's currently a good method of objectively determining mod popularity, and if Mojang makes a subjective decision about that it's bound to result in hurt feelings and a lot of chaos as additional modders try to get in on that. I sincerely doubt the modding community needs a big cock-fight to erupt over whose mod is more popular than whose when Mojang is trying to organize communication between everyone.
Honestly, I think restricting it to API devs is probably the right move at this stage.
I don't have any particular issue with it. However, the practicality and feasibility of doing something like that is up to Mojang and the original authors of those APIs.
It's really not as simple as dropping the code into MC. Given that the source for MC is obfuscated, they aren't even really working on the same code-base. Given that, and given that they would most certainly want to review each and every change, it's likely Mojang would have to effectively rewrite them from scratch anyways.