There is a feature which allows you to exclude specific players and entities from rollbacks and lookups by placing a "!" in front of their username (ex. p:!Ranr). In some cases it would be useful to be able to do the same for specific blocks. The same can be achieved by rolling back and then restore that particular block type, but this would allow it to be done in one rollback.

Describe the bug
When an Armor Stand is

To Reproduce
Steps to reproduce the behavior:
Kill an Armor Stand using /minecraft:kill command.

Expected behavior
No NPE happens

Console log
[13:04:53] [Server thread/ERROR]: Could not pass event EntityDeathEvent to Prism v2.1.6-127
java.lang.NullPointerException: null
at me.botsko.prism.listeners.PrismEntityEvents.onEntityDeath(PrismEntityEvents.java:163) ~[?:?]
at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor849.execute(Unknown Source) ~[?:?]
at org.bukkit.plugin.EventExecutor.lambda$create$1(EventExecutor.java:69) ~[patched_1.15.2.jar:git-Paper-301]
at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:80) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:607) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.craftbukkit.v1_15_R1.event.CraftEventFactory.callEntityDeathEvent(CraftEventFactory.java:767) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.EntityArmorStand.killEntity(EntityArmorStand.java:704) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.CommandKill.a(SourceFile:32) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.CommandKill.a(SourceFile:25) ~[patched_1.15.2.jar:git-Paper-301]
at com.mojang.brigadier.CommandDispatcher.execute(CommandDispatcher.java:262) ~[patched_1.15.2.jar:git-Paper-301]
at com.mojang.brigadier.CommandDispatcher.execute(CommandDispatcher.java:176) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.CommandDispatcher.a(CommandDispatcher.java:179) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.craftbukkit.v1_15_R1.command.VanillaCommandWrapper.execute(VanillaCommandWrapper.java:45) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:159) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.craftbukkit.v1_15_R1.CraftServer.dispatchCommand(CraftServer.java:761) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.craftbukkit.v1_15_R1.entity.CraftPlayer.performCommand(CraftPlayer.java:461) ~[patched_1.15.2.jar:git-Paper-301]
at com.denizenscript.denizen.scripts.commands.server.ExecuteCommand.execute(ExecuteCommand.java:185) ~[?:?]
at com.denizenscript.denizencore.scripts.commands.CommandExecutor.execute(CommandExecutor.java:80) ~[?:?]
at com.denizenscript.denizencore.scripts.queues.ScriptEngine.revolve(ScriptEngine.java:56) ~[?:?]
at com.denizenscript.denizencore.scripts.queues.core.InstantQueue.revolve(InstantQueue.java:64) ~[?:?]
at com.denizenscript.denizencore.scripts.queues.core.InstantQueue.onStart(InstantQueue.java:54) ~[?:?]
at com.denizenscript.denizencore.scripts.queues.ScriptQueue.runMeNow(ScriptQueue.java:290) ~[?:?]
at com.denizenscript.denizencore.scripts.queues.ScriptQueue.start(ScriptQueue.java:337) ~[?:?]
at com.denizenscript.denizencore.scripts.queues.ScriptQueue.start(ScriptQueue.java:298) ~[?:?]
at com.denizenscript.denizen.scripts.containers.core.CommandScriptContainer.runCommandScript(CommandScriptContainer.java:172) ~[?:?]
at com.denizenscript.denizen.utilities.command.scripted.DenizenCommand.execute(DenizenCommand.java:161) ~[?:?]
at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:159) ~[patched_1.15.2.jar:git-Paper-301]
at org.bukkit.craftbukkit.v1_15_R1.CraftServer.dispatchCommand(CraftServer.java:761) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.PlayerConnection.handleCommand(PlayerConnection.java:1860) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.PlayerConnection.a(PlayerConnection.java:1668) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.PacketPlayInChat.a(PacketPlayInChat.java:47) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.PacketPlayInChat.a(PacketPlayInChat.java:5) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.PlayerConnectionUtils.lambda$ensureMainThread$0(PlayerConnectionUtils.java:23) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.TickTask.run(SourceFile:18) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.IAsyncTaskHandler.executeTask(IAsyncTaskHandler.java:136) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.IAsyncTaskHandler.executeNext(IAsyncTaskHandler.java:109) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.MinecraftServer.ba(MinecraftServer.java:1097) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.MinecraftServer.executeNext(MinecraftServer.java:1090) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.IAsyncTaskHandler.awaitTasks(IAsyncTaskHandler.java:119) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.MinecraftServer.sleepForTick(MinecraftServer.java:1051) ~[patched_1.15.2.jar:git-Paper-301]
at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:966) ~[patched_1.15.2.jar:git-Paper-301]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

Server (please complete the following information):

• Prism Version: 2.1.6
• Server Type: Paper 301
• Server Version: 1.15.2

Issue:
Using essentialsx's /invsee or openinv's /openinv to edit another player's inventory results in one of two different NPEs being thrown.

Errors:
https://pastebin.com/nk20jkaQ
https://pastebin.com/9uS4GxRu

Plugins:
Plugins (2): Essentials, Prism

Server:

[00:35:53 INFO]: This server is running Paper version git-Paper-135 (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)
[00:35:53 INFO]: Checking version, please wait...
[00:35:54 INFO]: Previous version: git-Purpur-489 (MC: 1.15.2)
[00:35:54 INFO]: You are running the latest version

Tested on java-13 and java-14.

Config is completely unchanged except for necessary MySQL settings.

From an admin standpoint, Prism works well if the admin has all permissions, except for the permission prism.parameters.action.required. In this case, having the permission prevents the admin from doing something. So I'd like to discuss what, if anything, should be done about this. Some possibilities:

1. Get rid of the permission entirely, making actions optional for everyone.

2. Change the permission to prism.parameters.action.notrequired, so if an admin has all permissions, things will work in an intuitive manner.

3. Come up with a way to support both permissions, with one (notrequired?) overriding the other.

Note that this permission does not really fit in with the rest of the permissions (there's no other action.* permission), and is not shown in the Prism documentation from 2016.

Here's a reference to the source lines where the permission is checked:
https://github.com/AddstarMC/Prism-Bukkit/blob/master/src/main/java/me/botsko/prism/commandlibs/PreprocessArgs.java#L109-L114

Raised as part of issue #160

This will add https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/event/player/PlayerItemBreakEvent.html

Tracking items lost this way is important so owners can understand where an item dissappeared to as opposed to being lost. That being said it should not be restorable or rollback. It makes no sense to allow that.

Is your feature request related to a problem? Please describe.
When I try to compile the plugin with Java 8 it gives me package javax.xml.bind does not exist. After a quick search I realized that javax.xml.bind is dropped from Java 11.

A lot of plugins nowaday support Java 11. Also JRE 11 usually yield better performance with new GCs. We want to move our server into Java 11 and maybe save some ram overhead as well.

Describe the solution you'd like
Migrate codes that are still using Java-8-only features.

Describe alternatives you've considered
I added a new dependency section in the pom.xml according to this post. It complies, but not sure how it performed in a jre-11 server. I will post my test run here if I get time to test it.

name: Bug report
about: 'Create a report to help us improve Prism '
title: "[BUG] "
labels: ''
assignees: ''

Describe the bug
Banners are not logged and when broken will revert to base type

To Reproduce
Place patterned banner...
break...
rollback...

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem** via https://imgur.com/ or similar.

Server (please complete the following information):

• Prism Version: X.X.X
• Server Type: [Spigot|Paper|CraftBukkit]
• Server Version: X.X.X

Additional context
Add any other context about the problem here.

Describe the bug
Increasing the radius provides fewer results.

To Reproduce
Issued the following command:
/pr l r:5 t:15d p:dishwashes

At the same location, changed the radius to 50:
/pr l r:50 t:15d p:dishwashes

Expected behavior
A larger radius should encompass all the results in the smaller radius.

Server (please complete the following information):

• v2.1.7-SNAPSHOT-160
• Spigot
• git-Spigot-2f5d615-cfeef75 (MC: 1.15.2)

Describe the bug
Torches placed on walls are not logged unless they're placed on top of the block. Torches & redstone torches placed on the sides of blocks are not logged when the block they are attached to is broken.

Bells do not appear to have any causal logs. If the block they are attached to is broken, they are not logged.

To Reproduce
Steps to reproduce the behavior:
Place a torch on the side of a block then break the block it is attached to which will cause the torch to fall. Enable inspector wand and click where the torch used to be and you will find no logs.

Place Bell on a block and break the block it is attached to and inspect with wand. No logs are found.
Server (please complete the following information):

• Prism Version: 2.1.6-127
• Server Type: Spigot
• Server Version: 1.15.2

Background
Currently, we have specific items that spawn from other plugins (we use numerous plugins, some custom made by our devs, some not, most of them run console commands to trigger events). When the items spawn from either blocks or command, they're not always logged in prism, it depends on how they're spawned. If a player spawns them in via command then yes we can find that in prism logs. However, if an item naturally spawns (such as when a player causes the server to spawn a special custom item for them at their location) then it's not logged. Another example is when we are in the console and broadcast something from the console ("broadcast This is a test!") it will not appear in logs. Same thing if we have another plugin run that broadcast message as a console command. However, if I as a player in game run "/broadcast This is a test!" then yes it logs just fine

Ideal solution
A new command that both can be used by the server and by a player with an admin permission, that is like "/prism log <entity> <action> [additional record filling details]"

• This of course would look for different "record filling details" for each type of log and then denote the log entry
  Optionally: You could also NOT let us choose <entity> and <action> but rather just make a new action type called "inserted record" or "logged" or something similar and the command and output would be: "/prism log <details>
• GenSecrets logged 'This was a test'
• console logged 'Player found an Epic Artifact'
• console logged 'Broadcasted: This is a test!'
  This second alternative here might be easier/better and also simply would have a key/value, similar to current logs with the entity that ran it (typically being console or the player in game), and then whatever they typed in <details>

Describe alternatives you've considered
Alternatively something similar could be added in the API? I have little experience with the API and our dev's are taxed as is so making something from our side while seemingly easy could also be a few months down the pipeline due to other projects. But overall, ideally it would be a main plugin feature via a command. If the addition of this command isn't feasible then more console support could accomplish similar things(ie logging when the console runs a particular command etc, maybe a list of whitelisted commands in a config somewhere). This suggested command would just allow us to input it wherever we need. For instance, if we have a plugin we could have it run the command for us when we want it to log something for us. OR say a staff member was at an area and wants to leave a note in the logs for other staff members in case they have to do any rollbacks/restores at that area, then they could drop "/prism log <details>"

Additional context

• Ideally, it would attempt to fill in time and location as well so that the logs could be teleported to if applicable, if not then it would fill in a default value (whatever your common practice is for similar scenarios when no location/time should be attached to something)

Describe the bug
The custom name is not recorded/shown for action place.

To Reproduce
Place a chest with a custom name, then access the chest. Do an extended lookup command and a:place will not show the custom name.

Also note that the text formatting is not reset after the custom name (a:access).

Expected behavior
The custom name should be shown.

Screenshots

Server (please complete the following information):

• Prism Version: v2.1.7-SNAPSHOT-161
• git-Spigot-2f5d615-1b2830a (MC: 1.15.2)

Additional context

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Track bed explosions and damage in the Nether

Describe the bug
Errors on shutdown in appears the queue may not have emptied before Hikari terminates

To Reproduce
Steps to reproduce the behavior:
Shutdown server

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

[18:02:44 INFO]: [Prism] Disabling Prism v2.1.7-SNAPSHOT-10
[18:02:44 INFO]: [com.botsko.prism.libs.hikari.HikariDataSource] prism - Shutdown initiated...
[18:02:44 INFO]: [com.botsko.prism.libs.hikari.HikariDataSource] prism - Shutdown completed.
[18:02:44 INFO]: [Prism] Closing plugin.
[18:02:44 WARN]: [com.botsko.prism.libs.hikari.pool.ProxyConnection] prism - Connection com.mysql.jdbc.JDBC4Connection@2687b34b marked as broken because of SQLSTATE(08S01), ErrorCode(0)
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 174 milliseconds ago.The last packet sent successfully to the server was 174 milliseconds ago.
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_242]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_242]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_242]
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_242]
at com.mysql.jdbc.Util.handleNewInstance(Util.java:403) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3517) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3417) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2524) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2675) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2465) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3860) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.PreparedStatement.executeUpdateInternal(PreparedStatement.java:2136) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.PreparedStatement.executeUpdateInternal(PreparedStatement.java:2070) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.PreparedStatement.executeLargeUpdate(PreparedStatement.java:5187) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2055) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1915) ~[patched_1.16.2.jar:git-Paper-174]
at com.botsko.prism.libs.hikari.pool.ProxyPreparedStatement.executeUpdate(ProxyPreparedStatement.java:61) ~[?:?]
at me.botsko.prism.actionlibs.RecordingTask.insertActionsIntoDatabase(RecordingTask.java:118) ~[?:?]
at me.botsko.prism.database.sql.SqlInsertBuilder.insertActionIntoDatabase(SqlInsertBuilder.java:72) ~[?:?]
at me.botsko.prism.actionlibs.RecordingTask.save(RecordingTask.java:46) ~[?:?]
at me.botsko.prism.actionlibs.RecordingTask.run(RecordingTask.java:156) ~[?:?]
at org.bukkit.craftbukkit.v1_16_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54) ~[patched_1.16.2.jar:git-Paper-174]
at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[patched_1.16.2.jar:git-Paper-174]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_242]
at org.bukkit.craftbukkit.v1_16_R2.scheduler.CraftTask.run(CraftTask.java:99) ~[patched_1.16.2.jar:git-Paper-174]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_242]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_242]
at java.net.SocketInputStream.socketRead0(Native Method) ~[?:1.8.0_242]
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.read(SocketInputStream.java:171) ~[?:1.8.0_242]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) ~[?:1.8.0_242]
at java.net.SocketInputStream.read(SocketInputStream.java:141) ~[?:1.8.0_242]
at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144) ~[patched_1.16.2.jar:git-Paper-174]
at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174) ~[patched_1.16.2.jar:git-Paper-174]
at com.botsko.prism.libs.hikari.pool.HikariProxyPreparedStatement.executeUpdate(HikariProxyPreparedStatement.java) ~[?:?]
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3427) ~[patched_1.16.2.jar:git-Paper-174]
[18:02:44 WARN]:
... 22 more
[18:02:44 WARN]: The last packet successfully received from the server was 174 milliseconds ago.The last packet sent successfully to the server was 174 milliseconds ago.
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2966) ~[patched_1.16.2.jar:git-Paper-174]
[18:02:44 WARN]: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[18:02:44 WARN]: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
[18:02:44 WARN]: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
[18:02:44 WARN]: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[18:02:44 WARN]: at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
[18:02:44 WARN]: at com.mysql.jdbc.Util.handleNewInstance(Util.java:403)
[18:02:44 WARN]: at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3517)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3417)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3860)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2524)
[18:02:44 WARN]: at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2465)
[18:02:44 WARN]: at com.mysql.jdbc.PreparedStatement.executeUpdateInternal(PreparedStatement.java:2136)
[18:02:44 WARN]: at com.mysql.jdbc.PreparedStatement.executeUpdateInternal(PreparedStatement.java:2070)
[18:02:44 WARN]: at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2055)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2675)
[18:02:44 WARN]: at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1915)
[18:02:44 WARN]: at me.botsko.prism.database.sql.SqlInsertBuilder.insertActionIntoDatabase(SqlInsertBuilder.java:72)
[18:02:44 WARN]: at com.botsko.prism.libs.hikari.pool.HikariProxyPreparedStatement.executeUpdate(HikariProxyPreparedStatement.java)
[18:02:44 WARN]: at com.mysql.jdbc.PreparedStatement.executeLargeUpdate(PreparedStatement.java:5187)
[18:02:44 WARN]: at com.botsko.prism.libs.hikari.pool.ProxyPreparedStatement.executeUpdate(ProxyPreparedStatement.java:61)
[18:02:44 WARN]: at me.botsko.prism.actionlibs.RecordingTask.insertActionsIntoDatabase(RecordingTask.java:118)
[18:02:44 WARN]: at me.botsko.prism.actionlibs.RecordingTask.save(RecordingTask.java:46)
[18:02:44 WARN]: at me.botsko.prism.actionlibs.RecordingTask.run(RecordingTask.java:156)
[18:02:44 WARN]: at org.bukkit.craftbukkit.v1_16_R2.scheduler.CraftTask.run(CraftTask.java:99)
[18:02:44 WARN]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[18:02:44 WARN]: at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22)
[18:02:44 WARN]: at java.lang.Thread.run(Thread.java:748)
[18:02:44 WARN]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[18:02:44 WARN]: Caused by: java.net.SocketException: Socket closed
[18:02:44 WARN]: at java.net.SocketInputStream.socketRead0(Native Method)
[18:02:44 WARN]: at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
[18:02:44 WARN]: at java.net.SocketInputStream.read(SocketInputStream.java:171)
[18:02:44 WARN]: at java.net.SocketInputStream.read(SocketInputStream.java:141)
[18:02:44 WARN]: at org.bukkit.craftbukkit.v1_16_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54)
[18:02:44 WARN]: at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2966)
[18:02:44 WARN]: at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3427)
[18:02:44 WARN]: ... 22 more
[18:02:44 WARN]: at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
[18:02:44 WARN]: at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
[18:02:44 INFO]: [Prism] Could not retrieve a connection
[18:02:44 WARN]: [Prism] Plugin Prism v2.1.7-SNAPSHOT-10 generated an exception while executing task 1388152
java.lang.NullPointerException: null
at me.botsko.prism.database.sql.SqlInsertBuilder.insertActionIntoDatabase(SqlInsertBuilder.java:69) ~[?:?]
at org.bukkit.craftbukkit.v1_16_R2.scheduler.CraftTask.run(CraftTask.java:99) ~[patched_1.16.2.jar:git-Paper-174]
at me.botsko.prism.actionlibs.RecordingTask.insertActionsIntoDatabase(RecordingTask.java:118) ~[?:?]
at me.botsko.prism.actionlibs.RecordingTask.save(RecordingTask.java:46) ~[?:?]
at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[patched_1.16.2.jar:git-Paper-174]
at org.bukkit.craftbukkit.v1_16_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54) ~[patched_1.16.2.jar:git-Paper-174]
at me.botsko.prism.actionlibs.RecordingTask.run(RecordingTask.java:156) ~[?:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_242]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_242]
[18:02:44 INFO]: [Multiverse-Portals] Disabling Multiverse-Portals v4.1.0-b805
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_242]```

**Server (please complete the following information):**
  - Prism Version: 2.1.7.10
  - Server Type: Paper
  - Server Version: 176

**Additional context**
Add any other context about the problem here.

Block sub id is redundant - its no longer used as we use BlockState

However because block state quering is very very slow as it is doing a string match we may need to consider converting the state to an more easily queriable storage system

We can detect the underlying Sql server. setting non standard sql if required ... a player set param via config will override

Attached are the Usage and Reference documentation from the old site converted to GitHub Markdown format. Some changes were made, but this is a more-or-less direct transcript of the old site.

I didn't do the database, troubleshooting, or known issues sections, because they may have changed significantly.

PrismDocs.zip

https://pastebin.com/raw/fA0Fyyht

I had this similar issue with another plugin I think it has to do with not relocating hikaricp

The defaults in config.yml and hikari.properties have different values. They should be changed to match, or if the default values in config.yml no longer apply, they should be removed from the code.

In particular, max-pool-connections (20) / maximumPoolSize (10) and min-idle-connections (5) / minimumIdle (10) don't match. There may be others.

Prism 2.1.6-SNAPSHOT-118
MySQL 5.7.29
git-Spigot-6de3d4b-fc24934 (MC: 1.15.2)

The following were generated for the default files.

config.yml:

  mysql:
    hostname: 127.0.0.1
    username: root
    password: ''
    databaseName: minecraft
    prefix: prism_
    port: '3306'
    useNonStandardSql: true
    database:
      max-pool-connections: 20
      min-idle-connections: 5
      max-wait: 30000
      max-failures-before-wait: 5
      actions-per-insert-batch: 300
      force-write-queue-on-shutdown: true

hikari.properties:

#Prism Hikari Datasource Properties for advanced database Configuration
#Thu Mar 12 11:11:51 EDT 2020
allowPoolSuspension=false
poolName=prism
registerMbeans=false
maxLifetime=1800000
autoCommit=true
leakDetectionThreshold=0
maximumPoolSize=10
idleTimeout=600000
validationTimeout=5000
minimumIdle=10
isolateInternalQueries=false
initializationFailTimeout=1
readOnly=false
connectionTimeout=30000

Describe the bug
/pr undo appears to not work. We do a rollback, then /pr undo and it says "no previous action."

To Reproduce
Steps to reproduce the behavior:
Perform a rollback and then use /pr undo

Expected behavior
The rollback should be "undone"

Screenshots
N/A

Server (please complete the following information):

• Prism Version: 2.1.6
• Server Type: Paper
• Server Version: 1.15.2 b312

Additional context
N/A

Describe the bug
When doing /pr wand, I get "You need to specify a wand type". That should default to inspect mode. It also advises looking at /prism ? which doesn't include any further help.

When doing /pr wand i (or /pr wand inspect) it says "Only some parameters used". Parameters should be optional for the inspect wand, but I didn't provide any, so I don't know what it's rejecting.

To Reproduce
Steps to reproduce the behavior:
/pr wand and /pr wand inspect

Expected behavior
See description. Wands are definitely confusing to use due to these messages, showing unintentionally.

Screenshots

Server (please complete the following information):

• Prism Version: 2.1.6
• Server Type: Paper
• Server Version: 1.15.2 b332

Additional context
N/A

Describe the bug
Console errors thrown on EntityDeathEvent involving EliteMob.

To Reproduce
Steps to reproduce the behavior:
1 - Install EliteMobs Dev-build here (SpigotMC is heavily out of date)
2 - Enable Entity death logging in Prism
3 - Spawn any EliteMob
4 - Kill it
5 - Profit?

Expected behavior
No errorino

Screenshots
I'll do you one better than screenshots, here's the exception:
Error link: https://gist.github.com/B-Knight49/ce205f6bc00d7ef67a438defa65549e0

Server (please complete the following information):

• Prism Version: v2.1.5-106
• Server Type: Paper-103
• Server Version: 1.15.2

Additional context
N/A. Lemme know if you need anything else.

Describe the bug
A clear and concise description of what the bug is.
Items shift clicked into a chest are logged as expected
Items placed in a chest ARE not logged using standard item drag
Items removed using a drag and drop remove are logged
however items removed using shift click are not!!

To Reproduce
Steps to reproduce the behavior:
Place Chest
SHIFT click item into chest
verify insert is logged
Drag an item from your inv to the chest -
Verify no insert is logged

Expected behavior
A clear and concise description of what you expected to happen.
Expect it is logged.

Server (please complete the following information):

• Prism Version: 2.1.7-SNAPSHOT
• Server Type: Spigot
• Mysql 5.7

Additional context
Add any other context about the problem here.

Describe the bug
Placing, accessing, or breaking a block with a custom name, such as as a chest or dispenser, does not log the name. If the chest/dispenser is broken and rolled back, the custom name is not set.

To Reproduce
Acquire a chest and give it a custom name by using an anvil. Place, open, then break the chest. Use /pr l r:10 t:10m and observe that the output does not include the name. (See the screenshot below, demonstrating this with a dispenser.) Use /pr rollback r:10 t:10m a:break and observe that the rolled-back chest does not have the name.

Expected behavior
The custom name should be logged for place/access/break and should be restored upon a successful rollback.

Screenshots

Server (please complete the following information):

• Prism Version: 2.1.7 build 144
• Server Type: Spigot
• Server Version: git-Spigot-2040c4c-933e909 (MC: 1.15.2)

Additional context
Testing was done in Creative mode.

Describe the bug
When rolling back a writable book, the item itself comes back but not the contents written inside. Paintings do not rollback when attempted, and are not logged when destroyed via tnt.

To Reproduce
Destroy/remove a writable book (unsigned) then roll it back.

Place painting and have it destroyed. Attempt to roll it back, it will claim it has succeeded but the painting will not return.

Expected behavior
Expected book to return with its contents.

Expected painting to return.

Screenshots
N/A

Server (please complete the following information):

• Prism Version: 2.1.6
• Server Type: Spigot
• Server Version: 1.15.2

Additional context
Add any other context about the problem here.

Describe the bug
When breaking a beacon, logs are inserted into the database for that beacon as well as any beacon it is touching, causing an inflated break count.

To Reproduce
Steps to reproduce the behavior:

• Place down several beacons touching one another. State of the beacon (active/inactive), surface, or face of the beacon it's placed against do not seem to matter, only that several beacons are touching.
• Break one of the beacons
• Run a lookup on beacon breaks, and compare number broken to number logged as broken

Expected behavior
When one beacon is broken one log is inserted into the database under any circumstance.

Screenshots
Screenshots are included at https://imgur.com/a/Gzgo0bc

Server (please complete the following information):

• Prism Version: 2.1.8-Snapshot-200
• Server Type: Spigot
• Server Version: 1.16.2, Build 122

Describe the bug
When you execute a drain it executes properly..however - the data stored cannot later be looked up because its missing `parent_id'
To Reproduce
Steps to reproduce the behavior:

1. Execute a drain
2. execute a lookup.

Expected behavior
lookup shows the drain event,
Screenshots

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem** via https://imgur.com/ or similar.

Server (please complete the following information):

• Prism Version: 2.1.7-SNAPSHOT
• Server Type: Spigot
• Server Version: 1.15.2

Additional context
[17:15:17] [Craft Scheduler Thread - 0/WARN]: [Prism] Plugin Prism v2.1.7-SNAPSHOT- generated an exception while executing task 1237
java.lang.NumberFormatException: null
at java.lang.Long.parseLong(Long.java:552) ~[?:1.8.0_181]
at java.lang.Long.parseLong(Long.java:631) ~[?:1.8.0_181]
at me.botsko.prism.actions.PrismRollbackAction.deserialize(PrismRollbackAction.java:35) ~[?:?]
at me.botsko.prism.database.sql.SqlSelectQueryBuilder.executeSelect(SqlSelectQueryBuilder.java:629) ~[?:?]
at me.botsko.prism.actionlibs.ActionsQuery.lookup(ActionsQuery.java:65) ~[?:?]
at me.botsko.prism.commands.LookupCommand.lambda$handle$0(LookupCommand.java:63) ~[?:?]
at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftTask.run(CraftTask.java:81) ~[spigot-1.15.2.jar:git-Spigot-2040c4c-1872231]
at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54) [spigot-1.15.2.jar:git-Spigot-2040c4c-1872231]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_181]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_181]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]

• Prism 2.1.6
• Paper 103
• Minecraft 1.15.2
• R5 3600 + 8GB RAM

As it currently stands, the PlayerJoinEvent in Prism is the 2nd biggest contributor to tick usage (when testing joining performance). The 1st is chunkAwait.

I think that the majority (if not all) of the PlayerJoinEvent listener could probably be run asynchronously since, from what I can tell, it doesn't directly interact with the Bukkit API and is simply for caching.

Would alleviate a bit (or a lot) of the impact placed upon servers during joining. Mostly beneficial for those that have a lot of people leaving/joining in short periods of time.

When im trying to inspect block, it writes "Prism // No history for this grass block found."
Block has been removed and placed before checking.

Console error: https://pastebin.com/9DH3BePn

Prism 2.1.6 (Default config)
Paper-260 (1.15.2)

Describe the bug
Suppose /pr l r:100 t:10m a:kill returns bats and iron golems being killed.
Adding e:bat or e:iron_golum returns no results (either you're missing something or we are).

To Reproduce
Try the above or similar lookups for entities being killed.

Expected behavior
With the above lookups, adding an entity should return results that are a subset of the original lookup.

Screenshots

Server (please complete the following information):

• Prism Version: v2.1.7-SNAPSHOT-163
• Server Type: Spigot
• Server Version: git-Spigot-a99063f-be6aaf0 (MC: 1.15.2)

Additional context

Is your feature request related to a problem? Please describe.
WIth the coming of 1.16 chat formatting options have been placed at the forefront of a lot of plugin changes. Prism has never had any sort of localization or customization.

Describe the solution you'd like

1. Create localization files. - to abstract the actual content
2. Create a customization that allows custom colours and formatting to various reports.

Describe alternatives you've considered
The localization will be handled by UTF8 formatted resource bundles.
The formatting I want to consider adding dependency on the
KyoriPowered/Adventure platform https://adventure.docs.kyori.net/
This will add around 700k size to the plugin jar -

https://adventure.docs.kyori.net/minimessage.html#

When Prism uses bStats 1.7 and any other plugin is the bStats "sending" plugin, the statistics for Prism are not sent. The following testing was done with Spigot 1.15.2.

If I run with just Prism build 74 (which uses bStats 1.7) and no other plugins, the stats get sent.

If I add WorldEdit (just WE and Prism), the Prism stats are not sent. WorldEdit is the "sending" plugin and it also uses bStats 1.7.

If I add a third plugin which uses bStats 1.7 (WE is still the "sending" plugin), the stats for WE and the third plugin are sent, but the stats for Prism are not sent.

This is the Metrics code involved in submitData:

Object plugin = provider.getService().getMethod("getPluginData").invoke(provider.getProvider());
if (plugin instanceof JsonObject) {
    pluginData.add((JsonObject) plugin);
} else { // old bstats version compatibility
    try {
        Class<?> jsonObjectJsonSimple = Class.forName("org.json.simple.JSONObject");
        if (plugin.getClass().isAssignableFrom(jsonObjectJsonSimple)) {
            Method jsonStringGetter = jsonObjectJsonSimple.getDeclaredMethod("toJSONString");
            jsonStringGetter.setAccessible(true);
            String jsonString = (String) jsonStringGetter.invoke(plugin);
            JsonObject object = new JsonParser().parse(jsonString).getAsJsonObject();
            pluginData.add(object);
        }
    } catch (ClassNotFoundException e) {
        // minecraft version 1.14+
        if (logFailedRequests) {
            this.plugin.getLogger().log(Level.SEVERE, "Encountered unexpected exception", e);
        }
    }
}

When the "sending" plugin is processing the Prism data, it fails the test for (plugin instanceof JsonObject) and goes into the "old bstats version compatibility" part (I don't think it should be there), and then fails the test if (plugin.getClass().isAssignableFrom(jsonObjectJsonSimple))

So the problem appears to involve what Prism is returning for provider.getService().getMethod("getPluginData").invoke(provider.getProvider())

Also note that both bStats and Spigot made changes related to JSON. bStats Replaced json-simple with Gson and Spigot removed json-simple from the api in their 1.14 update.

Currently when any items are rolled back (armor/items/tools/etc) they're all rolled back at full durability. While this is a great convenience feature I suggest there be a toggle for sake of larger servers like mine.

Why

We receive numerous tickets a week regarding needing items rolled back because they were lost or disappeared. Because of the intentions of some RPG or sentient items, we do not refund them if they naturally broke due to low durability. Because of this, in non-obvious situations we used to rollback the item, check it's durability, then run quick math based on blocks broken/mobs hit/etc to determine how close durability was or if it broke naturally or really disappeared. After transition to 1.15.2 this is no longer possible

Another instance is because of some custom plugins we have where we have item trades heavily dependent on exact durability (i.e. a "relic" that can be exchanged for gold, but the "relic" is old and fragile, this having 1 durability so that it can't be used, only traded if found.

Implementation

Ideally this would be a config line-item "repair-items-on-rollback:true/false" or similar. If false it would not repair items and would rollback items exactly as they were at the state they're being rolled back from. If true it would default to always repairing the items. This would require the database to save the state of the item exactly if it doesn't already.

There would also be two in game flags "-no-repair" and "-repair" to be run in rollback commands which would override the config and either repair or not repair per request. This would be dependent on the person having a permission "prism.repair" to be able to use the flags, similar to drain, extinguish, override, etc.

Server: git-Spigot-8faa8b4-13ed05d (MC: 1.15.2)
Prism: v2.1.5-106

An error occurred in the following operation.

/pr wand rollback
Specify the location of the destroyed powered_rail (off).

[17:22:46] [Server thread/INFO]: [Prism]: Applier error: Material must be a block!
[17:22:46] [Server thread/WARN]: java.lang.IllegalArgumentException: Material must be a block!
[17:22:46] [Server thread/WARN]: at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
[17:22:46] [Server thread/WARN]: at org.bukkit.craftbukkit.v1_15_R1.block.CraftBlockState.setType(CraftBlockState.java:133)
[17:22:46] [Server thread/WARN]: at me.botsko.prism.actions.BlockAction.placeBlock(BlockAction.java:382)
[17:22:46] [Server thread/WARN]: at me.botsko.prism.actions.BlockAction.applyRollback(BlockAction.java:270)
[17:22:46] [Server thread/WARN]: at me.botsko.prism.appliers.Preview.lambda$processWorldChanges$0(Preview.java:299)
[17:22:46] [Server thread/WARN]: at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftTask.run(CraftTask.java:81)
[17:22:46] [Server thread/WARN]: at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:394)
[17:22:46] [Server thread/WARN]: at net.minecraft.server.v1_15_R1.MinecraftServer.b(MinecraftServer.java:1036)
[17:22:46] [Server thread/WARN]: at net.minecraft.server.v1_15_R1.DedicatedServer.b(DedicatedServer.java:406)
[17:22:46] [Server thread/WARN]: at net.minecraft.server.v1_15_R1.MinecraftServer.a(MinecraftServer.java:984)
[17:22:46] [Server thread/WARN]: at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:824)
[17:22:46] [Server thread/WARN]: at java.lang.Thread.run(Thread.java:748)

Shutdown called before async tasks have completed writing the queue

Prism 2.1.6 still has references to pste.me in the default configuration file:

  paste:
    enable: false
    username: Username on http://pste.me/#/signup
    api-key: API key from http://pste.me/#/account

Is your feature request related to a problem? Please describe.
Previously there was a feature where if staff rolled back any events, then those logs would be displayed with &n in front of them, striking through the log to indicate that they've been fixed. Then anything not rolled back or restored will not have the strikethrough format. As it is right now, it's extra work for staff (especially on a server with hundreds of players and 2 dozen+ daily tickets) to spend an extra 10 minutes determining not only what happened at a scene, but also if there are logs from other staff members and then exactly what happened/resulted from that staff member, and what's left untouched. This produces double work, and sometimes the possibility of duplicated roll backs of items/events.

Solution

• When a player rolls back a log, it would be exactly as it is now, except all logs that are considered "rolled back" will have a strike through them.
• When a player restores a rolled back log, it will do exactly the opposite and simply return it to the beginning state without a strike through it.

Implementation
Possibly could be done via a "rolled back" state? for logs, and "if rolled back" then preface the output with "&n" minecraft format code

Instead of doing:

SELECT min(id) FROM prism_data  WHERE ...
SELECT max(id) FROM prism_data  WHERE ...

minId and maxId can be determined by a single query:

SELECT MIN(id) AS minid, MAX(id) AS maxid, COUNT(*) AS rows FROM prism_data WHERE ...

This should be faster than two separate queries, although that should be confirmed with timing measurements before this is implemented.

Tridents have no action logged by prism. You can throw a trident (projectile) then pick it up off the ground and nothing gets logged. This is especially inconvenient when investigating lost tridents.

Currently, CMI (a large popular multi-function Spigot plugin) has a chat channel functionality where players can /chat and start a persistent chat channel to talk without using commands. Once someone enters a chat channel, Prism does not log anything typed by the user inside that chat channel

Solution
Since the user types out messages as chat messages and not through commands, the messages once found through the event listener, would be logged as chat actions in lookups. Simply /pr l r:global a:chat p:playername would grab all chat actions by the playername, both inside and outside the chat channels

Alternatives and additional context
There are no work arounds other than not allowing the chat channels, since prism lacks the support for this logging. However for some additional information, I'm not sure how useful it is, but CMI does have an open API for use.

Describe the bug
Trying to perform a lookup, console shows the below error/stacktrace.

To Reproduce
Steps to reproduce the behavior:
I installed it on a new paper 1.15.2 server, connected it to a MariaDB server.

Logging works fine, I see data, queried my actions via SQL. But any lookup/near command via Prism fails.

Expected behavior
Shouldn't fail

Screenshots
N/A

Server (please complete the following information):

• Prism Version: 2.1.6
• Server Type: Paper b264
• Server Version: 1.15.2

Additional context

[17:31:58] [Craft Scheduler Thread - 2658/ERROR]: [Prism] Database connection error: FUNCTION minecraft.any_value does not exist
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: FUNCTION minecraft.any_value does not exist
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at jdk.internal.reflect.GeneratedConstructorAccessor69.newInstance(Unknown Source)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.Util.getInstance(Util.java:408)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:944)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3933)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3869)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2524)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2675)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2465)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1912)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2020)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.botsko.prism.libs.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.botsko.prism.libs.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at me.botsko.prism.database.sql.SQLSelectQueryBuilder.executeSelect(SQLSelectQueryBuilder.java:526)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at me.botsko.prism.actionlibs.ActionsQuery.lookup(ActionsQuery.java:81)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at me.botsko.prism.commands.NearCommand.lambda$handle$0(NearCommand.java:76)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftTask.run(CraftTask.java:84)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[17:31:58] [Craft Scheduler Thread - 2658/WARN]: 	at java.base/java.lang.Thread.run(Thread.java:834)

Describe the bug
Redstone broken by water flow is not recorded. Repeaters, torches, etc logged fine.

To Reproduce
Steps to reproduce the behavior:
Place redstone, dump water. Do /pr l a:break

Expected behavior
Redstone breaking should be logged.

Screenshots

Server (please complete the following information):

• Prism Version: 2.1.6
• Server Type: Paper
• Server Version: 1.15.2 b341

Additional context
N/A

Describe the bug
After a PR #194 some prism lookups began to run very slowly.
For example this command /pr l r:100 t:1d -no-group executed ~30s before PR and ~600s after on our prism database with 18kk+ rows.

This is because database engine using wrong key (player) when select.

For /pr l r:100 t:1d -no-group:

EXPLAIN SELECT id, epoch, action_id, player, world_id, x, y, z, block_id, block_subid, old_block_id, old_block_subid, data, HEX(player_uuid) AS uuid FROM prism_data INNER JOIN prism_players p ON p.player_id = prism_data.player_id LEFT JOIN prism_data_extra ex ON ex.data_id = prism_data.id WHERE world_id = ( SELECT w.world_id FROM prism_worlds w WHERE w.world = 'world') AND (prism_data.x BETWEEN 1100 AND 1300) AND (prism_data.y BETWEEN 102 AND 302) AND (prism_data.z BETWEEN 2000 AND 2200) AND prism_data.epoch >= 1591875073 ORDER BY prism_data.epoch DESC, x ASC, z ASC, y ASC, id DESC LIMIT 1000

After adding IGNORE INDEX (player) to select query, the lookup is fast again.

EXPLAIN SELECT id, epoch, action_id, player, world_id, x, y, z, block_id, block_subid, old_block_id, old_block_subid, data, HEX(player_uuid) AS uuid FROM prism_data IGNORE INDEX (player) INNER JOIN prism_players p ON p.player_id = prism_data.player_id LEFT JOIN prism_data_extra ex ON ex.data_id = prism_data.id WHERE world_id = ( SELECT w.world_id FROM prism_worlds w WHERE w.world = 'world') AND (prism_data.x BETWEEN 1100 AND 1300) AND (prism_data.y BETWEEN 102 AND 302) AND (prism_data.z BETWEEN 2000 AND 2200) AND prism_data.epoch >= 1591875073 ORDER BY prism_data.epoch DESC, x ASC, z ASC, y ASC, id DESC LIMIT 1000

So can anyone compare the query speed at their large database before pr and after?

Server (please complete the following information):

• Prism Version: v2.1.7-SNAPSHOT-164
• Server Type: Paper
• Server Version: git-Paper-347
• Database: MariaDB 10.2.29

I am not sure this api is even functional anymore and if anyone uses it -

Additionally it presents issues if and when some moves to java 11. It requires additional dependencies in that environment -

I would appreciate community feedback

May need to relocate the slf4j api to avoid class loading errors..

6:02] [Server thread/INFO]: [Prism] Enabling Prism v2.1.6-SNAPSHOT-118
[11:26:02] [Server thread/INFO]: [Prism]: Initializing Prism 2.1.6-SNAPSHOT-118. By Viveleroi.
[11:26:02] [Server thread/WARN]: [Prism] ====================================================
[11:26:02] [Server thread/WARN]: [Prism]  Prism works better if you use Paper 
[11:26:02] [Server thread/WARN]: [Prism]  as your server software. 
[11:26:02] [Server thread/WARN]: [Prism] ====================================================
[11:26:02] [Server thread/INFO]: [Prism]: Configuring Hikari from hikari.properties
[11:26:02] [Server thread/INFO]: [Prism]: This file will not save the jdbcURL, username or password - these are loaded by default from the standard prism configuration file.  If you set these explicitly in the properties file the settings in the standard config will beignored.
[11:26:02] [Server thread/WARN]: [DiscordSRV] Loaded class org.slf4j.spi.LoggerFactoryBinder from Prism v2.1.6-SNAPSHOT-118 which is not a depend, softdepend or loadbefore of this plugin.
[11:26:02] [Server thread/WARN]: [Prism] Loaded class org.slf4j.impl.StaticLoggerBinder from DiscordSRV v1.18.4 which is not a depend, softdepend or loadbefore of this plugin.
[11:26:02] [Server thread/INFO]: Elixr: Loaded items directory
[11:26:02] [Server thread/INFO]: [Prism]: Prism bStats metrics are enabled - thank you!

Is your feature request related to a problem? Please describe.
Actions/blocks are not tab-completed, so you must type them out fully. Some Prism messages are white, which make them blend in with the chat. An option to change the color would be helpful.

Describe the solution you'd like
It would be immensely helpful to have full tab-completion for parameters

Describe alternatives you've considered
N/A

Additional context
Add any other context or screenshots about the feature request here.

I am using MariaDB 10.3.22 on Debian 10.
I have tried a different user and I was getting an Access denied error. I am not sure if this issue is invalid.

Describe the bug
Frosted ice formed by a player does not log the player name, but instead that the entity player created it.

To Reproduce
Steps to reproduce the behavior:

1. Wear boots with Frost Walker on them
2. Walk on water.
3. Preform a lookup on the ice.

Expected behavior
The username of the player who forms the ice, should be logged to the database.

Screenshots

Server (please complete the following information):

• Prism Version: 2.1.6-127
• Server Type: Paper
• Server Version: 1.16.2

Additional context
I believe this is caused by this line. It gets the entity type name and passes that to ActionFactory.createBlockChange(). For players, it should cast the entity to an OfflinePlayer and pass that to ActionFactory.createBlockChange(). I'm working on implementing this, any guidance on alternative fixes is also appreciated.

With metrics now supporting customized views - we need to discuss what metrics Prism should report on.

Latest builds are not work.
Paper version: git-Paper-239 (MC: 1.15.2)

[WARN]: [Prism] Task #3 for Prism v2.1.7-SNAPSHOT-136 generated an exception
org.bukkit.plugin.IllegalPluginAccessException: Unable to find handler list for event me.botsko.prism.events.PrismCustomPlayerActionEvent. Static getHandlerList method required!
	at org.bukkit.plugin.SimplePluginManager.getRegistrationClass(SimplePluginManager.java:703) ~[patched_1.15.2.jar:git-Paper-239]
	at org.bukkit.plugin.SimplePluginManager.registerEvents(SimplePluginManager.java:640) ~[patched_1.15.2.jar:git-Paper-239]
	at me.botsko.prism.Prism.enabled(Prism.java:431) ~[?:?]
	at me.botsko.prism.Prism.lambda$null$2(Prism.java:373) ~[?:?]
	at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftTask.run(CraftTask.java:84) ~[patched_1.15.2.jar:git-Paper-239]
	at org.bukkit.craftbukkit.v1_15_R1.scheduler.CraftScheduler.mainThreadHeartbeat(CraftScheduler.java:461) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.b(MinecraftServer.java:1240) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.DedicatedServer.b(DedicatedServer.java:430) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.a(MinecraftServer.java:1157) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:946) ~[patched_1.15.2.jar:git-Paper-239]
	at java.lang.Thread.run(Thread.java:834) [?:?]

[ERROR]: Could not pass event BlockBreakEvent to Prism v2.1.7-SNAPSHOT-136
java.lang.NullPointerException: null
	at me.botsko.prism.listeners.PrismBlockEvents.onBlockBreak(PrismBlockEvents.java:187) ~[?:?]
	at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor11.execute(Unknown Source) ~[?:?]
	at org.bukkit.plugin.EventExecutor.lambda$create$1(EventExecutor.java:69) ~[patched_1.15.2.jar:git-Paper-239]
	at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:80) ~[patched_1.15.2.jar:git-Paper-239]
	at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[patched_1.15.2.jar:git-Paper-239]
	at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:607) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PlayerInteractManager.breakBlock(PlayerInteractManager.java:315) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PlayerInteractManager.a(PlayerInteractManager.java:274) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PlayerInteractManager.a(PlayerInteractManager.java:157) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PlayerConnection.a(PlayerConnection.java:1351) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PacketPlayInBlockDig.a(SourceFile:40) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PacketPlayInBlockDig.a(SourceFile:10) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.PlayerConnectionUtils.lambda$ensureMainThread$0(PlayerConnectionUtils.java:23) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.TickTask.run(SourceFile:18) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.IAsyncTaskHandler.executeTask(IAsyncTaskHandler.java:136) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.IAsyncTaskHandler.executeNext(IAsyncTaskHandler.java:109) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.ba(MinecraftServer.java:1081) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.executeNext(MinecraftServer.java:1074) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.IAsyncTaskHandler.awaitTasks(IAsyncTaskHandler.java:119) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.sleepForTick(MinecraftServer.java:1035) ~[patched_1.15.2.jar:git-Paper-239]
	at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:950) ~[patched_1.15.2.jar:git-Paper-239]
	at java.lang.Thread.run(Thread.java:834) [?:?]