Nukkit 2.0 Alpha

Nukkit 2.0 is now in alpha with support for blocks above ID 255 (old chunk format limitation), LevelDB support, faster chunk loading and a variety of other features that listed are below. This build is NOT intended to be used in production environments as there are still major bugs that could potentially corrupt your world.
Existing anvil format worlds will be automatically converted to the LevelDB format upon loading. This may take a long time however we are still optimising the converter code.

Developers
The API has undergone some major changes in areas which will 100% break your plugins and due to this version still being in alpha, we do not recommend updating them yet as there may still be more changes to come.

New Features​

Custom Blocks, Items & Entities

These will require a resource pack to be loaded with the definitions and textures for the specified object. A custom class can be registered with the corresponding Registry to give your block custom features such as drops, hardness and light level. You will need to have load: STARTUP set in your plugin.yml so that the blocks, items and entities can be registered before any worlds are loaded. As of writing this post, custom entities have not been tested so they may not work. If you do come across any issues, please make a bug report on the GitHub issue tracker with your resource pack included.


Async Chunk I/O

Chunk loading was previously run on the main thread which caused unnecessary lag on the due to compression and decompression of the chunks being loaded from the disk. Now chunk loading has been moved into it's own thread pool with generation to give some extra performance to the main thread.


LevelDB

LevelDB support has been updated to enable loading of vanilla worlds into Nukkit and vice versa although 1.13+ worlds cannot currently be loaded into Nukkit due to new block state changes in the format. This will be implemented at a later date. With the move to LevelDB, we are now able to support blocks above ID 255 which was a limitation of the old Anvil format. Loading times should also be improved as the format saved to disk is native to Minecraft Bedrock therefore requiring minimal decoding before being sent to the player.

Other Major Changes​

Network

The network has been overhauled to use Netty wherever possible to reduce the overhead from converting between Java byte arrays and native Netty buffers. All packets sent using the indirect method will now be batched together in a single packet every tick to reduce network overhead (vanilla does this by default)


Entities

Every entity now have it's own interface to allow extra customisation so you do not have to extend the existing BaseEntity class and can write one from scratch. These entities can be registered in the EntityRegistry class which allows overriding of the default entity classes using a priority system. Overridden and plugins specific entities can still be created by using the function that provides a plugin object.
Entity metadata has also been completely rewritten so that protocol updates do not require your plugins to be recompiled if they use any metadata constants.

 

On server start i get this

Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.ensureError(J9VMInternals.java:148)
at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:137)
at net.daporkchop.lib.random.PRandom.shuffle(PRandom.java:256)
at net.daporkchop.lib.random.PRandom.shuffle(PRandom.java:244)
at net.daporkchop.lib.noise.engine.PerlinNoiseEngine.<init>(PerlinNoiseEngine.java:124)
at cn.nukkit.level.biome.Biome.<clinit>(Biome.java:23)
at cn.nukkit.registry.BiomeRegistry.<clinit>(BiomeRegistry.java:28)
at cn.nukkit.Server.<init>(Server.java:194)
at cn.nukkit.Nukkit.main(Nukkit.java:135)
Caused by: java.lang.RuntimeException: java.lang.NoSuchMethodException: java.lang.Throwable.getOurStackTrace()
at net.daporkchop.lib.common.util.PorkUtil.<clinit>(PorkUtil.java:101)
... 7 more
Caused by: java.lang.NoSuchMethodException: java.lang.Throwable.getOurStackTrace()
at java.lang.Class.newNoSuchMethodException(Class.java:562)
at java.lang.Class.throwExceptionOrReturnNull(Class.java:1195)
at java.lang.Class.getMethodHelper(Class.java:1259)
at java.lang.Class.getDeclaredMethod(Class.java:931)
at net.daporkchop.lib.common.util.PorkUtil.<clinit>(PorkUtil.java:91)
... 7 more

Nukkit 2.0 currently does not support OpenJ9 VMs. Please use GitHub to report issues.

 

Nukkit 2.0 is now in alpha with support for blocks above ID 255 (old chunk format limitation), LevelDB support, faster chunk loading and a variety of other features that listed are below. This build is NOT intended to be used in production environments as there are still major bugs that could potentially corrupt your world.
Existing anvil format worlds will be automatically converted to the LevelDB format upon loading. This may take a long time however we are still optimising the converter code.

Developers
The API has undergone some major changes in areas which will 100% break your plugins and due to this version still being in alpha, we do not recommend updating them yet as there may still be more changes to come.

New Features​

Custom Blocks, Items & Entities

These will require a resource pack to be loaded with the definitions and textures for the specified object. A custom class can be registered with the corresponding Registry to give your block custom features such as drops, hardness and light level. You will need to have load: STARTUP set in your plugin.yml so that the blocks, items and entities can be registered before any worlds are loaded. As of writing this post, custom entities have not been tested so they may not work. If you do come across any issues, please make a bug report on the GitHub issue tracker with your resource pack included.


Async Chunk I/O

Chunk loading was previously run on the main thread which caused unnecessary lag on the due to compression and decompression of the chunks being loaded from the disk. Now chunk loading has been moved into it's own thread pool with generation to give some extra performance to the main thread.


LevelDB

LevelDB support has been updated to enable loading of vanilla worlds into Nukkit and vice versa although 1.13+ worlds cannot currently be loaded into Nukkit due to new block state changes in the format. This will be implemented at a later date. With the move to LevelDB, we are now able to support blocks above ID 255 which was a limitation of the old Anvil format. Loading times should also be improved as the format saved to disk is native to Minecraft Bedrock therefore requiring minimal decoding before being sent to the player.

Other Major Changes​

Network

The network has been overhauled to use Netty wherever possible to reduce the overhead from converting between Java byte arrays and native Netty buffers. All packets sent using the indirect method will now be batched together in a single packet every tick to reduce network overhead (vanilla does this by default)


Entities

Every entity now have it's own interface to allow extra customisation so you do not have to extend the existing BaseEntity class and can write one from scratch. These entities can be registered in the EntityRegistry class which allows overriding of the default entity classes using a priority system. Overridden and plugins specific entities can still be created by using the function that provides a plugin object.
Entity metadata has also been completely rewritten so that protocol updates do not require your plugins to be recompiled if they use any metadata constants.

Make it for iPhone

 

It's not supposed to be compatible with old plugins. That's why we've changed the major version number.

That may be the case but please take the needs of the open source community (which is still being formed) into consideration. The effort that you put into this project is greatly appreciated but ignoring backward compatibility will make it much harder for plugin developers to keep up. If I understand correctly the suggested improvement could avoid a lot of "pain" but is quickly dismissed because a major release can contain breaking changes. But just because it can does not mean it should, especially when it can be avoided. And even more so because many plugins are created in user land. Soon you'll have a fork of a fork of a fork of a bunch of unmaintained plugins. The lack of documentation will cause more trial and error. More compatibility issues no doubt. Providing a stable and predictable server will be very helpful and will surely motivate devs to build more, and better plugins. Unavoidable breaking changes for the greater good sure, but why would you discard such a suggestion so easily? Sounds like a small change but a big win to me. For me, personally, I am motivated to contribute because my kids love minecraft and I love to be a part of that. Also I would be willing too share what I create but it must be fun, for me at least. To keep involved I'd need the reward of creating something fun without becoming too much of a burden to keep up. Not to forget you have quite a big dependency on microsoft updates. I can imagine the last thing you need is to maintain two versions of the server. Unless of course you simply plan on dropping support for 1.0. But of course that may proof to be a huge problem for a lot of people if everything is broken en half of the plugins are abandoned. I do not mean to complain. I am only saying this because I believe this project deserves an active opensource community. I would suggest to keep it fun to keep plugin devs engaged and motivated. A great number of well maintained and feature rich plugins that will "just work" when installed. How awesome would that be ;-)

 

That may be the case but please take the needs of the open source community (which is still being formed) into consideration. The effort that you put into this project is greatly appreciated but ignoring backward compatibility will make it much harder for plugin developers to keep up. If I understand correctly that is a way to avoid a lot of "pain" but it is dismissed because a major plugin can contain breaking changes. I guess I am saying that just because it can does not mean it should. Especially in this field as many plugins are created in user land. Soon you'll have a fork of a fork of a fork of a bunch of unmaintained plugins. The lack of documentation will cause more trial and error. More compatibility issues no doubt. Providing a stable and predictable server will be very helpful and will surely motivate devs to build more, and better plugins. Unavoidable breaking changes for the greater good sure, but why would you discard such a suggestion so easily? Sounds like a small change but a big win to me. For me, personally, I am motivated to contribute because my kids love minecraft and I love to be a part of that. Also I would be willing too share what I create but it must be fun, for me at least. To keep involved I'd need the reward of creating something fun without becoming too much of a burden to keep up. Plugins will break, but should not break more often than needed. And especially in this case since you have such a great dependency on microsoft updates. I can imagine the last thing you need is to maintain two versions of the server. Unless of course you simply plan on dropping support for 1.0. But of course that may proof to be a huge problem for a lot of people if everything is broken en half of the plugins are abandoned. I do not mean to complain. I am only saying this because I believe this project deserves an active opensource community. I would suggest to keep it fun to keep plugin devs engaged and motivated. A great number of well maintained and feature rich plugins that will "just work" when installed. How awesome would that be ;-)

Oh and just one more thing, compared to the competition you already have a great advantage in terms of software. I would argue that projects such as Pocketmine can only challenge this project on stability, ease of use and the availability of community plugins. Something to consider perhaps.

 

That may be the case but please take the needs of the open source community (which is still being formed) into consideration. The effort that you put into this project is greatly appreciated but ignoring backward compatibility will make it much harder for plugin developers to keep up. If I understand correctly the suggested improvement could avoid a lot of "pain" but is quickly dismissed because a major release can contain breaking changes. But just because it can does not mean it should, especially when it can be avoided. And even more so because many plugins are created in user land. Soon you'll have a fork of a fork of a fork of a bunch of unmaintained plugins. The lack of documentation will cause more trial and error. More compatibility issues no doubt. Providing a stable and predictable server will be very helpful and will surely motivate devs to build more, and better plugins. Unavoidable breaking changes for the greater good sure, but why would you discard such a suggestion so easily? Sounds like a small change but a big win to me. For me, personally, I am motivated to contribute because my kids love minecraft and I love to be a part of that. Also I would be willing too share what I create but it must be fun, for me at least. To keep involved I'd need the reward of creating something fun without becoming too much of a burden to keep up. Not to forget you have quite a big dependency on microsoft updates. I can imagine the last thing you need is to maintain two versions of the server. Unless of course you simply plan on dropping support for 1.0. But of course that may proof to be a huge problem for a lot of people if everything is broken en half of the plugins are abandoned. I do not mean to complain. I am only saying this because I believe this project deserves an active opensource community. I would suggest to keep it fun to keep plugin devs engaged and motivated. A great number of well maintained and feature rich plugins that will "just work" when installed. How awesome would that be ;-)

Well put UncleCode. I for one was trying to support this project but felt that I was not needed as there were (as it appeared to me) so many developers and it seemed that there was really no need for me as a developer. So, I gave up on trying to help with the project. Plus, issues I found in the code were apparently being worked on but didn't have any idea on what wasn't being worked on. Admitting, I probably could have looked more at open issues. But I found that my wanting to volunteer to help was not really wanted. This is fine because I will just spend my effort with some other project.

 

I get this error when I start my server



17:13:56 [FATAL] Nukkit crashed
java.lang.IllegalStateException: No worlds configured! Add a world to nukkit.yml and try again!
at cn.nukkit.Server.loadLevels(Server.java:1951) ~[Nukkit.jar:?]
at cn.nukkit.Server.boot(Server.java:554) ~[Nukkit.jar:?]
at cn.nukkit.Nukkit.main(Nukkit.java:144) [Nukkit.jar:?]

Hi,
you have to set the world name into the nukkit.yml.

 

The development of 2.0 is way too slow. And it still lacks killer features that makes me hungry to use it. One major feature would be an internal compatibility layer to Spigot/Bukkit plugins. Without support of already existing plugin-apis your project will decay.

 

The development of 2.0 is way too slow. And it still lacks killer features that makes me hungry to use it. One major feature would be an internal compatibility layer to Spigot/Bukkit plugins. Without support of already existing plugin-apis your project will decay.

Development in general is a very slow process, especially big rewrites like this. Sponge has been on 1.12.2 since 2018. That's 3 years of development to get their new API version out. Creating a compatibility layer would further slow down the development by taking on the technical debt of years of development gone into another project. With other leading server projects starting to make distance to spigot (papermc is planning on becoming a hard fork), it might be detrimental to even make an attempt to do so. When development takes years, the other projects don't stop in their tracks - they continue development. As such a compatibility layer might be already out-of-date fresh out the oven.

Competition for such a compatibility layer already exists to the other direction, as Geyser already allows bedrock players to join spigot servers