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
(Stuff in brackets is the ModLoader implementation.)
- adding fuel to vanilla furnace [BaseMod.addFuel(itemid, meta) cooktime]
- grabbing the Minecraft instance (!!! This is a must.)
- entity renderers is a must [BaseMod.addRenderer(renderermap)]
- registring animations [BaseMod.registerAnimation]
- adding custom handling to dispensers [BaseMod.dispenseEntity(.....) handled]
- changing worldgen [BaseMod.generateNether/Surface]
- a load method [BaseMod.load]
- ordering mod loading [BaseMod.getPriorities]
- a post-load method [BaseMod.modsLoaded]
- mod versioning [BaseMod.getVersion]
- keyboard handling [BaseMod.keyboardEvent]
- every-tick hooks [BaseMod.onTickInGame, BaseMod.onTickInGUI]
- packet handling [BaseMod.receiveCustomPacket]
- rendering hooks [BaseMod.renderInvBlock, BaseMod.renderWorldBlock]
- achievements:
--- BaseMod.takenFromCrafting
--- BaseMod.takenFromFurnace
--- BaseMod.onItemPickup
--- ModLoader.addAchievementDesc
--- Awarding achievements (somewhere).
- e-z reflection [ModLoader.get/set PrivateValue]
- adding/removing mob spawns [ModLoader.addSpawn]
- adding recipes [ModLoader.add(Shapeless)Recipe]
- adding furnace results [ModLoader.addSmelting]
- Adding blocks to the static list [ModLoader.registerBlock]
- Registering entity IDs [ModLoader.registerEntityID]
- Sending packets [ModLoader.sendPacket]
- Hooks for connecting and disconnecting from a server [BaseMod.serverConnect/Disconnect]
- Clean error throwing [ModLoader.throwException]
Features missing in ModLoader that easily complement those listed:
* one-time worldgen calls
* generateEnd()
* strict mod versioning [BaseMod.getMinecraftVersion]
* Clean error catching
* Adding controls [ModLoader.registerKey] (needs work)
* Hooks for joining and leaving a singleplayer world
* adding armor (yeah it's still hard)
* opening a GUI
* dealing with mods that don't load properly (use point "clean error throwing" above)
* dealing with mods that violate the design contract (which is: Do all your initialization in load() and the methods that pass you a container)
Yeah, I think that's it.
One more thing: when you do "opening a GUI", please, PLEASE change the workbench and furnaces to use the API methods. (The reason for this is setting a good example.) Thanks~
Also, I'm thinking:
- Adding custom sounds
- Adding new potions
- Adding new dimensions
- Changing player model
And other things that I can't think of right now.
- Adding World Types
- Hooking into options GUI
-Adding custom animated textures.
- An integrated skin and texture pack editor (with skin uploader).
- A plugin manager (see SKCraft's one, it's fantastic!) including switching to old Minecraft versions and creating profiles of mod setups, seeing mod conflicts.
- Block, item, biome, hud, mob, script etc creation tools.
- Popup option to download relevant mods as a temp or permanent file upon logging into a server if you don't have them.
- Ingame mod browser with search, tags, ratings, comments etc.
- A foundation that allows mods to be combined more efficiently (like an official variation on Forge).
I will pay you £100 or more for just a couple of these features I'm not kidding. They would easily make Minecraft the best game on the planet!
You're modifying EntityCow? Damn! So much for my Mooshmallow mod being compatible with BTW. ;-)
I would love to talk at this session if there's a place for me!
Thanks.
Where was that in the announcement? They are trying to get input from the community.
Like EvilSeph said in the original announcement, they will be letting representatives from modding groups talk during the meeting. It's not that you aren't "allowed" in the meeting because you are not a chosen representative; everyone is allowed to listen in that's the point of the public meeting. However, if every person with a mod was allowed to speak during the meeting it would be about as insane as letting everyone speak.
If all mods were run by the server you would not need to download anything.
API stands for Application Programming Interface. It's a way for third party programmers to develop their own extensions (usually known as "plugins") for an application. In this case the application is Minecraft and the extensions are "mods". So the API would provide a way for mod developers to create mods which work smoothly with Minecraft and don't interefere with each other (or at least are less likely to).
Bukkit and Forge are examples of existing APIs for Minecraft, but one provided by Mojang would have several advantages:
Let's say that Mojang is only able to implement 5% of the API per month. It might then be a year before many mods could start using it.
But if Mojang was able to publish the specs for the entire API near the start, then modders could write their own implementations of the bits they needed. Those could then be retired when Mojang catches up, without having to rewrite the mod itself.
Having designed an API for a large application I know that the specification alone represents quite a bit of work and that it is likely to be tweaked as implementation points out various difficulties with the original concept. But my experience has been that such changes only rarely require a complete redesign of an interface, so mods would still benefit greatly from having the specs in advance.
Publishing the specs in advance of the bulk of their development would also give the modding community a chance to comment and provide potentially crucial feedback *before* too much time has been spent on implementing a flawed design.
If that was the case, mods could not have unique textures, models, or sounds.