FastAsyncWorldEdit

FastAsyncWorldEdit

152k Downloads

Missing WE API call "void com.sk89q.worldedit.world.block.BlockType.<init>(java.lang.String)"

TomLewis opened this issue ยท 2 comments

commented

Server Implementation

Paper

Server Version

1.18.2

Describe the bug

When trying to use Movecraft-repair, it throws an error for a missing API call thats used in WE, heres my initial ticket:
APDevTeam/Movecraft-Repair#20

@TylerS1066 is the maintainer of the project.

To Reproduce

  1. Use 1.18.2 & FastAsyncWorldEdit version 2.6.2;3b7d126
  2. With movecraft and movecraft repair, create a repair sign.
  3. Save your craft
  4. Try to restore your craft using the repair sign and the error is thrown.

Expected behaviour

To be able to make this API call that is avalible in worldedit.

Screenshots / Videos

No response

Error log (if applicable)

No response

Fawe Debugpaste

https://gist.github.com/TomLewis/108103568d84a8f0dde8376f951b6921

Fawe Version

FastAsyncWorldEdit version 2.6.2;3b7d126

Checklist

Anything else?

config
https://gist.github.com/TomLewis/108103568d84a8f0dde8376f951b6921

worldedit config
https://gist.github.com/TomLewis/aaee2a349fa93fc2cf5ac3b85ae303e8

No need to have private latest.log and plugin list public, not related to this ticket.

commented

Tbh I'm not sure why the developer wants to instantiate a new BlockType rather using BlockTypes.get(String) to get the already existing instance (as types are not bound to the world) - but that's a whole other story I guess.

Other than that, I think we should try to adapt to upstream there. At least overload the methods or smth.

commented

why the developer wants to instantiate a new BlockType rather using BlockTypes.get(String)

This is what happens when we copy paste another developer's code from ~6 years ago without a thorough read-through. Looks like one of my fellow devs has already fixed the issue by implementing this change (APDevTeam/Movecraft-Repair#24), thanks for the heads up!