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.
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.
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.
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.
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.
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!
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.
Links to the tweets if anyone is as interested as I was:
1I found 42 projects on github that contain the decompiled game code. Giving everyone a fair chance to fix it before I take further action.
2Yes, 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.
3Nobody will probably complain if someone copies a function or two from the code in their mod, but complete code is a different story.
4I 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.
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.
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.
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
I meant to reply to this earlier but it slipped my mind. Whoops.
Anyway, from what I understand Spigot is going to phase out all bukkit code and replace it with their own. Once they do that I can’t see any reason why they wouldn’t be able to publish the sources. Correct me if I’m wrong but, I’m also pretty sure they haven’t/won’t distribute complete game code anyway so nothing would be stopping them.
And as @modwizcode has already said, Forge or Sponge doesn’t distribute complete game code anyway so the idea that you’d have to consider “any server mod publishing sources to be very sketchy” isn’t true. This also true for granite since it states on their site that it “doesn’t contain or build against vanilla code.”
“Reflection is super horrendously slow” is a myth that hasn’t been completely valid for at least 3 years. It appears that Granite is caching classes, fields, and methods based on name, so the overhead is already greatly reduced. See the recent posts on this thread: http://stackoverflow.com/a/435571
The only real performance drawback I can think of is inability to optimize vanilla stuff like Spigot, which could be worked around with ASM or similar bytecode manipulation.
In addition, I don’t see why Granite would be “at least somewhat hard to update”. It seems like it would be slightly simpler than CB due to not actually modifying the vanilla code, and the developers are supposedly starting to automate their mapping methods.
Personally, I feel that it’s the most viable, legal option ATM. It goes without saying that this is blasphemy on the Sponge forums, but from writing a simple plugin and appraising functionality/ease of use/future update potential, Granite definitely takes the cake.
I don’t think it’s blasphemy at all. Granite appears to be our most serious competition if Husk doesn’t turn out to exist.
I think we should help them design a good API, I actually would rather team up with and have them work on a native implementation of the SpongeAPI that doesn’t rely on forge.
All I can say is for someone that doesn’t have a product out, you sure do put sponge on a pedestal, Knocking down everything else. Not that I’m against Sponge, but what have you guys got to show for it as of now? I’ve said it before and I’ll say it again Rainbow is the only working alternative at this time for a 1.8 server that i find has less bugs then the others mentioned in the OP.
I haven’t knocked anyone down and neither has @modwizcode. Yes some people are shitting on it for no reason other than blind hate but if you look at my [other][1] [posts][2] and [various][3] examples you’ll find that the only thing that the legitimate arguments are doing is stating what they feel are pros and cons about other products. Nothing more. Heck even @Inscrutable has [made some good points][4] in the previous thread.
Just because something is the only thing available doesn’t mean it’s great. And just because Sponge isn’t out yet doesn’t mean we can’t discuss the pros and cons of other servers out there. Heck I may even start using another server if one comes out with the plugins I need and looks like it has a decent future.
Also as for the “You have nothing out yet so you can’t discuss the cons of a server that is out” argument I have to say that’s simply not true. As I already stated there are pros and cons to both products and you could easily compare the two on certain levels like Dev reputation, community, api features both planned and already shown, etc. Plus, yes Sponge isnt available to download and use yet but any dev can look at what they have done and pushed to the github and see if they would want to work with it in the future. The core part of a server platforms life are the plugin devs and depending on how many are willing to make plugins for the product and which well known ones get official ports is very important.
It’s not a race to see who get’s theirs out first it’s what pros and cons each one has more than just having a working product. Again, just because a restaurant is the only place to get food in town doesn’t mean it’s particularly good for you.
I agree with you to an extent, but how is possible to say Sponge is better than (anything) because the people working on it? The same developers will be working on other platforms so this should not matter. What I’m stating is that Sponge is being being put on a pedestal, with no proof of what’s being done with it. SO yeah you have some good developers onboard, but nothing to show for it. Pros and Cons should be compared for what you have going, not what might be.
You seem to have a few misconceptions so let me clear them up:
I have Never said Sponge is better than anything and most of the valid people in this and the other thread haven’t either. If I have alluded to that then that wasn’t my intention. The point of the pros and cons is to talk about the pros and cons not compare them. And if you do compare, you can compare on the levels as I have already said. I may support sponge and hope for the best for it’s future but it isnt even out yet. Anything could happen. Heck Granite may be the best one or Rainbow a little bit down the line.
As far as I know the plugin devs may or may not make plugins because the amount of time to port to each platform isnt worth it. Even if many do, not every one will take the time to port and what matters is which ones and how many are developed for what platform first
There is plenty of proof of what’s going on with it. From the Dev irc channel to the announcements to the Github. It’s not like a secret project only the head devs are able to access. Heck they even opened up applications for other devs to work on the api and you can ask any of them.
As I said above, there is work to be shown for it.
If pros and cons are to be compared they should be compared to everything. Yes, you shouldn’t say something like “Sponge will have better performance than Rainbow” because that would be a guess. But you could and should compare things like the future plans for each project or the way each of the api’s are shaping up. But again, the point isnt to compare to sponge necessarily but to give pros and cons on the platforms stand alone. Of course some people will make the comparison but the valid ones will compare to things that are actually, well, valid at the current time. Like some of the api problems some people have stated earlier.
