I present the recording of the State of Sponge 2.
I’m providing the source for the fireball plugin used on the demo server HERE.
The same plugin can be built with Scala for those who don’t want to be coding in Java, but still wish to use SpongeAPI. That repository is located HERE
We’ve put down some of the main points covered in the State of Sponge here, be sure to read it if you don’t want to rewatch the stream. More will be entered here as we get around to typing it out.
For someone familiar with Bukkit, porting over will be fairly straightforward. Possibly the biggest difference is the complete avoidance of enums because they don’t really support custom types very well. Instead, you need to ask some sort of registry object for information, but this is pretty simple. A plugin’s initialization is a bit different in Sponge, but seeing an example plugin should answer most questions.
We are working hard on some pretty in-depth documentation (https://docs.spongepowered.org/), which we plan to mostly complete by the time we make regular releases. Some pages currently fairly thin as we figure out better ways to do something in the code.
With the docs, we’d like to reduce the number of times you need to look through a bunch of dated forum threads to find the current way of doing something.
This is answered by the next question.
Spigot has been making frequent releases – what is taking Sponge so long, and what is the point of Sponge then?
Remember that Sponge is starting anew, so even boring, foundational things like loading plugins or handling events need to be coded. Something like Spigot is able to re-use the code that was written many years ago by other people. We cannot simply copy this code from Bukkit because one of our goals is to not mar ourselves in the legal problems of Bukkit (which, for example, prevents Spigot from hosting their code on a public code website like GitHub because they’d be shut down).
Once Sponge finishes these foundational things, we will be at the same point as something like Spigot, and so updates should roll around just as quickly. In addition, we’ve chosen to update Sponge in a way that’s a little different from that of Bukkit and Spigot. This process does require a little more initial investment on our part (explaining some of our delay), but like organizing your closet, it means everything is so much easier afterwards.
At the moment, we’ve already finished the basic things of loading plugins and being able to raise events. What we’ve been working on now is connecting the “Sponge API” to MC code. For example, Sponge, like Bukkit, tells plugins when an explosion is starting and when it has happened. To do that, however, there isn’t just one place in Minecraft’s code where it happens – we have to find them all. Creepers explode, but so does TNT. We have to find every place that explosions happen and then add in our own code, and unfortunately, what often takes up the most time in programming is fixing and testing to make sure that the code actually works. We do happen to know all the places: it’s just time for the code. Just like those foundational things, something like Bukkit already has this code in all the necessary places. We will get to the same point too.
OK, so now you might be asking: “doesn’t that just make Sponge end up becoming the same as Spigot or Bukkit after all of this is done, just perhaps without legal problems?” While we do plan to make Sponge do everything the Bukkit API can do, we also plan to go further.
The amazing thing that Bukkit did was making modding MC straightforward – no more having to deal with 100 hours of work that no longer works the next MC update, or from the standpoint of server owners, “yay – I get to use a plugin that the author abandoned a year ago!”. However, Bukkit was made with that idea that Minecraft would never have custom blocks, entities, or game types. It has no way of adding new blocks – whether “fake” (powered by just resource packs and events) or real. In fact, if the Bukkit API was simply applied to a copy of Minecraft that had custom blocks, a Bukkit plugin would not even be able to tell that a custom block type existed.
Our goal is to fix this for two scenarios: servers that allow unmodified “vanilla” clients to connect (anyone can connect), and also servers that do use some sort of client modpack.We know people make minigames and survival servers with custom gameplay, and we know people go through some creative loops to do fairly basic things like add custom behavior to an item, entity or block. Want to make some sort of special sign that takes Redstone input to emit fireworks? If you were modding MC, you could very easily add this new “block” with a few lines of code, but in Bukkit, you need to handle a dozen of events, write custom code to keep track of state, and do a bunch of other things that Minecraft already completely does for itself.
Our goal is to let you tap into this. Want to create a custom block? Just register a custom block with Sponge and tell Sponge some basic properties: if you are aiming for a server with unmodified clients, then Sponge will co-opt an existing block (like a sign), hook into Minecraft’s code, and then handle the rest. If you are planning for a Sponge client mod, then Sponge will let you register a completely new type of block – possibly with custom rendering – and you’d be able to reuse most of the same code.
Another example is with AI: Minecraft has an internal API for AI. Want to change how mobs wander? Normally it’d be pretty easy to do if you were simply modding Minecraft, but doing the same thing in Bukkit is much more complex and also much less efficient.
In addition, should the proposed Mojang API come out (which theoretically would expand the possibilities of modding MC without requiring any client mod), we will continue to develop Sponge and also support all the features of Mojang’s API. That means that if you write code now for Sponge, it will still work in a few years’ time, possibly after only a few minor changes.
Lastly, we also plan to support mundane things not supported in Bukkit like being able to work with NBT data or being able to tap to the new MC features like attributes. Maybe we’ll figure out a solution to the pain of using common, large, custom Java libraries in your plugin.
Performance is definitely important to us. Many of our team members are familiar with the topic.
While we can’t give hard numbers on where we compare with Spigot, we are doing two things to ensure performance parity of or at least with Spigot. First, blood is our lead developer on the performance portion of Sponge. His previous project – Cauldron – was the merging of Spigot and Forge, something he has done for several years now, so he is extremely familiar with both Spigot’s and Forge’s code. He’ll be spending time writing code to come in and optimize the Minecraft server while contributing back to Forge where we can.
Second, we do plan to reuse some of the performance tweaks used in Spigot. While we can’t use Bukkit’s code in Sponge because of license incompatibilities, performance tweaks in Spigot were written by a few people and Aikar and mikeprimm have given us permission to use their work.
Performance is one of our key goals in Sponge. For example, we have spent quite some time making sure that our event code was extremely fast (it is much faster than Bukkit’s or Spigot’s).
Without a packet API, how will it be possible to support disguises?
We are not considering the packet API at this time, so our current approach will be to allow a third-party plugin like ProtocolLib to provide the missing functionality.
Most recently we have finalized deployment of the documentation, translated documentation, as well as the new theme. All of you can see this in effect at the https://docs.spongepowered.org/ URL. Currently the documentation is hosted using Github Pages and built primarily by Travis; we hope to migrate this into our own private CI and servers. The source will stay where it’s always been, at GitHub - SpongePowered/SpongeDocs: Documentation for Sponge and its Implementations. We invite any PRs or docs contributions to that repository as well as translators at https://translate.spongepowered.org.
Most of our time recently has been spent getting the documentation up and running, which we consider to be a higher-priority project given our current websites. However, this task is mostly complete, which means we are able to concentrate more on our grand plans of unification of the Sponge web presence as well as the Ore plugin repository.
We’d like to share a sneak peek at the mockups for the Sponge websites from our designer, Kornagan:
As you can see, the unified navbar is coming along. We have tried several designs while trying to unify the Sponge sites, and have mostly settled on a navbar along with a dropdown. We have begun theming the forums, designing a new homepage, and styling the docs to fit in with this unified vision.
Unfortunately, Ore has been on the backburner for a while while we have been concentrating on the documentation as well as the upcoming unification. Because the documentation deployment project is mostly finished, this means that Ore now has time to be worked on, and will be a project of higher priority. The goal is to complete Ore a little before or during the implementation release so that developers will have a single place to share their Sponge plugins from day one of the Sponge release.
Ore has undergone a few recent refactors and cleanups of the codebase in preparation for more work to be done on it. As always, it is open source at GitHub - SpongePowered/Ore: Repository software for Sponge plugins and Forge mods and we appreciate any contributions.
Hey that’s my job 
Ffffng I missed it, again! I requested an at-home reminder, damn it! 
Screw verizon… I had to skip the stream and miss the fun because the internet sucked so bad… :c At least I get to watch it now though…
I added some links in the OP that reference the repositories for the fireball plugin and how it works. Just for those who are curious.
Brilliant new spongie! 
Can you post a screenshot of the new spongie? I can’t rly seem to find it in the SoS and I don’t rly have time to watch all of it right now. xD
I like SoS. Good to see where we are and a great possibility for the devs to present their work to each other.
SoS II at about 1h 20min. Most people voted vor the “evil”, “serious” version 
I liked none evil, but whatever.
The old Spongie is better…
What? Didn’t you see the github link?
Can anyone Tell me The Sponge Testserver IP ?
I did, but is ore the only website that’s currently developed? AFAIK it’s just a WIP plugin repo
It’s private for very obvious security reasons. It’s also non-reusable code which would gain nothing from being open source.
The homepage pulls a bit of data from the forums, and how it does that is protected by a secret token. While setting up the infrastructure for pulling the token from the deployment configuration is really easy, it’s an extra task that we really don’t want to do, since there are more important and urgent things.
tl;dr We don’t need any help on the homepage, thanks. Any help on Ore would be greatly appreciated
We can’t use the old Spongie. It has a spigot and a cauldron attached, which have been deliberately omitted to avoid references to (and reliance on) other projects. New drafts were not forthcoming, attempts to get more from the original artist failed. We need a high quality vector art version.
We also tried the old Spongie’s face on this, and it wasn’t as popular as alternatives.
One of the big problems with selecting art assets here is the focus group keeps changing. We just need to settle on something acceptable, not expect the final product to please everyone.