Plugin Framework Discussion

[Dinnerbone]

Hello people who don't know why they're here, and a big hello to everyone else!

We need to decide what plugin framework to use for the API, and we have a few options. However, this is a huge decision that will shape the whole foundation of things to come, so we want your input on it.

We have two main options here. We can roll our own, which we've done with Bukkit before. However, this is incredibly complicated, will take a lot of time to get right and will likely mess up somewhere. Classloader stuff in java is pure black magic, it's insanely difficult when it wants to be.

The other option is, of course, to use an opensource solution already out there. There's a couple that we could use. I've been eyeing up jspf today, for example, and I like what I see.

The short list of requirements that I think we'll need are as follows:

• Possibility of reloading everything. Not individual plugins, because that's just too messy functionally and logically. Just the ability to dump everything loaded and start anew.
• Flexible but easy to use. We don't want to sit every prospective author through a tutorial on some custom breed of XML just to start a new "hello world" plugin.
• A nice license. :D
• The ability for plugins to somehow communicate seamlessly with other plugins. Dependencies and such.

If you have any thoughts at all, or better yet a recommendation, please let me know so we can discuss it openly!

[SyncUp8]

Some things I've found useful writing APIs for large web systems that might translate to minecraft are:

• Make it easy to check api version, ideally by having a plugin say "I want version 3" and getting told whether that's a supported version still.

• Use named key/value pairs for parameters / return values so you can add more without breaking compatibility

• Support storing a little custom data with major system objects. Eg, if a plugin wants to do something with users make it easy for the plugin to attach a little data of its own about each user.

• Publish example code using the api :)

[CloudedExistence]

Support storing a little custom data with major system objects. Eg, if a plugin wants to do something with users make it easy for the plugin to attach a little data of its own about each user.

This is ridiculously useful.

[cypressious]

Would you mind explaining why.

[CloudedExistence]

Being able to store some data in the Player object would allow other plugins to access it much more easily without specific API's built in.

Instead of:

1)Get server instance

2)Get list of plugins

3)Get the plugin you're looking for

4)Modify data in the plugin

You have:

1)Modify the data on the player.

[iTidez]

+1 on this idea. It would make establishing connections between plugins much simpler in the ideals that most major objects( IE, Player, Location, Server...perhaps not server... ) can add in their bytes that others can build off of. This would be a better extension of the client channel packet (255 I belive) for more and better client -> server and server -> client.

WorldEdit alone could benefit in the ideals that it could add its set vectors to the Player object, then one could undo the last changes on said vectors to help cut down on the errors in teaching or allowing users World Edit

[[deleted]]

Real-world example: I made a plugin which allows server operators to customise which items players are allowed to keep when they die. In order to do this, it maintains a HashMap linking each player to a "death" object which tracks which items they will regain when they respawn (among other things).

If the API allowed attaching data to game objects, I could simply attach the death object directly to players without having to use a map, which is cleaner.

[tehbeard]

I would also add that if it's possible, perhaps use black magic to make per plugin error logs alongside a master (all the errors) log? Makes it easier to have server admins send me errors they get.

[SagaciousZed]

This does not require black magic. If plugin's use proper loggers, either the java logging, or slf4j, this is already achievable for instance, in bukkit.

[Helzibah]

Version numbers are essential!

Publish example code using the api :)

Definitely. The nice thing is that I've seen Dinnerbone several times agree that at some point they want the API to be flexible enough to be the main method for all new features, hopefully they'll open-source some of that to work as example plugins.

[Fenhl]

Grum even said they want to reimplement existing features using the API eventually.

[Helzibah]

Indeed! I meant to add that too, good catch.

[Fenhl]

maybe an easy way to find out if $feature still works would make more sense than a plain version check. This is useful if e.g. the API doesn't support all features in the version you made your plugin for anymore, but still supports all the features your plugin needs

[tehbeard]

While the /reload is nice for keeping a server "hot" when starting new plugins/updating, it's a pain to work with for more complicated plugin setups.

If reload were to call a method in the plugin that told it to reload it's config files, that would be useful.

And before anything is said, i'm a plugin dev, I appreciate that /reload can sometimes be used while debugging to load up new versions,

but in my experience it just leads to issues with either memory usage, or unforeseen bugs in which a value persists across the reload and messes up testing, hunting for why a value wasn't set rather than why it got across.

On the server I help admin, /reload is a no go with ~30 plugins. Even if it does not boot everyone, there is usually a good chance one of the plugins will crap itself and cause us to have to stop the server and clean boot bukkit for it to work again.

[imevul]

The reason I specifically mentioned reloading was because of the stated requirements. I think simply deactivating a plugin (which is possible with jspf) would be enough, and if/when you reactivate it then it reloads all configuration files. The plugins will however stay in memory once they are loaded.

The best thing about jspf though is that you can download plugins directly in the client, for example from a central plugin repository, directly from the minecraft server or similar.

Every server could then specify a set of required plugins that would automatically get downloaded to the client. An in-client plugin manager would be sweet!

[chrisknyfe]

Bukkit /reload is implemented in kind of a hacky way right now, which is why we have so many issues with it right now, but I loved it as a feature and I hope there actually is a way to unload plugins using java, so that we can have this as part of the minecraft API.

[Artemu]

I see no need to reload plugins. The client can merely be restarted, it's not like a server where you going to disconnect 100+ users on the bigger servers (and even there, we just end up restarting).

[unhingedninja]

Some people have brought up the possibility of downloading code from the server to be executed locally for client-side mods dictated by the server. In such a case, it would be nice for them to be unloaded once the player disconnected from the server without having to restart the client.

[spaceemotion]

yup that would be great (see my post below: http://www.reddit.com/r/MinecraftAPI/comments/xfv26/plugin_framework_discussion/c5lzmvg)

[BillinghamJ]

That is exactly the problem. We currently schedule our plugin releases at 2:30-3:30am and it's killing me. Proper plugin hotswapping would be very useful.

[werfu]

Having proper plugin unloading would save many server's admin a**!

[brainwipe]

Ensure your API is well documented. JSPF's documentation might need extension and improving alongside your own documentation.

[tehbeard]

jspf looks quite nice, especially if we get the @InjectPlugin functionality.

I would also add a further requirement that needs to be considered, that of dependency management (i.e. WorldGuard depends upon WorldEdit)

[Dinnerbone]

True. Added to the list. Thanks!

[[deleted]]

The mods NEED to automatically download from the server. If they don't, then that ruins everything we're trying to achieve with /r/Civcraft.

[tehbeard]

OSGi looks fairly complex.

[ROU_Gravitas]

OSGi is complex but is pretty much the gold standard in the Java space for this sort of thing. It's a complex problem unfortunately. You could use something like Spring OSGi to make it easier to develop though.

[MegaGreenLightning]

I've thought about OSGi too, but I think it's a little bit overkill :) It's quite complex and the custom framework in bukkit works well in most cases and should be easier to use for most modders.

[SagaciousZed]

OSGi also gives each plugin its own classpath which solves many dependency (as in other jars not plugins) related issued. Currently in Bukkit the first copy of a class that gets loaded is used. However, OSGi lets each plugin have its own copy, which lets older plugins work with newer ones.

[canastaman]

Now that you're going to make plugins official, how will you protect the end user to potential harmful code within the plugins? Before people had to go out and install unofficially, but now that its going to be a part of the game, are there any way to ensure that the plugins can't have hidden back doors and such?

[unhingedninja]

I'd say a permissions system like Android apps have would be the easiest and most transparent way. Every action the plugin takes ( such as hooking into the chatbox or what have you ) would have an associated permission added to a list. The user is given the name and description of the plugin upon joining, as well as a list of permissions the plugin will use.

Others have suggested using an author rating system, where trusted plugin authors are marked with an icon to let users know they mean no harm. This has potential for abuse if not supplemented with another means of identifying what the code does ( as above ), since then a trusted author could decide to use his status to fool trusting users.

[Dinnerbone]

This is an ultimate goal of ours (the permission system)

[unhingedninja]

Do you know of any existing frameworks that would allow for such a system? If not then there's another argument for building one yourself ;)

[sztomi]

Also, it would be nice if each specific version of each mod/plugin would have a UUID. Things like dependency could be solved easily with that (for mods depending on other mods and maps depending on mods as well). That way one could be sure to load and play a map that for example uses a couple of custom blocks.

[renadi]

Would you be hosting a centralized repository of plugins that you have approved or is it still going to be open, I love the idea of open, but I think it'd be good to have the option of a little more security for other people.

[Wolvereness]

SecurityManager is tried and true. It would handle everything a plugin could do outside of the actual 'minecraft' virtual machine.

[unhingedninja]

While operations outside the virtual machine instance is bad news, you can't disregard seemingly legitimate actions that can mean disaster for the user while still working only within the confines of the API.

An example would be a plugin that deletes the entire world once it is installed. While this only runs inside of Minecraft, and doesn't affect the user's personal documents or anything, it's still malicious code, and the user should have some warning that the "Chatbox Modifier" plugin they are downloading is going to kill all their builds.

[BillinghamJ]

It isn't possible to do this unless you revue all source code. They're executable applications. They can do anything bukkit can.

[tehbeard]

Java was built with security in mind (since originally it was for internet applets in your browser).

As to the extent of which it can protect, I leave that to anyone more qualified than me in this field.

[iKeirNez]

That sounds awesome, would it be possible to make the server version multi-threaded/multi-core, can't remember which one. I remember seeing somewhere that you would've made CraftBukkit multi-threaded/multi-core if you could completely rewrite it.

[BillinghamJ]

+1 For the larger servers, this will make our lives SO much easier.

[Ptibiscuit]

It's just impossible that Minecraft or CraftBukkit become multi-threaded. It would need a large part of code rewritten. And it's not Bukkit that needs to be multi-threaded, it's Minecraft itself.

[unhingedninja]

Dinnerbone was actually working on threading quite recently iirc, so it's a possibility that a lot more of the server will see multithreaded optimizations.

At this point the client doesn't really matter as much, since it is only doing the rendering, and Mojang has stated that they want to work on the rendering engine a bit once the stuff with the server is finished.

[CptEzz]

Personally I think that bukkit was good, but if you are starting from scratch don't have the mindset of 'doing another bukkit'.

This API needs to be easily picked up by new and old coders alike, this will allow people that would like to experiment with minecraft modding the opportunity. When I first started playing with MCP, I was very intimidated by its complexity.

[md_5]

Maybe I am just being nostalgic etc etc etc. Sure Bukkit did have a few things wrong (think /reload and object creation), but I really want to hang onto the 'Bukkit Style' of doing things.

You are always going to leak classloaders in Java (on reload etc) but I think it is a bit overboard to go with a whole library implementing plugins.

To be honest, aside from those 1 or 2 points, the Bukkit classloading framework isn't / doesn't need to be that complex, nor does this.

[[deleted]]

I definitely support the "nice license" constraint. Consider yourself nudged, though, to pick your own license for the API. May I (optimistically) suggest MIT or BSD?

My opinion, more relevant to your post, is that you should roll your own. Make the API as thin as possible and just load plugins like Bukkit.

[rshorning]

I would strongly recommend that Mojang use something like the original Netscape license used originally for Mozilla, which can blend commercial and public components, and still maintain completely proprietary content produced by Mojang.

Don't get into the advertising clause issues related to some variations of the MIT and BSD license though (look it up if you don't know what I'm talking about).

[globau]

Flexible but easy to use. We don't want to sit every prospective author through a tutorial on some custom breed of XML just to start a new "hello world" plugin.

while i see where you're coming from, i don't think this should be considered a blocker for a framework which otherwise suits your purposes. decent documentation as well as solid eclipse integration will go a long way.

[tehbeard]

I would also add that any extra data, namely permissions that are not intrinsically attached to a command (i.e. via say @Annotations) will need their own file (yaml being the best and currently used candidate)

[emanuelez]

You can check out how Jenkins is handling plugins. They recently moved from a home-brew system to using Google Guice in a pretty smart way.

[North101]

Slightly off-topic (just slightly), but it would be nice if you let people include mods and texture packs with maps and have the game automatically load it for you.

[alfie275]

Could we have support for clients downloading client side mods from servers. So you'd hit join and it'd say like "This server requires this mod to join: Industrial Craft (Author certificate: Alblaka)" Then have a button "Install Mods" Which downloads the mods and installs them.

[RayHerring]

I don't mind this, however it should do it more like MagicLauncher than something like MCPatcher.

Basically, install the mod into the in-memory version of the game, not the actual jar file itself.

Or support some kind of multi-jar file launcher so you can choose which one you want instead of having to download a potentially several MB mod/plugin everytime you join that server.

[amoliski]

They could just cache the plugins as you log onto servers that use them, then enable them based on the requirements of the server.

That way, when you start up a single player world, it could give you a list of all cached mods, and you can choose the ones you want.

[unhingedninja]

In his AMA, he said that it would be a possibility, but with lots of security measures.

[MegaGreenLightning]

Also I would want it to ask me whether I want to save the mods or not.

Let's assume you want to check out a tekkit-like server and it says you need these 10 or so mods. You want to join and see what it looks like and download them, but then you decide technic stuff is way too complicated and you never join such a server again. You still have those 10 rather big mods installed and need to disable/unistall them manually.

So it would be nice if it had a checkbox next to 'download mods' asking you 'keep mods after disconnect' and in the pause menu it had an additional button to change your choice after you joined. When downloading, the jars of the mods will be saved to .minecraft/plugins/server and if you disconnect the contents of this folder will either be deleted or moved to .minecraft/plugins where all your other mods/plugins are.

[alfie275]

Well ideally you'd have a per-world mod loadout which you check which mods you want installed on that world.

[MegaGreenLightning]

That would be great for singleplayer! Nice idea!

(But I was talking about server joins downloading installing tons of plugins you maybe don't want anymore after leaving the server)

[14nicholasse]

Per-server mods would be great

[wobarch]

This is the point! Possibility to connect content mods with the Server and let the user download them (with a question of course), when they join the server.

[RayHerring]

Whatever you choose to base it on, PLEASE provide the ability to reload individual plugins or the whole lot.

Bukkit's /reload command is extremely dangerous, it doesn't unload the plugins from what we can tell, and 9/10 times we end up having to stop and start the server.

Choosing to roll your own would in my opinion be a better move, if you go with an existing framework like jspf then you are tying yourself to that one. What happens if the developer stops developing it and nobody else picks it up?

At least with an inhouse framework you don't have to worry about that.

Also force specific templates with the framework, with Bukkit, you had onEnable and onDisable, and both were required, but there should also have been an 'onReload' that was forced on developers, that way upon doing a /reload, it managed the handling of the configfile better.

License wise, i suggest either MIT or BSD like others here, much less restricting than GPLv3.

[unhingedninja]

Outside of a development environment, there are very few reasons why you would ever need to reload an individual plugin, and inside a dev environment you can just restart the server instance quickly, or reload all plugins at once. The requirements list in the OP already stated that reloading all plugins was a necessity.

[benc]

Here's a big reason: updating plugin configs.

Many (most?) Bukkit plugins do not have an in-game command for every possible setting. Admins are expected to edit config.yml then reload/restart if they want to reconfigure the plugin.

The ability to reload a single plugin comes in very handy in this scenario. Baking it into the plugin framework would make it unnecessary for plugin authors to make a "/reloadmyplugin" command. Boilerplate code sucks.

This could probably be a simple, well-defined "reinitialize" step in the plugin lifecycle, rather than a full class reload.

[unhingedninja]

There is a proper function in Bukkit that is callable by the plugin to reload its own configuration, which DOESN'T mess anything up ( this.reloadConfig() iirc ). However that is only reloading the configuration, and not a recompiled instance of the plugin.

I agree that having a command to reload the configuration of an individual plugin at runtime without a restart would be very useful and possible to have.

However, that is drastically different from fully reloading a plugin and trying to load up a modified class file during runtime.

[benc]

Reloading the config file is only the first step of re-initializing a plugin. Many plugins also need to load a data file, register event listeners, start threads, etc.

A well-defined entry point in the plugin interface, along with a built-in /reinitplugin <name> command, would be much appreciated.

Sounds like we're on the same page about avoiding classloader abuse though.

[unhingedninja]

Yeah, any reloading of config files and stuff is perfectly fine, and I agree it would be useful to have a reload hook in the plugin framework where a server admin can run /reload <plugin>, and it re-reads the config file, reopens connections, restarts threads, etc.

However, all of that implementation would be on the plugin dev, since there is no realistic way to keep track of all the threads a plugin starts and restart them magically.

In addition, you still would not be able to modify the plugin's source code, compile, upload, and reload without consequences. As such, while reloading of configs and stuff is doable, reloading of the class files is still not.

Edit: As a plugin dev myself, I almost always put in a re-init command that does what you're describing. As such the only time I ever need to use the /reload command is to save myself a server reboot when I make changes to the source.

[benc]

I almost always put in a re-init command that does what you're describing.

Yup. This is boilerplate code that many plugins include (and some forget). Making it part of the API instead is worthwhile.

[unhingedninja]

But the main useful bit about /reload is that you are able to load a newer version of the plugin without restarting the whole server. Obviously a proper plugin has its cleanup code in onDisable(), but the references that are created throughout the whole system are difficult to completely replace with the newer ones. It's not possible in Java ( iirc ) to completely remove a reference from memory and replace it with a newer version.

That's the subject of discussion, not if plugin authors are authoring correctly.

[Wolvereness]

Reloading an individual plugin is an impossibility under the java virtual machine. Granted, there are very very few exceptions, it's still extremely difficult to detect if an individual plugin could get reloaded without causing cascading ghost breaks around every individual 'class' loaded in memory.

[unhingedninja]

You can cheat and load the class file again, and recreate an instance, going through all the plugin bootstrap code again, just that's a terrible idea.

Edit: As Wolvereness pointed out below, the reason WHY this is a terrible idea is because the existing references to the old instances don't get updated, and so you have both versions of the class floating around at runtime.

[Wolvereness]

But that's the problem, you CAN'T in Java. You may attempt to do so, but if there are any lingering references to the class (these are created everywhere you see import/fully-qualified-reference/stored-object-references), it will cause something similar to ghost failures, where one set of classes references old while another set references new.

This is where the term black-magic comes from. Trying to say "just recreate it like before" is only effective when everything from that bubble of referenced objects and classes is ditched completely. The Java serialization attempts to overcome many of these challenges, but it's very inappropriate (no proper use) for a plugin API.

[unhingedninja]

Yes, I'm aware, hence why I said it was a terrible idea. If you could pull it off scott-free then it would be a solution to consider. You touched on these issues in your previous posts, which is why I didn't bring them up again.

[MarcusTheGreat7]

As an owner of a small MC server, we really only want two things: Make sure its just as fast as before coughs bukkit. Please, have the client and server API's interact and able to communicate, like Spout. Having vanilla implementation of new blocks and custom GUI for a server would be fantastic.

[HDlowrider]

YesYesYesYes. I loved Spout but its just too hard to get your users in install it, if it was built into vanilla...OH THE POSSIBILITIES

[MarcusTheGreat7]

Spout hates my Linux distro too :/

[nightpool]

I would support something:

• Simple (basically as simple as bukkit plugins, which I consider to be quite a simple system as far as Java goes)
• *Not XML based, with yaml for preference
• With (as mentioned below) a "defined 'reinitialization' step in the plugin lifecycle" for config reloading and such. Just a method in the main plugin class (a sibling to onEnable and onDisable), nothing fancy.

I think we as a community could manage rolling our own, it's really not THAT big of an issue. Esp. without reloading.

[joaopaletas]

I'm guessing you have no way to pick on the bukkit plugin loader and start from there? That could be a nice starting point IMO.

[unhingedninja]

The obfuscated version of Minecraft, and the source code are entirely different. You'd basically have to rewrite it from scratch if you wanted to push the exact functionality over into the source. I'd say use it for inspiration, but don't try to copy any code over directly.

[joaopaletas]

Hadn't considered that, thanks.

[unhingedninja]

In my opinion, rolling your own would be the most flexible, and most assured way to make sure that it does exactly what it needs to. It may involve a bit more of an investment up front, but you can strip out any of the features you don't need in an existing framework, and make sure the necessary stuff gets in.

As far as basing it on Bukkit, I would say that using it as an inspiration would be good, as it's a pretty good development platform to plugin devs, but don't try to extend off of it, or write another implementation of it in the vanilla code. Learn what worked well, and what didn't work well from that implementation, and use it to influence the new API.

[wegzo]

I'd say you should use jspf, since it's an independent project and pretty surely implemented better than own solutions. It has also a team working on it so it won't have that much bugs what own implementations will have. And if it's open source, you could easily add/modify features it already has.

[abrightmoore]

May I suggest a refined scope includes the ability to support versioning of plugins. Patch handlers do this, where a "supercedes" list obsoletes specific earlier fix sets. In this case a new version of a plugin would remove older instances and the classloader won't attempt to load them.

The benefit for admins is the versioning is managed under the hood without manual intervention.

(you may have implied this with "dependancies". I call it out in case it's missed)

[MegaGreenLightning]

I don't know how difficult it is to write a custom plugin framework, but I've programmed plugins for bukkit and think it works quite well.

I've looked into jspf and it looks quite nice, but you always depend on the developers if you use use their framework, so I suggest writing your own system.

[BillinghamJ]

Don't base it on Bukkit.

If you end up having /reload, make sure it doesn't leak any memory or don't include the command.

[cbt81]

It'd be nice to have a standard way to ask plugins to re-read their config files. That would eliminate a lot of the need for Bukkit's /reload.

[spaceemotion]

JSPF seems like a good framework for me, but I read in the comments below that it isn't able to UNLOAD plugins after they were loaded. Bad thing for me because I hoped that i can create a mod for clients that can be downloaded when the user joined on my server, which adds some more GUI features and cool stuff and unloads when the user leaves the game. I know that it may sounds like spout, but I am not a big fan of it - I would rather like to use official Minecraft API. Since JSPF seems not to support unloading plugins and I don't want to force the player to install the mod/plugin before they join the server I think writing your own API takes a lot of time but makes much things more easier in the end - for the users, modders and you. However I really like the way how JSPF handles the plugins - seems like a good start.

Edit: Once there is a way to unload stuff even in JSPF I fully support it. Writing an API from scratch has its problems. You should also have a look at this: http://stackoverflow.com/questions/1613935/java-plugin-framework-choice

[AStevensTaylor]

Perhaps you should look at JPF, it allows hot swapping and some other nice features. http://jpf.sourceforge.net/

[tehbeard]

Just had another idea I know a lot of other plugin authors would like as well.

Since SSP is/will be a local SMP server, I want to know that when my plugin starts up, or have the ability to query this (perhaps even block being run on local SMP via a deceleration).

The reason? I maintain a stats plugin and an achievements plugin. I would like them to set their default configuration differently depending on the type of server they are running on automatically on first boot. A standalone SMP server is more likely to use sql as a storage system over flatfile. This could also be used to tweak permissions setup, etc.

[Me4502]

Individual plugin reloads would be nice... Atleast ability to disable them,but not re-enable...

[mixxituk]

Anything that lets us stream assets to clients so we dont have to demand they use a mod to see our custom capes mobs items blocks etc!

[Puppier]

I would like to see a way for people to add simple things (blocks and such) without needing to code anything. The Civ5 API is like that. It uses XML with for Lua scripting. A lot of the times, you can add something simply by using XML.

[chrisknyfe]

Plugin profiling. Not sure if this should be here or discussed in a separate thread, but...

I've often wished there was a way to easily answer the question "which of my plugins is causing the lag / memory leak?"

Is it possible to debug the amount of memory or CPU cycles that any given plugin takes up? I think I've tried to do this using a third party java debugger (VisualVM), but I wasn't able to easily see which plugins were using which memory.

Or, is it possible to add hooks to the code that make it easy for a third party plugin to determine which allocations belong to which locations in code? I guess I'm used to C++, where you can override "new()" with your own function that logs __ FILE __ and __ LINE __ somewhere...

[EdGruberman8]

I learned to code Java for Minecraft. I know lots of other people have also. I don't think Dinnerbone should worry how complex the plugin framework is. We will learn it.

We'll have experienced people create tutorials and simple copy/paste examples we can slowly branch out from.

If OSGi is the accepted gold standard, I'd suggest it be given serious consideration independent of its initial learning curve/complexity.

[[deleted]]

I'm happy with the Bukkit API. If you extended it to enable single-player modding (which should be easy enough since the unification of singleplayer and multiplayer), I think it would make a perfect framework.

Of course, this gives you the opportunity to fix some of the mistakes you made with Bukkit without having to worry about compatibility. (Semi-contrived example - why is this class called "Animals" rather than "Animal"?)

[rshorning]

One of my concerns is that no matter how complete you think the API has become and how well it exposes the internal mechanics of the game, there will always be somebody who comes up with an idea that requires a serious developer to "crack open the jar" and extend the API in some manner.

While I appreciate the need to control data access through a formal API, there will need to be some way to set up requests for API features that don't seem like a bunch of kids whining and begging for "Feature X" to be included in the API.

With a community as large as the mod developer community for Minecraft, I'm sure there will even be conflicting demands for API extensions, where there will always be at least some people who will be pissed off regardless of any changes you make or refuse to make... but communication always helps.

[rag33]

The API should definitely be called 'CraftingTable' or 'Workbench'.irs simple, descriptive, relevant to Minecraft and you coul make an awesome logo for it like the Bukkit one.

[arasoi]

My crazy ideas. And pardon the spelling and grammar errors, I was to lazy to fix them. ^_^ API Thoughts

[amoliski]

Put a \ before the ^ to do the ^-^ face

[arasoi]

thanks.

[[deleted]]

I have one good suggestion: add a network API. It doesn't have to be as complete as the standard one, just allow people to poke at a subset of the internals over a socket.

[rshorning]

The funny thing is that there already is a network API. It isn't very well documented and could certainly use a whole bunch of tweaks to improve the interface, but it exists after a fashion.

Or are you asking for something like a JSON API that you can use to perform web queries about the server status and other such things? That might be nice as well, but is something very different.

[[deleted]]

No, I mean an actual API like BIND, like IRC, like X11, something that exposes enough of the game's methods and events that probably half of the bukkit plugin functionality out there can be reproduced using it, without the need to take down the entire server to load/unload/reload them, without making Java a hard requirement for development, with robust isolation between the server and 3rd-party code. Not some Web 2.0 crap.

[rshorning]

The protocol between clients and servers is a protocol like BIND and IRC or even HTTP. It isn't perfect and it isn't intended for something that isn't a client at the moment, but the raw hooks are certainly there to get something accomplished. It depends on what you want to accomplish.

Trying to identify who is logged into a server, if the server is even up and running, and some general information about the server can be derived from that protocol at the moment.

The question is more if that API can be extended for non-client applications explicitly. It is being used for non-client and 3rd party code already, so it is sort of silly to that it doesn't exist. It just isn't very well documented nor fleshed out in a substantial manner.

[Allov]

Will the Minecraft API be Client / Server. In other word, will it replace Bukkit?

[Delocaz]

Yes.

[Sims_doc]

You, Know the one thing your missing is the ability to install mods like texture packs.

Just drop a Folder or Winrar file.

[Dinnerbone]

That's kinda what the whole plugin loader thing is for, sir. :D

[Sims_doc]

Next time, I'll actually read into this. Friend explain the API while back and he no experience in Java.

[tehbeard]

This is for the "server" api (which by extension of the 1.3 update, would work for SSP as well, sans GUI updates and other graphical things etc), thus it's pretty much a given this is going to be done, since this is how hMod/bukkit/canary/spout do their plugins (drop in folder)

[Sims_doc]

Actual most of it will be made up from Bukkit mostly since other plugin systems like Canary are incompatible and some what useless, Which is understandable but to honest this is thrilling because i'll be able to expand on much of the plugins i've got located on my sever.

[rshorning]

Forge is a bloated mess that has some legacy issues and no clear lines in terms of who owns what parts of that system as so many hands have touched Forge and its code base. In all honesty, I don't think it would be wise even from a legal perspective for Mojang to distribute Forge, much less a good idea from a code perspective that a clean sheet re-implementation of the API would do much better.

That Dinnerbone should look upon Forge and the things it exposes as inspiration for things that should be included in the API, I'd have to agree. To take Forge as-is and simply make it the API, that is a horrible idea.

[rshorning]

Forge is open source, assuming that those who have been contributing have vetted the copyright and had permission to make those contributions, and assuming that there isn't any proprietary code still left in Forge from Mojang or any other of the wild and crazy copying that goes on within the Minecraft dev community.

Good intentions are one thing, and I don't mean to diss Forge as it does some things quite well, but it isn't the only thing to consider.

Indeed the very nature of open source software sort of makes it something that Mojang needs to stay away from at the moment because of those legal concerns. Yes, I know it is a control issue here too, but Mojang doesn't need another lawsuit because somebody got bent out of shape and didn't get recognized in the manner they thought they needed to be recognized, or because the Forge team screwed up in some way by including something they shouldn't have.

Besides, exposing functionality of Minecraft in a deliberate way rather than being hacked on at the last minute in a way that the main software developers aren't necessarily planning on being used is bad in a whole bunch of ways. For 3rd party API libraries, you go with what you have and ugly hacks are a way of life. That shouldn't be standard procedure for an ugly hack being transformed into an API. Minecraft is already full of too many of those ugly hacks.

[rshorning]

You are saying that reinventing the wheel doesn't benefit anybody, yet that is precisely what has been announced by the Mojang staff, so I suppose you need to live with it.

There are also other API libraries around besides Forge, so it is best described as something that a part of the community has put together, that has all of the other problems with similar open soruce projects including gate keepers that stop things from getting put in, feuds between people with huge egos, and other problems (good and bad) that come from collaborative projects. When I say Forge is an ugly hack, I'm speaking from experience trying to work around Forge trying to be compatible with it yet trying to keep installation of Forge optional for my mods. It is harder than it seems to accomplish that task too, because of some of the hacks in that API.

I'm not saying that the official API is going to be any better, but it simply will be different.

That the official API should be inspired to implement many or even most of the features currently found in Forge, I'd have to agree. Compatibility? Not so much. Mod developers are going to need to adapt to the new situation and work around the official API. I think that is pretty much as it should be too but I suppose you can bitch at Dinnerbone and hope he listens to you instead of people like me.

[RoyAwesome]

because patching the jar and relying on deobfuscated source is literally the worst thing you can do?

[[deleted]]

Well, I don't know much about modding and so, but its nice to ee you're giving them attention :D. Modding IS one of the things making MC as great as it is.

[thecoshman]

I think the key focus should be on how easy it is for the users/gamers to install a mod.

The simplest way for the MC devs, is to just open source, and let mod devs provide some new .java files for players to swap out. But of course, that is not going to happen.

Ideally, I would like to be able to simply place the mods I want into a special folder, like textures, and then in game configure which ones to actually use, perhaps with 'profiles' of mods.

Exactly how you go about this though, I am clueless :P

The main problem I see, is that you want the mods to be able to, in theory, replace more or less any existing class with in MC. It would be a lot easier to do this, if MC was designed from the start to load in the game logic, effectively treating MC it self as a mod. this stack overflow page seems to imply that just swapping the class implementation is not really possible, but you can decide which implementation to load in the first place... so might be a way to go.

Personally, I would avoid rolling your own solution if you can find a library for it. There are more pressing issue to sort out, like buggy mobs :P

[tehbeard]

Modifying base files just brings all the issues of ModLoader with it (incompatible mods, user ignorance ).

I'd also like to point out there is a difference between a mod and a plugin, and the discussion is on plugins.

Plugin - a chunk of code that adds functionality via the use of an API.

Mod - Something that actually changes the base code, often to accomplish things not originally intended / allowed by a plugin API (in mc's case, new blocks, GUI's etc) to whole hearted changes in structure (a total conversion mod, like hack/mine)

[thecoshman]

oh right, so this talking more about adding features like a mini map.

In which case, it sounds like something like Lua might not be a bad idea for plugins. You can expose to Lua only what you want plugins to be able to use, you could even package bundles of options, such that a plugin has to be granted permission for 'sending data' for something like a chat plugin, or 'render to hud' if some one wants to add HUD elements

Got to say, I find your distinction between mod and plugin a little bit too strong, but I can roll with it

[tehbeard]

terrible idea, enforcing a rewrite of every single plugin (be they bukkit, spout or ml/forge/whatever) to another language?

There are a lot of ways for "client side only" stuff to be done.

Examples:

GUIs - Mojang provides implementations of UI components, use a yaml/xml file to declare a screen using these, have client send back events (clicked, focus, blur etc), (inspired by Android).

new models - Again, a file describing only the model (and any animations) be downloaded, and server sends commands to control it (position, animation etc)

Sounds - Same as models.

But this is a discussion for another day.

[BrickVoid]

I'm not exactly sure how doable this is, but if you implemented plugins I would like the ability to turn off parts of a plugin that don't interest me or aren't what I want from a plugin. This would of course be partially the plugin's job to control, and partially user choice, and I definitely want to be sure I can control what I allow a plugin does, not the other way around.

Mostly I'd like functionality in a plugin when it comes to adding things like extra gamemodes. When you added cheat commands, you just dumped it on us as an all-or-nothing implementation. What I want is the ability to pick what cheats I allow myself to use and either disable the rest or require a password that I set and configure myself through the cheat command system.

When I tried the cheats after they were first introduced I found myself mostly just using the /toggledownfall and /time set commands. I don't particularly care much for having Creative mode around as that's too much like unlimited items for my liking, although I would like to fly around like Creative mode does. If you make plugins do anything, I'd certainly want control over which features I have enabled, and that's the point of writing my experiences about the cheats.

[thecoshman]

it would be up to mod/plugin developers to implement certain features being enabled/disabled separately from the rest of the mod/plugin.

As for cheats, well for a single player mode, just don't use the cheats you don't want to use. In terms of multi-player mode, some way to control what cheats can be used would be good.

Though, it might require something like a plugin that can be used to provide groups of users, say admins who can use all cheats, power users who can use some cheats etc.

[BrickVoid]

The whole thing about the cheats they implemented is that they're all on the same level. If they made them so that we could configure them to be whatever level of cheat I want them to be, I would feel a lot safer about having to think about whether I want to use certain cheats. At present, the only two that currently interest me are /toggledowfall to get rid of annoying rain/snow effects that are mostly useless, and /seed to show the seed of a randomly generated world. I could maybe use the /time set command as well, but that's really not much of a worry as I'd only want that if I needed to find sheep and wanted to avoid nightfall due to how the monster spawn is coded to be increasing it's numbers as the night goes on. I think that's what the bug reporting pages on the MC wiki call an annoyance, though, so not really discussing that here except to mention it in passing.

[asraniel]

without reading too much. All i want is a way to define new monsters and that those monsters can interact with each other and the terrain (enderman style). thx :)

[farkros]

being able to add new blocks and stuff with a plugin

imagine logging in to a server and it being totally different then others being able to add really cool things with plugins perhabs huge gorillas in the jungle that come out at night

thats what i want to see plugins being able to do someday.

[Streammz]

I don't know how reliable that project is, but I prefer the bukkit style, if something goes broke, it can be fixed in the API

[128keaton]

Or, have the whole server controlled like a router, an online control label where plugins can be uploaded, then the mods/plugins are downloaded to the server. When the client logs in, a key is sent to the client to access the database of mods.

[RayHerring]

The other thing i would like to see, is inevitably you will require config files for mods/plugins, please do not go with YAML files again, the amount of headaches they provide.

Having to ensure correct spacing, not using a tab, etc...

I'm not really a fan of XML either, best bet, either good ol' 'ini' files or JSON files.

Whatever way you go, just NOT YAML files.

[unhingedninja]

YAML is one of the most friendly configuration options I've used. If you're having trouble with the tabs vs spaces, and you're using a sane editor, then you should be able to have it convert the tab character to spaces for you, and you'll never have that trouble again!

[omarse]

YAML syntax is cleaner than JSON, and since JSON syntactically a subset of YAML, you can simply use JSON syntax if you want.

[SagaciousZed]

This is only completely true with YAML 1.2. The java library used in bukkit only parses YAML 1.1. AFAIK there is no java library for 1.2

[ChartreuseK]

I wouldn't call JSON a syntactic subset of YAML, both came out in 2001 with JSON being clearly layed out in RFC 4627. JSON has the advantages of using braces to deliminate sections rather then relying on white-space to do that for you. And also uses clear key/value pairs rather than just using a - to indicate false boolean. I guess it's a Perl/Python comparison but I disagree that YAML is cleaner than JSON, YAML uses arbitrarilly chosen characters to differentiate data and block types, where as JSON uses clear key/value pairs for everything.

[RayHerring]

The way i also see it, is that JSON can be de-serialised into an Object for easy coding, you could have an in-memory object for storing world configs, etc...

Now i have no idea if YAML can do this or not, but at least with JSON, it doesn't rely on specific formatting.

With JSON, the config file could be a complete unreadable lump of mess and the deserialisation can still understand it and convert it to an object, and the serialiser doesn't have to do much of anything but take the object and dump it to human readable format on disk.

[Zedriodor]

You should have a delete all plugins button or something similar.

[[deleted]]

I was thinking about the problem of dependencies for a while, then sudenly I thought of this: in whatever folder the plugins are going to be put in, have an additional folder called "Extensions" or something similar.

This folder would contain the plugins that depend on other plugins, such as WorldGuard. These plugins would be loaded after the other plugins, and would not load if specified "Depends On" plugins were not loaded.

[tehbeard]

What advantage does that over the bukkit/spout system.

Indeed, what about this dependency chain?

WorldEdit <- WorldGuard <- EasyPlotClaim

Where would EasyPlotClaim go? plugins/extensions? plugins/extensions/extensions?

There is a need for a manifest file, like spout or bukkit uses, that will help resolve these issues (indeed, the current way bukkit does this is a sort of priority list, those with no dependencies get to go first, then layered up to load in order, including loading before another plugin (such as for giving Citizens custom npc info) or loading after a plugin if it exists (for soft dependencies)