For$
<!-- begin site header -->
<div id=

Author Topic: The new Plugin API  (Read 66870 times)

Fador

  • Administrator
  • Full Member
  • *****
  • Posts: 126
    • View Profile
The new Plugin API
« on: January 05, 2011, 12:58:45 am »
I was wondering what functions/hooks do you people really need?

So I made a new C-pointer struct based API just to see if that would really work and it did!
I have some documentation at http://mineserver.be/wiki/Plugin_API but the wiki page needs some changes because it's a bit messy with all the functions (if anyone has an idea on this, please do something ;D).

To create a plugin, you basically just need to include plugin_api.h and define init and shutdown functions (as seen on the wiki page).
I have a test plugin at plugintest/src/command.cpp just for an example. It might not be the most readable code because I just put that together for testing =/

I also made the plugin system the way, that _all_ the old plugins should work even when the Mineserver changes. (Wrapper functions and some amount of void pointers, which can be "converted" to function pointers when needed. Old plugins just think they are still void pointers)

It'll take few more days to get all the needed functions added there...

Fador

  • Administrator
  • Full Member
  • *****
  • Posts: 126
    • View Profile
Re: The new Plugin API
« Reply #1 on: January 07, 2011, 12:35:44 am »
Theres now windows builds available with command-plugin included, check http://mineserver.be/downloads/.

The command-plugin supports only /i, /home, /settime and /cuboid for now!

Fador

  • Administrator
  • Full Member
  • *****
  • Posts: 126
    • View Profile
Re: The new Plugin API
« Reply #2 on: January 11, 2011, 01:50:02 am »
The command plugin supports few more commands like /help (which will give the list of all available commands ;D)

I made some minor changes to the callbacks too..

Afforess

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: The new Plugin API
« Reply #3 on: January 24, 2011, 03:27:14 pm »
The best API would be some kind of integration with the new Bukkit server API. Then you'd instantly get access to 100's of plugins.

Fador

  • Administrator
  • Full Member
  • *****
  • Posts: 126
    • View Profile
Re: The new Plugin API
« Reply #4 on: January 24, 2011, 05:53:04 pm »
We will have some wrapper plugin to enable the use of Bukkit at some point.. Problem is that Bukkit is Java and Mineserver is C++ ;)

Afforess

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: The new Plugin API
« Reply #5 on: January 24, 2011, 07:39:40 pm »
We will have some wrapper plugin to enable the use of Bukkit at some point.. Problem is that Bukkit is Java and Mineserver is C++ ;)

I'm bukkit Plugin dev (see minecart mania), but have experience in c++, and realize that there will be a cost for language intercommunication. Perhaps plugins could run in aa separate thread to minimize the cost.

I think the thing that will make or break this project is plugins, so bukkit implementation could be just what this project needs to catch fire.

Ben S.

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: The new Plugin API
« Reply #6 on: January 25, 2011, 07:17:47 am »
This may not be very feasible because the API for bukkit is constantly changing.  I know it is still in development, but it would be very tedious to have to expose everything in the exact same way bukkit does.  Plus having this project rely on another project kind of defeats the purpose of this even existing.

As much as I hate to say it, a complete rewrite of the plugins would probably be faster than writing a very generic emulator, which would definitely be slow, and most likely pretty buggy.  Cross language communication between languages that aren't very similar (bytecode vs machine code) is very troublesome.  Calling conventions get really screwy and it is just a mess.

Eh, my 2 cents.

Unofficial Mineserver builds:
http://www.benschro.com/mineserver

Afforess

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: The new Plugin API
« Reply #7 on: January 25, 2011, 12:06:58 pm »
This may not be very feasible because the API for bukkit is constantly changing.  I know it is still in development, but it would be very tedious to have to expose everything in the exact same way bukkit does.  Plus having this project rely on another project kind of defeats the purpose of this even existing.
MineServer would never be relying on another project, it'd be providing an optional plugin/wrapper to allow bukkit to work. You'd still be able to make mineserver as you'd see fit, and have the bukkit plugin do the heavy lifting.

Quote
As much as I hate to say it, a complete rewrite of the plugins would probably be faster than writing a very generic emulator, which would definitely be slow, and most likely pretty buggy.  Cross language communication between languages that aren't very similar (bytecode vs
machine code) is very troublesome.  Calling conventions get really screwy and it is just a mess.

Well yes, this is all true, but gaining access to potentially thousands of already working plugins would be huge. If mineserver is as fast as they claim (I'm sure it is) then the cost of extra communication would slow it some, but even 7-8x the java server is huge.
« Last Edit: January 25, 2011, 12:09:16 pm by Afforess »

Andrew

  • Developer
  • Newbie
  • ****
  • Posts: 9
    • View Profile
Re: The new Plugin API
« Reply #8 on: January 27, 2011, 12:38:05 pm »
It would be less work to simply port the plugins to c++

Afforess

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: The new Plugin API
« Reply #9 on: January 29, 2011, 06:02:53 am »
It would be less work to simply port the plugins to c++

Port 250+ plugins would be less work than a creating a bridge between Bukkit and Mineserver?  ???

Ligustah

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: The new Plugin API
« Reply #10 on: January 29, 2011, 01:21:02 pm »
In my opinion bridging to Java plugins would somehow defeat the purpose of Mineserver.
If i am not mistaken it is supposed to be a very lightweight and fast server, while Bukkit
is more like a mod of the original server.
I would rather like to see a feature-complete Mineserver, which is easy to add plugins to than one that is beaten into an interface just to meet compatibility with a bunch of stuff already done. I mean the whole idea of Mineserver was to create a complete re-write that is focussed on performance, so why should the devs bridge to plugins that are not really optimized for how Mineserver works?

Don't get me wrong here, i'm a fan of http://en.wikipedia.org/wiki/Don%27t_repeat_yourself but i do think sometimes stuff has to be thrown away to get things forward. Backwards compatibility (i do consider the java server inferior here indeed) is not an option, in my very humble opinion.

If at all, it is a thing to achieve when Mineserver has all caught up with the original Minecraft server.

Ben S.

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: The new Plugin API
« Reply #11 on: January 29, 2011, 08:14:52 pm »
It would be less work to simply port the plugins to c++

Port 250+ plugins would be less work than a creating a bridge between Bukkit and Mineserver?  ???
There's really only a few plugins worth porting.  The rest are trivial and can be written in probably 5 minutes.
Unofficial Mineserver builds:
http://www.benschro.com/mineserver

Afforess

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: The new Plugin API
« Reply #12 on: February 06, 2011, 09:37:09 am »
In my opinion bridging to Java plugins would somehow defeat the purpose of Mineserver.
If i am not mistaken it is supposed to be a very lightweight and fast server, while Bukkit
is more like a mod of the original server.
I would rather like to see a feature-complete Mineserver, which is easy to add plugins to than one that is beaten into an interface just to meet compatibility with a bunch of stuff already done. I mean the whole idea of Mineserver was to create a complete re-write that is focussed on performance, so why should the devs bridge to plugins that are not really optimized for how Mineserver works?

I agree completely. I'd mourn if Mineserver tried to conform to someone else's arbitrary standards, and wasted potential on that.

But there's no reason we can't have our cake and eat it too. Plenty of plugin API for mineserver matches up 1 to 1 with Bukkit API, and would (I hesistate to use simple...) be possible to convert over without harm. I can't imagine most plugins harming performance by more than 20%, perhaps less if they were run in separate threads.

If at all, it is a thing to achieve when Mineserver has all caught up with the original Minecraft server.

Definitely, but now's as good of a time as any to bring it up.

It would be less work to simply port the plugins to c++

Port 250+ plugins would be less work than a creating a bridge between Bukkit and Mineserver?  ???
There's really only a few plugins worth porting.  The rest are trivial and can be written in probably 5 minutes.

I'm not even going to give a response to such a ludicrous statement.

Gutter

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: The new Plugin API
« Reply #13 on: February 16, 2011, 06:48:33 am »
I checked the plugin API, and what is needed is some access to the map generator...

Unless it's expected to be all done through the server? But none of the function seems to address that. It would be a leg up over the vanilla emulator. There are some great algorithm emerging left and right, some are bound to be coded in this kind of server soon.

xoft

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: The new Plugin API
« Reply #14 on: February 16, 2011, 11:04:49 am »
@Gutter: nice idea, but this needs a bit more thought before actually implementing this, so that it can be done nicely:

I suggest each world gets a "style" assigned to it in the config file. Then the server triggers a "chunk needed" message whenever a new chunk needs to be generated; plugins check the "style" attribute of the world and if they handle that style, they generate the chunk; otherwise they ignore the message. If no plugin handles the message, a default generator generates the chunk.

This way we could implement other generators as plugins and they would be completely configurable as to which world, if any, they generate.
-> Nether generator
-> Heaven generator
-> Flat world generator
-> Cave-only world generator
All of these could be used for separate worlds, with warps between them.