API: Custom Blocks

Plugins Plugin Development
1

About

This has been an idea of mine for quite some time; ever since seeing Spoutcraft I felt like we were almost there, we were just missing some tiny little glue to make everything Just Work. Now that 1.8 and Sponge are here, everything kind of clicked together. Being involved with Sponge has given me such unprecedented access to iconic modders that I could pull the last few strings to make this work. Custom blocks that work for clients that support them, and replacements for clients that don’t.

Why support unmodded clients?

Quite simply, servers are not simple little things, and havent been that way for a long time. Some servers have a limited box area for free users. Some servers have different worlds with different features. Some servers want to BungeeCord into five literal servers, each with different custom blocks. This project is about rethinking everything we know about block modding to give unprecedented access to every play style.

How will unmodded clients use blocks with GUIs?

I’m taking a page from all the Bukkit modding I did: Chest GUIs! Unmodded users will be able to interact with block GUIs in this limited fashion.

How will unmodded clients even tell which blocks are modded?

Working on it. There has been some talk about 1.7/1.8 clients not crashing when sent invalid block identifiers. If that’s the case, I can merge non-code resource pack data from Sponge plugins on-the-fly and serve the result as the server resource pack. If all goes well, the user downloads the resource pack and the normal process of matching up textures happens. If not, we’ll get the pink and black texture, which isn’t horrifyingly bad in itself. Grum has been working on this really hard for the official API, no matter what you think, and it directly benefits us now.

When will this be released?

Some of the testing involved will require the 1.8 Forge, because client-side Forge replaces a considerable chunk of the render code in question. I move quickly though, so I hope to start releasing preliminary code very shortly after Forge releases.

Do you need help?

Of course! The more information and cooperation there is, the better all this works. I can be found quite frequently on EsperNet #Spigot (and less frequently on #SpigotDev) or send me text on the forums. Likewise, if you’re interested in helping steer the direction of the plugin-side API or are interested in making a Custom Blocks mod, let me know!

Happy modding, folks!

28 Likes
2

If this is gonna work it will be amazing :smiley:
But I thought they said it would not be possible in any way to add custom blocks etc.
And when you make this API you should make it more generic and also do stuff with custom sounds and items etc.
Because I assume when blocks are possible then those things should also be possible right?

1 Like
3

I was thinking through your idea, and realized it was totally possible. You NEED to make this.
If you actually follow through, this might be huge… something like spoutcraft, only ALSO having forge AND this new thing known as sponge API?

wheeeeeooooooo!!!

2 Likes
4

Agreed. This is a pretty fantastic idea

5

This will definetely used by many server admins and plugin creators. If it can support vanilla clients, there will be no reason to not to use it.

The server side API may possibly even merged into Sponge itself. And if not, using separate plugin is not really bad idea.

1 Like
6

10/10 would want this. I love the idea quite along time, but it was never really made, so i hope it will be implemented :slight_smile:

7

10/10 support on this. I actually found this topic while I was trying to create one on this very issue. It would really fill the gap that had always set bukkit back in respect to client-modding.
Let me know if you need anything that somebody with some Java experience can help you with.

8

This is a wonderful idea, and since Sponge will be built with Forge I agree that the time is perfect to make this happen! I am excited to see this take form and to see where it can really go!

9

You could use messages some client mods use to detect whether or not the player is using a modded client. Then send the blocks if he has a modded client (and don’t send them if not) <- With some flagging chunks this can be with no lagg

1 Like
10

Because Sponge sits on top of Forge, I get all that information free at login-time as a part of the Forge client handshaking. And there will be an optional clientside Forge mod as part of this system to allow cleaner GUIs and ensure that textures and models are applied the way they’re supposed to be. Ideally I’d be redacting or amending information for vanilla clients, rather than sending additional information to modded clients. That makes the best-case scenario a better case, and doesn’t hurt the worst-case scenario too much.

11

This sounds awesome, it needs to at least be attempted.

12

I’m down for custom blocks. But I am lost as to why you mentioned Chest GUIs here? What do those have to do with custom blocks? (side note, I think I’m the only one in the world that hates the idea of Chest GUIs lol)

13

I assume it’s for interactable blocks.
What if you wanna add a new chest block or some sort of machine block?
You would need a GUI which opens when you interact with the block.
I assume the other GUI elements will have more support as well so you can do a proper furnace GUI etc as well.

14

That’s the plan. If the proposed GUI is furnace-like, then it makes sense to implement it as a furnace GUI. Just like there can be sensible vanilla-block fallbacks for when the client just can’t understand a block, there can and should be sensible GUI fallbacks which are as close as the client can understand to capture the intent of the GUI.

This of course means that when defining GUIs, we will have to focus on intent:

This is an inventory GUI with four input slots, a fuel slot, and an output slot.

Resulting vanilla implementation: Chest GUI

This is an inventory GUI with one input slot, one fuel slot, and one output slot.

Resulting vanilla implementation: Furnace GUI

I can see a good case for a Builder/Painter pattern such as

CustomGUI gui = GUIBuilder.inventory()
    .withInputSlots(1)
    .withOutputSlots(1)
    .withFuelSlots(1)
    .build();

gui.showTo(event.getPlayer());

Now the real trick, the one that has me scratching my head, is what happens if some idiot disables our SpongeBlocks plugin? Bad things, I’m guessing. Definitely deletion of all custom blocks on world load unless we’re really devious. That’s the drawback to mods I guess.

15

If it’s disabled on the fly, I’d say send packets to the client telling it to replace all blocks with an identifier of “spongeblocks:blah” with a placeholder, and the same would happen on the server side. When the plugin was loaded back, you tell them it’s back and send the assets and models again.

This wouldn’t cover an event where identifiers change, though.

16

As the developer of OreVeins, Custom blocks would fulfill my dream of completely realistic Minecraft Geology!

17

I agree. Persistent metadata can be cool too :slight_smile:

1 Like
18

As the author of the Sensible Toolbox Bukkit plugin, I’m also extremely interested in this :slight_smile:

19

Le me is interested at this for SIP :slight_smile:

20

i would love to see a fallback for the server

problem: when there is a problem with a mod that has custom blocks and it isn’t loaded, every custom block that belongs to that mod in loaded chunks on the server will be deleted.
solution: blocks with unknown assignment will be replaced with default blocks containing all data that is necessary to restore that block later

if it isn’t possible to have this as a plugin, then it has to be in sponge it self.

2 Likes