Huge changes in Minecraft v1.13

[Captain Starbuck]

Ref https://www.spigotmc.org/threads/bukkit-craftbukkit-spigot-bungeecord-1-13-development-builds.328883/

A LOT of changes have been made between 1.12 and 1.13. From my perspective it will be difficult for ScriptCraftJS to keep up given the current state of code and resources for maintenance. So I've been thinking about ways to help this plugin evolve with fewer changes from one Minecraft release to another.

I haven't been active with this community at all recently but I have been watching v1.13 evolve. I'm now experimenting with code that will allow ScriptCraftJS to dynamically incorporate functionality from Spigot, rather than having details hard-coded into this plugin. This will eliminate many or all common issues where ScriptCraftJS doesn't provide access to some feature in a new version of Minecraft.

I haven't discussed this with Walter or anyone else. This effort will result in completely different underpinnings in ScriptCraftJS, and perhaps incompatibility with prior versions. For this reason I am not going to attempt to merge any of this into ScriptCraftJS. My intent is to do all of this independently, write these dynamic functions in a completely separate repo, and attempt a merge the live ScriptCraftJS into that mess, rather than the other way around. If this all works then I will offer the update in its entirety as a new ScriptCraftJS baseline. I cannot presume that this will be accepted, I can only offer.

So as an independent developer, this is what I plan to be doing, and I hope that it will benefit this community at some point. I will post info about this here later as it starts to take shape.

[Mike Stay]

I've been concerned for a long time about the need to continually change scriptcraft to keep it up to date with minecraft.  I completely support forking if that's necessary to keep the project alive.

[Jonathan Perret]

For anyone here who's not following the Github repo, I just opened a pull request https://github.com/walterhiggins/ScriptCraft/pull/388 that uses an undocumented CraftBukkit class to give the old block IDs a new lease on life.

This means you can run ScriptCraft today on a Spigot 1.13 server, and look into what else needs to be done to update to changes in the Minecraft core.

I agree there are things that can be done in ScriptCraft to pick up new Minecraft features "automatically". The most obvious example being block types: instead of a hardcoded list as we have now in https://github.com/walterhiggins/ScriptCraft/blob/development/src/main/js/modules/blocks.js it would be relatively easy to enumerate the values of the `org.bukkit.Material` enum.

However this approach has its limits. For example, as part of the "flattening" (https://minecraft.gamepedia.com/1.13/Flattening), in 1.13 red stained glass is an entirely different block type from green stained glass. And yet, being able to enumerate the stained glass colors through the `blocks.stained_glass` JavaScript object is very convenient and makes for example the `rainbow` function easy to write. This is an example of the value added by defining a friendlier API in ScriptCraft over the raw Bukkit API, particular in the beginner context where ScriptCraft is most commonly used.

In the extreme, it is relatively trivial to build a ScriptCraft-like mod that has practically no dependency on the Bukkit API: just remove most of the JS code such as the Drone, events, inventory modules and keep only the bare minimum of glue that allows running JavaScript code against the Java API. This would indeed require very little maintenance between Minecraft releases, but having to code to the Bukkit API directly would make the end user's JavaScript coding much less fun and prone itself to breakage between releases… something about having cake and eating it, I guess :-)

[Captain Starbuck]

Two thoughts.

I think ScriptCraftJS has two separate audiences, with an intersection point. There are people new to programming where JS is an excellent vehicle for learning. Then there are people who are truly intent on creating new functionality for Minecraft with JS.For the first group, concepts like backward compatibility and specific features aren't relevant. They have never seen these things before so something new can easily replace something old, and new programmers will never know the difference. We just want the learning experience to be as rich. Where this becomes a problem is that it separates the plugin from Walters fine book and other materials that are founded on the original functionality.

For block IDs, new Materials and such, the angle I've been looking at (with some few minutes per month, sigh) is to use reflection to generate code which is then built into ScriptCraftJS. No more adding IDs. Just execute a pre-build to get the names from the source, that generates code, then build the plugin to make all of the functionality available. I've spoken with other developers who do things like this with Minecraft, discussing options for collaboration on these reflection tools for everyone to use in various projects. But I haven't been able to keep up with those discussions.

So for now I'm just passing along thoughts on how this might move forward, even though as an individual I'm lacking time to act on it right now.

Regards.

[Josh Wulf]

This excellent workaround is now broken in 1.15.2, as CraftEvil is gone. 

I've written a patch that falls back to _something_. I haven't tested this because I don't use Drone. 

https://github.com/walterhiggins/ScriptCraft/pull/434

Does anyone have a drone snippet that I can use to debug it?

Josh