IDs on signs

1.13 poses a few interesting challenges for CraftBook. The biggest of which is items and blocks on signs. This idea is used throughout the plugin and underpins many of the main features.

The main annoyance regarding this issue, is I fixed it back in 2014 with CraftBook 4. CraftBook 4 never requires entering items or blocks on signs; however, it depends on a feature that is not realistically possible with Spigot.

The current solution has been to allow legacy IDs for existing blocks and use 'minified' (without the minecraft namespace) string IDs for new blocks. In the few cases where they're still unable to fit on signs, CraftBook's Variables feature allows for it to still function. This recommendation is a temporary solution.

Spigot Bugs

Another major issue that I've encountered is the instability and bugginess of the Spigot API. Upon first updating the plugin, over half of the features didn't work purely due to Spigot not correctly handling API calls and events. Even now, I'll find issues caused by a new bug in Spigot.

CraftBook uses almost all of the Spigot API, making it one of the most common plugins for encountering bugs within Spigot itself. Due to this, I quite frequently run into very niche issues, some that have existed for years.

I've gotten some of these fixed within Spigot and others within Paper. However, many are fundamental design flaws that Spigot can't reasonably fix. For these, I'd need to create new additions to the API, and Spigot is less likely to accept these.

Modernisation

Having to make such significant changes to the plugin meant this was also a perfect time to modernise the plugin. The build system has switched to Gradle, meaning builds are once again available on builds.enginehub.org. I removed the WorldEdit API's deprecated usages and made few other minor changes to ensure the plugin has a modern codebase.

Plans for the Future

My current plan is to build the WorldEdit API to a point where CraftBook can exist on top of it. This plan is quite an enormous task, so it won't happen in the short term.

The goal here would be for a thin platform layer to sit between Spigot and CraftBook, meaning there is much less code that Spigot bugs can break.

This goal is also where CraftBook 4 comes into it. Maintaining CraftBook for both Spigot and Sponge as two separate code bases was an awful idea. The intention here is to have CraftBook 5, compatible with Sponge and Spigot, and based on the CraftBook 4 source. It's unclear how I will replicate the Sponge-specific features on Spigot at this stage. My main idea is to require Paper and add the necessary functionality there.

For more updated information on CraftBook 5, check out this article!

I've devoted countless hours to working on this project. If you'd like to support me, I have a Patreon and accept donations through PayPal. Thanks 😁