The Meaning of Life, the Universe, and Everything.
Join Date:
3/29/2014
Posts:
66
Location:
KWIK WHO'S DAT BEHIND YOU?
Member Details
The Slimeball Project is a replacement for the Bukkit Server and API.
It's aim is to provide a stable, rock-solid core for developers to build server mods and plugins on,
allowing server admins to continue the management and the aspect of fun on their servers.
WHY SLIMEBALL?
After Bukkit was DMCA'ed, many new modding API's have sprung up out of the blue (or some less popular ones have become more so), yet a few come with a catch or two. For example, the Sponge Project is built on top of
Forge, which uses ASM. Put simply, this complicates things for developers, along with the fact
that Forge updates come out much later than the updates of Minecraft. If Forge doesn't update
quickly, Sponge updates will lag behind too.
Slimeball is not built on top of Forge (and doesn't use ASM either). Because no large dependencies
like Forge are used, it will be a simplistic, non-bloated, and easy to update API.
Slimeball's advantage over Forge is that plugins written for it will
most likely work with the next several updates of Minecraft. Slimeball will also continue to be developed for quite a while to
come, unlike BlazeLoader (abandoned?) and ModLoader, along with some others.
The API included with Slimeball is simplistic, similar to the Bukkit API. The same kind of functionality that was offered with Bukkit will be included with Slimeball, including an event system,
Looks promising. If it gets far enough, I will make an official extension to the Quantum API for compatibility with The Slimeball Project's plugins.
Q: Will Bukkit plugins work on Slimeball?
A: It depends. DisguiseCraft, MobDisguise, and other plugins that require the ProtocolLib will most likely not work. They will have to be ported to a different system of "client exchange".
I'm not here to advertise, but as Bill Nye said, Consider the Following: My API plans to have a client exchange. Since everything is in it's own layer during execution, It's much easier to debug mods (and plugins), and especially allows custom Object exchange between server and client. You don't have to touch any minecraft objects at all (including Netty or any library alongside minecraft). Look for the Quantum API page in the WIP mods section with prefix "Api".
The Meaning of Life, the Universe, and Everything.
Join Date:
3/29/2014
Posts:
66
Location:
KWIK WHO'S DAT BEHIND YOU?
Member Details
The reason that plugins depending on ProtocolLib will not work with Slimeball is mainly due to the Bountiful Update changing a lot of the game, and how the classes provided by the Bukkit API used by ProtocolLib are not going to be included (the Bukkit functionality is a wrapper over Slimeball classes). These plugins will have to be adapted to the packet system (client exchange) used in Slimeball.
Then make an implementation of ProtocolLib that conforms to the new packet system, or let me do that because inevitably I'm going to start work on the Server API and a Bukkit extension for it. I doubt anyone wants to go through that much refactoring (especially if it's a large plugin) just to conform to this new server-client exchange mechanism introduced by the Bountiful Update.
The Meaning of Life, the Universe, and Everything.
Join Date:
3/29/2014
Posts:
66
Location:
KWIK WHO'S DAT BEHIND YOU?
Member Details
Along with one small addition to the post above:
I am currently making a multiplayer-only 2D platformer game, with a built in mod-loader.
While it sound like a really stupid idea and I acknowledge that, I may (as in about a 1/50 chance), port the base of the built-in mod-loader code to the Minecraft Server.
If I do make the port, this will be released as Slimeball2. However, please do not PM / e-mail / (ask in any form) me about it.
Looks promising. If it gets far enough, I will make an official extension to the Quantum API for compatibility with The Slimeball Project's plugins.
I'm not here to advertise, but as Bill Nye said, Consider the Following: My API plans to have a client exchange. Since everything is in it's own layer during execution, It's much easier to debug mods (and plugins), and especially allows custom Object exchange between server and client. You don't have to touch any minecraft objects at all (including Netty or any library alongside minecraft). Look for the Quantum API page in the WIP mods section with prefix "Api".
The reason that plugins depending on ProtocolLib will not work with Slimeball is mainly due to the Bountiful Update changing a lot of the game, and how the classes provided by the Bukkit API used by ProtocolLib are not going to be included (the Bukkit functionality is a wrapper over Slimeball classes). These plugins will have to be adapted to the packet system (client exchange) used in Slimeball.
Then make an implementation of ProtocolLib that conforms to the new packet system, or let me do that because inevitably I'm going to start work on the Server API and a Bukkit extension for it. I doubt anyone wants to go through that much refactoring (especially if it's a large plugin) just to conform to this new server-client exchange mechanism introduced by the Bountiful Update.
*** Captain obvious strikes again! ***
For whom it may concern, this project is DEAD and will remain DEAD to the point of which and after of when I become DEAD.
I have semi-quit Minecraft and moved on to better things.
Along with one small addition to the post above:
I am currently making a multiplayer-only 2D platformer game, with a built in mod-loader.
While it sound like a really stupid idea and I acknowledge that, I may (as in about a 1/50 chance), port the base of the built-in mod-loader code to the Minecraft Server.
If I do make the port, this will be released as Slimeball2. However, please do not PM / e-mail / (ask in any form) me about it.
-Noodly_Doodly
Question: Can I work on your project?