Directional Bug.
Pheotis opened this issue ยท 7 comments
Background
A portal with a closing-block specified as water is an underwater portal. A portal with either the A flag or the R flag is a type of always-on.
Description
Underwater portals, upon first creation will fail at construction and print a stack trace.
An air block attempts to get placed in front of the portal -- not a coral.
Any portal that is facing south will not experience the above.
This is because, by default, MC's dead_tube_coral_wall_fan faces south.
If one attempts to create a portal on the exact same spot a failed portal has already been made, it will work.
This persists across server restarts.
This issue impacts ALL variants and types of portals EXCEPT anything considered Always-On.
This includes the A flag and the R flag.
In no situation will this problem impact and above-ground portal.
This problem will begin to occur the first server restart after a fresh install of SG.
Trace
java.lang.ClassCastException: class org.bukkit.craftbukkit.v1_16_R3.block.data.CraftBlockData cannot be cast to class org.bukkit.block.data.Directional (org.bukkit.craftbukkit.v1_16_R3.block.data.CraftBlockData and org.bukkit.block.data.Directional are in unnamed module of loader 'app')
at net.TheDgtl.Stargate.Portal.createPortal(Portal.java:1212) ~[?:?]
at net.TheDgtl.Stargate.Stargate$bListener.onSignChange(Stargate.java:999) ~[?:?]
at com.destroystokyo.paper.event.executor.MethodHandleEventExecutor.execute(MethodHandleEventExecutor.java:37) ~[patched_1.16.4.jar:git-Paper-337]
at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:80) ~[patched_1.16.4.jar:git-Paper-337]
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[patched_1.16.4.jar:git-Paper-337]
at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:607) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.PlayerConnection.a(PlayerConnection.java:2803) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.PlayerConnection.lambda$a$16(PlayerConnection.java:2756) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.PlayerConnection.lambda$a$1(PlayerConnection.java:324) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.PlayerConnection.lambda$a$3(PlayerConnection.java:338) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.TickTask.run(SourceFile:18) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.executeTask(IAsyncTaskHandler.java:136) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.executeNext(IAsyncTaskHandler.java:109) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.MinecraftServer.bb(MinecraftServer.java:1133) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.MinecraftServer.executeNext(MinecraftServer.java:1126) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.awaitTasks(IAsyncTaskHandler.java:119) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.MinecraftServer.sleepForTick(MinecraftServer.java:1087) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.MinecraftServer.w(MinecraftServer.java:1001) ~[patched_1.16.4.jar:git-Paper-337]
at net.minecraft.server.v1_16_R3.MinecraftServer.lambda$a$0(MinecraftServer.java:178) ~[patched_1.16.4.jar:git-Paper-337]
at java.lang.Thread.run(Thread.java:834) [?:?]
Repro steps
Unknown
After extensive testing, this issue has been narrowed; the original post has been edited to show that.
This issue has been experienced again, and the original thread has been updated to reflect some new findings.
I have done some testing myself, but i am unable to get any error at all; underwater portals works for me whatever direction i choose.
We might not have the exact same spigot version (I have Spigot 1.16.4-RO.1-SNAPSHOT). Could this possibly be another spigot bug?
How odd... I guess it could be an issue with the testing environment.
For reference, all my tests so far have been run running git-Paper-401 (MC 1.16.4) via Waterfall-Bootstrap-1.16-R0.4 on Debian 10
After further investigation, we have determined that this is a bug that only applies in the above environment.
Furthermore, through a binary trace, we have determined that this bug is a conflict with RestrictedCreative.
As a work around, dead tube coral wall fan can be excluded from restricted creative checks.
As it is a decorative block, allowing an infinite supply of it probably won't jeopardize your economy.
tracking:
blocks:
enabled: true
exclude:
- DEAD_TUBE_CORAL_WALL_FAN
A possible scenario which would cause this error:
Stargate sets the corallWallFan into the world in its uncalibrated orientation
Because a block has been set, a blockEventListener in Restricted Creative will trigger (this might possibly be on a different thread)
This listener replaces the block into an airblock by some reason; I dont have RC code, but it might be because the block is in an unstable state. (thats why south-facing corals work)
This is where the final nail in the coffin gets laid:
Directional buttonData = (Directional) button.getBlock().getBlockData();
That command does not work on airblocks^, and therefore the error
I would say if there was a way to instantly set the blockmaterial and its direction at the same time (in one comand). This can be done by using strings, but its messy.