Upgraded Bukkit from 1.12.2 to 1.14.4

[iainbeeston]

The version of bukkit used by rasberry juice is quite old and when I try to start bukkit with it installed I get an error:

org.bukkit.plugin.InvalidPluginException: java.lang.NoSuchFieldError: GOLD_SWORD

I think that in version 1.13 of bukkit, GOLD_SWORD and WOOD_SWORD were renamed to GOLDEN_SWORD and WOODEN_SWORD, and although that doesn't stop rasberry juice from compiling, the compiled code is incompatible with up-to-date bukkit servers.

To fix that I have updated the pom file to compile against bukkit 1.14.4 (the latest on the spigot repository). As you would expect, that produced compile errors at the same place I'm seeing the issue in the bukkit logs:

[ERROR] RaspberryJuice/src/main/java/net/zhuoweizhang/raspberryjuice/RaspberryJuicePlugin.java:[21,11] error: cannot find symbol
[ERROR]
[ERROR] could not parse error message:   symbol:   variable GOLD_SWORD
[ERROR]   location: class Material
[ERROR] RaspberryJuice/src/main/java/net/zhuoweizhang/raspberryjuice/RaspberryJuicePlugin.java:24: error: cannot find symbol
[ERROR] 			Material.WOOD_SWORD);
[ERROR] 			        ^

Updating those to the current variable names fixes the compile error, and the compiled plugin now works with bukkit.

[martinohanlon]

Thank you. I'm going to be away for a couple of weeks but I will look into this when I'm back

[iainbeeston]

After a bit more testing it seems that a lot more changes are needed to use raspberry juice with the latest bukkit releases.

Right now raspberry juice sets block types using an integer id and additional information about a block (eg colour or orientation) using a byte of data that varies in meaning depending on the block type. After version 1.13 bukkit removed this functionality and instead expects the name of the block type any additional information must be set using explicit setter methods. There is a deprecated api to do things the old way but it isn't guaranteed to work the same way in all bukkit server implementations.

I'm trying to refactor rasberry juice to use the new bukkit API but it would mean changing the raspberry juice API and make it backwards incompatible (both with existing code that uses raspberry juice and with bukkit servers older than 1.13). Will this ever be merged if it breaks backwards compatibility? 🤔

[martinohanlon]

Thanks @iainbeeston .

I am just having a look at creating a version for 1_14_4 right now.

My view re the the new mechanism of managing block types is to try and have our cake and eat it...

e.g.

Using:

mc.setBlock(0, 0, 0, blockid, blockdata)

.. would still work and mapping would happen within RaspberryJuice for blockid specified in the old API.

But then changing the python library so you could also do:

mc.setBlock(0, 0, 0, "block:type")

Not even sure if this is possible, but its good to have a dream!

[iainbeeston]

I've all but given up on doing this I'm afraid. I can push up the code I have if it's of interest but the approach I was taking felt too risky, and it'd introduce a lot of bugs I'm sure

[martinohanlon]

Thanks Iain. Sure push away if you have it. It would be good to see the approach you have taken.

[Marcinosoft]

Having both method's would be great, to have backward code samples compatibility.

[iainbeeston]

@martinohanlon I've pushed up the latest, although the last commit is very much a work in progress and although regular blocks seemed to work, signs did not. Also I was in a rush and made some pretty sweeping changes to the code! Hopefully there's something in there that will be helpful

[iainbeeston]

The first commit might be more useful as some items have a different name in 1.14 (as explained in the pull request description)

[MinecraftDawn]

I sended a new pull request, it support version 1.14 of Minecraft, you can use it to upgrade this project

[martinohanlon]

closed in favour of #84