An Appraisal Of The Competition

General Discussion
1

I have to say, I like that Granite is actually a working (although a lot of stuff isn’t there and what’s there sometimes doesn’t work). I have a personal fork that I’ve been messing around with because it’s similar but at the same time very different to how we are doing it.

I think that due to progress made and plugin support it’s either going to come out with Spigot / Craftbukkit (if they can combat the DCMA), ourselves (if we are able to promptly get an API out and get the implementation going) and Granite (if they can expand their API and make themselves work well).

Granite suffers from a large amount of reflection and although it seems very well done from my pov, it’s going to be at least somewhat hard to update. Furthermore the reflection imposes at least a small speed penalty regardless.

SpongeAPI+Sponge: This is the main project, and it’s pretty good, however it suffers from not existing/having nothing to give people. Our dependency on not just FML but forge means that updates will be a bit slower than any system developed right on the server code. Note: This dependency is just in relation to the forge based implementation

Glowstone+SpongeAPI: This pairing is cool, but suffers from Glowstone’s continued lack of a full implementation of vanilla Minecraft’s functionality. Hopefully the flood of programmers that sponge brings will fix this limitation and it will update in a way similar to Forge and FML, changing only the implementation of the protocol and adding support for new features.

Obviously any Bukkit based system has the (very small) risk of Mojang’s ownership of the API. And anything based on Craftbukkit has the DCMA takedown to worry about.

Rainbow seems sketchy to say the least. It’s got a jar out and some starting (poorly coded/crap) plugins. But I couldn’t find any source at all which isn’t a pleasant thing to think about. I have also discovered that they bundle the vanilla Minecraft server jar with their download. Which, after all that has happened, is not smart at the least. As for their code, it’s not great. They don’t even seem to have their act together as much as the Bukkit team did. I will update this with more details once I’ve played with it more.

To wrap up the largish projects I would say that Husk has a good website, a good idea and possibly offers real competition to Sponge, but is being hush hush while they hammer out the API and implementation. Possibly waiting for the competition to become more clear giving them a direction to follow with their API. I’m interested in the outcomes here.

Note: If you want another platform appraised, just send me a PM.
Update 1: Updated Sponge information to mention Glowstone and added more information to Rainbow.
Update 2: Found Glowstone implementation beginning and added separation to Sponge vs. Glowstone implementation.

2

@modwizcode Sponge won’t be limited to Forge, you forgot to take that into account.

3

I will appraise the glowstone implementation when it exists enough to appraise (aka. Not just talk). Send me a link if I just missed it.

4

I don’t like that Rainbow is “building-in” features that aren’t really needed for 100% of servers, like a /tpa command for example.

Spigot guys recently posted that they plan to really run for 1.8. I have some serious doubts - since their plan is to patch out all of the craftbukkit code until they no longer have to worry about DMCA (during which time no one can legally download the original file that patches apply against!), I think the project is much too large for them. Spigot was a smallish modification of CraftBukkit, but this new project amounts to completely reimplementing CraftBukkit via a series of patches. Even if they can pull it off with their smaller, less experienced team, my guess is that Sponge will be up and running long before they have a legally downloadable release suitable for new server owners to adopt their platform.

I’m personally running one of their patches on my server now because I like that 1.8 clients can connect, so I’m definitely hoping I’m wrong on this. It would be a better overall result for the community if we could continue to run plugins without having to wait for them to be ported to an entirely new platform, and for all the resulting bugs to be worked out.

3 Likes
5

I think it should be configurable, but that command is so useful that I would vote for it being part of vanilla. Building in isn’t great, probably should use a prepackaged plugin or the like instead, but it certainly ends things like 100+ essentials plugins that are mostly poorly coded copies of the same concept with little to no variation.

6

Respectfully disagreeing - I don’t like that players can use /tpa to save themselves from being lost (which a timer or a cooldown doesn’t fix). I like that CraftBukkit’s out of box was just like Vanilla, as far as player experience is conerned. To me it’s annoying to have to go through the trouble of disabling extra features I don’t want - I’d much rather install only those I do want.

7

Actually besides building in the permissions CraftBukkit (not bukkit) changed the mechanics of the vanilla commands and added in several such as reload and plugin(s). I see your point, but a lot of people like a out of the box setup that has what they want, and one jar is kinda nice.

I like being able to go back so that I’m not lost, it’s a waste of gameplay that I don’t need to do when I’m just having fun. Sure it’s great for hardcore survival, but I rarely find like vanilla servers without it.

But I also agree with you, it’s probably not a smart choice in general.

8

True, but these are administrative changes, not player changes. To a player, CB without plugins feels just like Vanilla, I think.

Also, it’s difficult (impossible?) to decide on one design of a popular feature that everyone likes. Even something as simple as /tpa varies a lot. Should it have a cooldown? Can I use it underground? Can I use it to move from one world to another? Can I invite others to TP to me, or only me to them? By the time code and config options are added to support all these popular variations, you’ve got a project inside a project, and I’d much rather the platform developers spent all their time on keeping the platform up to date, reliable, and performant.

9

Yeah that’s basically what it boils down to. In my mind you can only solve that with what vanilla does. It picks the approach it wants and stays with it. If you don’t like /tell on a vanilla server, too bad for you. That’s the beauty of being the default.

So I make a very simple /tpa command and then let people that don’t like it disable it. Then they can make their plugin replace it, but at least it’s built in so that the person who wants a simple command doesn’t have to spend forever configuring a package that had the one they iiked.

10

You say rainbow is sketchy. But Im running 2 rainbow servers one with towny with the made perm plugin for rainbow.no errors no lag through bungee.I do not have a problem. I might not be a coder but I have had less errors with rainbow then bukkit/spigot. I think you need to do some more testing.

1 Like
11

Yes from a user perspective rainbow works just fine. If someone says that its poorly coded he should explain it.

1 Like
12

I don’t normally speak out at an individual user in forums, on the internet or in person during my normal day. But I just spent the last half hour reading every single post on that Rainbow vs. Sponge thread and you’re worth getting annoyed with.

People have been supportive of Rainbow, the Rainbow developer has come over and joined the community, wanting to work with us so it could be possible to load Sponge’s API on Rainbow, just like a Bukkit compatibility wrapper, except for Sponge. In return you’ve only been rude. You responses are poorly written and make you sound like you’re fourteen or fifteen years old. Which could be an issue with English as another language, however you haven’t said that anywhere and I don’t see real good evidence of it. The post was about the work on the coding, I haven’t had time to test the platforms or inspect the communities yet.

I agree that “sketchy” is a terrible description of anything, and I do still want to take another look at Rainbow as I like to inspect all the new 1.8 stuff to see how they’ve chosen to design it. However Rainbow is the only project as of right now, that has not made any code available and unlike Husk, Rainbow has not shown any desire to do so. In most situations that just makes Rainbow yet another proprietary application, which might not be ideologically favorable, but generally works out fine. However, this is not the norm with Minecraft plugin platforms.

I will say I disagree with some of the design choices made with Rainbow, namely not separating the API and the server jar and not deciding to distribute it as a patch or other legally sound distribution mechanism. It’s up to the developer of Rainbow to decided what he wants to do. I think it would be great for Rainbow to be less shaky legally, because it would mean that Rainbow doesn’t get washed away in the future.

I’ve not said that Rainbow doesn’t work as advertised, or that it’s not a stable server to use. I have just said that my appraisal of it worries me. I wouldn’t want servers to be built or plugin developers to invest themselves in something that hasn’t built itself up on secure principals.

As I’ve said I like the work and planning that I’ve done when working on Sponge, both in working on the API and the implementation, it’s clear that we have a very confident and competent group of developers putting their minds together here. I’ve worked a bit on Granite and worry about their lacking documentation and frequently broken master branch. These aren’t issues with the code itself or the community, these are easily fixed platform issues that are part of any project that will be used by someone other than yourself.

7 Likes
13

Here are just three I found after skimming the previous thread:

That seems pretty reasonable. Things might’ve changed since when these were posted but they are/were valid points to make.

1 Like
14

These are the same issues I was seeing in that thread. As I’ve said, easily fixed. An event bus is more work, but it’s fairly simple and can be searched online.

Heck I’ll even fix the code so they don’t have to. If their plugins are broken (as they probably would be by the package change) the plugin developers should be active enough to fix it. If not, then when loading the plugins they can remap the classes.

1 Like
15

I was catching up on the latest and saw this thread. Good idea to get a summary of current state and evaluation.

First, I welcome everyone’s opinion on Rainbow, good or bad. Some things to consider in counterpoint to the negative things raised:

  • Searge at Mojang has signaled they are taking action against publishing reverse engineered sources. As such any server mod would be wise to not share code. Any projects currently doing so are at legal risk. This has been the primary reason to not share. I posted about this legal aspect a few weeks ago and turned out to be true.

Searge Tweets:

I found 42 projects on github that contain the decompiled game code. Giving everyone a fair chance to fix it before I take further action… I contacted all of them. It’s ok to decompile the game to make mods for it, but it’s not ok to publish the decompiled code… People decompile Minecraft to make mods. That’s ok as long as they do not publish the decompiled code.

With this latest information, I think you’d have to consider any server mod publishing sources to be very sketchy. This also means when Spigot for example is done with their work, they won’t be able to publish sources for people to contribute openly to (at least not the server pieces).

About other things:

  • On Rainbow including features you don’t want. There are permissions for them all now you can run without any commands available to users. But there’s a logical reason they were there to begin with. It’s because originally there were no plugins available for a fresh 1.8 project. In order to provide something until plugins could be built, those were added directly into the mod. They will be phased out now that they can be moved to a plugin.

-The criticism on code is amusing. To each their own coding preference, it’s all 1s and 0s in the end. I only criticize code when it doesn’t work or is unnecessarily complex. If you find places where “This code doesn’t work” then I’ll be very interested and look to fix it! :hammer:

PS: Spigot status update looks promising. I wish them the best and don’t see anything stopping them. Technically it’s straight forward from where they are just requires hard work and following through.

4 Likes
16

Links to the tweets if anyone is as interested as I was:

1 I found 42 projects on github that contain the decompiled game code. Giving everyone a fair chance to fix it before I take further action.

2 Yes, I contacted all of them. It’s ok to decompile the game to make mods for it, but it’s not ok to publish the decompiled code.

Also these two also seem relevant. As for how much, I wouldn’t know since I’m not familiar with how this works but still I thought it would be a good thing to show.

3 Nobody will probably complain if someone copies a function or two from the code in their mod, but complete code is a different story.

4 I want to make sure everyone understands that I’m talking as the founder of MCP and our TOS, this is not related to Mojang in any way.

17

Thanks @DoingItWell I was hoping you might find the thread so I could get some idea of what you were thinking.

My critique of the code style is more the use of underscores and not using packages, which goes directly against both Oracle and Google’s published style guides. It’s common practice for beginner developers to not use packages, but beyond that I can’t say I’ve ever seen a developer choose not to use them. It makes the code way to complex to maintain in the future and can actually cause some very odd compiler issues (These I’ve had).

The point about plugins not existing makes a lot of sense to me. Bukkit actually had some in house plugins that weren’t part of the server, but were developed by the team called HomeBukkit, ScrapBukkit (and I think there was another one). However the concept of having to disable a non-vanilla feature is a little unusual given that no successful server has bundled commands that were default on.

As for published source, the whole reason other mods have such unusual ways of making their projects hook into the server is that Mojang made their position on decompiled code clear. Basically you can distribute your code as patches to a standard decompiled jar made via your toolkit. It’s a more annoying approach but it will be nice for people to get a copy of your code to make changes.

1 Like
18

I should have seen this post earlier, somehow I missed it. The Spigot team is amazing, lots of people from the Bukkit staff are actually also Spigot team members. MD_5 for one is an excellent programmer.

Given the time needed to properly write and implement the API for Sponge, I doubt that the Spigot team can’t beat us, they’ve been working on it for longer. However I welcome the competition.

I would have to say that one of my first Minecraft modding projects was to try and patch MCP to support a snapshot. That didn’t work so well, as I’ve written about in the past, each team seems to want to keep their remapping tools close to the chest. Making each new project have to reinvent the wheel and start from scratch. Everything but the most important piece, the part needed to update, is put up as open source. However the homemade tool used to remap is kept by a few, a sacred torch of Minecraft decompiling if you will.

19

In fact, I was gonna contribute an event system that I’d just written for a project I’m working on to rainbow, when I realised that they don’t have any code up. Granite is looking quite interesting :smiley:

Edit:

Pheraps you coud add a link to

under rainbow.

21

You just added the link :slight_smile:

Granite’s code needs to be a bit more understandable and such. Also it has the potential to be very slow given the extensive reflection.

But I like it’s unique approach.