[Bug]: Gem Success Rate Issue
Closed this issue · 2 comments
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
"min-success" option is broken and its causing huge inconvenience.
It is described as minimum progress bar (success rate) for it to be
considered as successful aka adding secret fake success rate for example
it always being successful if its over 90%. However as it is right not it is not
doing that. What it does now is if its above 90% it will always be successful,
if its lower it will never be successful even if its 89%. It can not even be
turned off making gem success rate non existent. Setting it to -1 does not
disable it, fully turning off animated bar gives the error and eats the items.
Expected Behavior
For the option to not impact the success rate if its under the config number.
Option for the config to be turned off either via setting it to -1 or 100 and
setting that as the default number instead of 50 in the config.
For animated bar to be able to be turned off
I have also noticed that the bar is not exact, my gems are all 75% success rate
but the bar shows a random number around 75% when it fills. It would be nice
to get somewhere where we can configure that. It is not silent rate bonus (aka pity)
since I have those all to 0 and it was changing when it was successful as well.
Steps To Reproduce
The config option was on 50 by default, I tried to socket gems (75%) on
the item to check what fail message is. I did 30 attempts and it was always
successful. When it was changed to 99, it was never successful.
Environment
-latest.log
[22:21:15 ERROR]: Could not pass event InventoryClickEvent to ProRPGItems v1.0.3.16
java.lang.NullPointerException: Cannot invoke "su.nightexpress.quantumrpg.manager.interactions.api.AnimatedSuccessBar$Builder.clone()" because "this.animation" is null
at su.nightexpress.quantumrpg.modules.api.socketing.ModuleSocket.getAnimation(ModuleSocket.java:167) ~[prorpgitems-1.0.3.16-1910433.jar:?]
at su.nightexpress.quantumrpg.modules.api.socketing.ISocketGUI.startSocketing(ISocketGUI.java:75) ~[prorpgitems-1.0.3.16-1910433.jar:?]
at su.nightexpress.quantumrpg.modules.api.socketing.ISocketGUI.lambda$new$0(ISocketGUI.java:52) ~[prorpgitems-1.0.3.16-1910433.jar:?]
at mc.promcteam.engine.manager.api.gui.GuiItem.click(GuiItem.java:235) ~[promccore-1.0.3.9-1910433.jar:?]
at mc.promcteam.engine.manager.api.gui.NGUI.click(NGUI.java:438) ~[promccore-1.0.3.9-1910433.jar:?]
at mc.promcteam.engine.manager.api.gui.NGUI.onEventClick(NGUI.java:475) ~[promccore-1.0.3.9-1910433.jar:?]
at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor570.execute(Unknown Source) ~[?:?]
at org.bukkit.plugin.EventExecutor.lambda$create$1(EventExecutor.java:69) ~[patched_1.17.1.jar:git-Purpur-1428]
at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:80) ~[patched_1.17.1.jar:git-Purpur-1428]
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[patched_1.17.1.jar:git-Purpur-1428]
at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:628) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.server.network.ServerGamePacketListenerImpl.handleContainerClick(ServerGamePacketListenerImpl.java:2891) ~[app:?]
at net.minecraft.network.protocol.game.ServerboundContainerClickPacket.handle(ServerboundContainerClickPacket.java:55) ~[app:?]
at net.minecraft.network.protocol.game.ServerboundContainerClickPacket.handle(ServerboundContainerClickPacket.java:11) ~[app:?]
at net.minecraft.network.protocol.PacketUtils.lambda$ensureRunningOnSameThread$1(PacketUtils.java:56) ~[app:?]
at net.minecraft.server.TickTask.run(TickTask.java:18) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.util.thread.BlockableEventLoop.doRunTask(BlockableEventLoop.java:149) ~[app:?]
at net.minecraft.util.thread.ReentrantBlockableEventLoop.doRunTask(ReentrantBlockableEventLoop.java:23) ~[app:?]
at net.minecraft.server.MinecraftServer.doRunTask(MinecraftServer.java:1450) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.server.MinecraftServer.executeTask(MinecraftServer.java:192) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.util.thread.BlockableEventLoop.pollTask(BlockableEventLoop.java:122) ~[app:?]
at net.minecraft.server.MinecraftServer.pollTaskInternal(MinecraftServer.java:1428) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.server.MinecraftServer.pollTask(MinecraftServer.java:1421) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.util.thread.BlockableEventLoop.managedBlock(BlockableEventLoop.java:132) ~[app:?]
at net.minecraft.server.MinecraftServer.waitUntilNextTick(MinecraftServer.java:1399) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1310) ~[patched_1.17.1.jar:git-Purpur-1428]
at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:322) ~[patched_1.17.1.jar:git-Purpur-1428]
at java.lang.Thread.run(Thread.java:831) ~[?:?]
Anything else?
No response
To understand the variance in the animation bar a little better, we have to understand the two scenarios here.
If the animation bar is disabled, the plugin generates a random number, checks if it lines up with the min-success rate, and grants the socket or not based on how that lines up. So effectively, a gem with a 70% enchant success has a 70% chance of succeeding, with "values" ranging anywhere from 0 to 100, and being compared appropriately. So any value 70 and below meets our 70% requirement and the socket will succeed.
With the animation bar enabled, it's a little different story. The percentage is calculated at each "step" along the way for the bar to fill up. So technically speaking, each step is a 70% chance of success. Probability-wise, this will balance out to roughly 70% at a final result, but won't necessarily be 70% on the dot with some variance either up or down. In this case, we'd have a 70% chance for a higher number and roughly 30% for a lower one. This makes it so it's still possible to fail a min-success of 70% with a gem with a 70% success rate. Using this same concept, it's also possible to succeed with a poor enchantment rate if the odds line up in your favor just right.
Hopefully that all makes sense, but the error should at least be resolved in the latest dev builds.
@lordsrubka5 if you want to make sure that this is indeed fixed. I believe that the issue should be resolved, at least from all of my testing, it behaved the way I'd expect.