Bug (Crashes Mine with BlockEvent)

Which module are you submitting this issue for?

Mines

Describe the issue you are experiencing.

When creating a BlockEvent, and using the mine once, after a restart the mine crashes due to the plugin producing a comma instead of a point decimal.

Describe the steps to reproduce the problem.

1. Create a BlockEvent
2. Use the mine once
3. Restart the server
4. [09:01:58] [Server thread/WARN]: java.lang.NumberFormatException: For input string: "2,00000"
5. The mine won't work (obviously) while the rest do

Anything else we need to know?

Ill post the logs needed here:

[09:01:58] [Server thread/WARN]: java.lang.NumberFormatException: For input string: "2,00000"
[09:01:58] [Server thread/WARN]: 	at java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
[09:01:58] [Server thread/WARN]: 	at java.base/jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
[09:01:58] [Server thread/WARN]: 	at java.base/java.lang.Double.parseDouble(Double.java:556)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.features.MineBlockEvent.fromStringV1(MineBlockEvent.java:200)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.features.MineBlockEvent.fromSaveString(MineBlockEvent.java:155)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.data.Mine.loadFromDocument(Mine.java:514)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.data.Mine.<init>(Mine.java:158)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.managers.MineManager.loadMines(MineManager.java:345)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.managers.MineManager.loadFromDbCollection(MineManager.java:243)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.mines.PrisonMines.deferredStartup(PrisonMines.java:137)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.spigot.SpigotPrison.initDeferredModules(SpigotPrison.java:688)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.spigot.SpigotPrison.enableModulesAndCommands(SpigotPrison.java:573)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.spigot.SpigotPrison.onEnableStartup(SpigotPrison.java:251)
[09:01:58] [Server thread/WARN]: 	at tech.mcprison.prison.spigot.SpigotPrison.onEnable(SpigotPrison.java:208)
[09:01:58] [Server thread/WARN]: 	at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:263)
[09:01:58] [Server thread/WARN]: 	at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:370)
[09:01:58] [Server thread/WARN]: 	at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:500)
[09:01:58] [Server thread/WARN]: 	at org.bukkit.craftbukkit.v1_17_R1.CraftServer.enablePlugin(CraftServer.java:527)
[09:01:58] [Server thread/WARN]: 	at org.bukkit.craftbukkit.v1_17_R1.CraftServer.enablePlugins(CraftServer.java:441)
[09:01:58] [Server thread/WARN]: 	at net.minecraft.server.MinecraftServer.loadWorld(MinecraftServer.java:639)
[09:01:58] [Server thread/WARN]: 	at net.minecraft.server.dedicated.DedicatedServer.init(DedicatedServer.java:306)
[09:01:58] [Server thread/WARN]: 	at net.minecraft.server.MinecraftServer.x(MinecraftServer.java:1126)
[09:01:58] [Server thread/WARN]: 	at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:316)
[09:01:58] [Server thread/WARN]: 	at java.base/java.lang.Thread.run(Thread.java:831)

Please visit our discord server for help. https://discord.gg/DCJ3j6r

Thanks for trying to report this issue. I'm so sorry you have had problems. It will help us make prison better.

Your first issue is that you are not using the correct notation. 2,00000 is an invalid number. We cannot fix that.

This is not a bug, but its more of an issue of a misunderstanding what correct data should look like.

I will fix the code so it won't produce a stack trace, but this is not a bug because it is not valid input. Actually I just applied a fix to the Prison source code. It will not allow you enter data like that, but at least now it will not fail with a stack trace any more. It will generate an error message indicating the percent chance is invalid and will inform you what the mine's name is, and what the incorrect value is. It will continue to load the mine and it's blockEvents, but it will use a value of 0.00001 for the invalid value. I'm having the chance set to the lowest possible value in case the event was intended to be a very rare event so it won't crash your server's economy with a high-chance value.

You must use the standard notation as used in the Western hemisphere, or the US standards, or whatever you want to call it.

If you are trying to enter 2 percent, then you must enter it as 2, or 2.0. You can enter 2.00000 but it's not required. Using just 2 is fine. The range of valid numbers are 0 through 100. There are no real reasonable limit on smallness of the percent chance, other than when saving the data it is formatting the number using a decimal format of "0.00000". That is equivalent to seven decimal place percent such that the closest you can get to 100% without being 100% would be as follows (for demonstration purposes): 0.9999999. So the smallest non-zero percentage value would be: 0.0000001.

So besides using the wrong numeric notation, your other issue is that you tried to manually edit the save file for the mines. We have always discouraged directly modify the save files because failures such as these will happen; incorrect data is entered, incorrect formatting of the data, invalid json and yaml, etc. We cannot support anyone who manually edits the files, since we have be a great deal of effort in providing a robust user interface that helps to ensure you are using the correct data so your server will work better.

So the fact that you edited the file manually, when we do not support doing that, you get what you got.... problems. Don't get me wrong, you can manually edit anything you want, but we cannot support that beyond pointing out what the issue may be. We've put our time and effort in ensuring the user interface is able to ensure your data is correct. We cannot put in tons of effort in troubleshooting issues that are created when you bypass the intended mode of entry.

When I try to enter that value of "2,00000" online, look what happens; it prevents the use of invalid data.

So this illustrates that if you would have used the user interface, then Prison would have informed you that you were using the wrong format for the number and it would have never made it to the mine's save file.

Please visit our discord server so we can help you better understand what you are doing wrong. We'll be happy to help.

I hope this information helps. It took a while for me to provide this response with hopes of not only helping you to better understand what the issues were, and how to fix them, but also to fix Prison's code. I've already fixed prison so this stack trace will not happen again, and hopefully the error message will be more informative as to what the issue was. This fix will be included in the next alpha release of Prison. You can download all alpha releases from our discord server.

I look forward to helping you on our discord server if you have any other issues. Thanks for this report!

• Blue

I just reread your initial submission. I'm thinking I may have been wrong in assuming that you manually edited the save files since you did not mention that you made manual edits. Generally situations like these are the results of a manual edit of the files.

Normally the file format cannot be changed. Prison should have saved it as "2.00000" so I'm unsure why it saved it as "2,00000".

The source code is locked in to using "my" language choice for compiling and running. The formatting that I am using on that data does "not" take in to consideration locale settings.

DecimalFormat dFmt = new DecimalFormat("0.00000");
dFmt.format( getChance() )

As you see, the period is locked in to that formatting. It should never apply a different output.

So if you did not manually edit the save files, then I'm wondering if you recompiled the project and you're using a custom build that has a non US locale setting?

Visit our discord server so we can explore this in greater detail if you did not manually edit the save file.

Thanks again for your submission!

Hey! I know where the confusion lies.
I used "2" in the command, and it works until I restart the server. I checked why it gave that error, and it looks like it saves the 2.0 as 2,0 (with a comma instead of a period). I did not change the file. I tried switching my pc's locale setting, which did not resolve the issue...

Now this is interesting, I moved the server to a dedicated server, where it doesnt replicate the issue...

Thanks to ScorchChamp working with me on Prison's discord server we've figured this out.

If this problem happens, it's happening because the java environment is using a different locale. To force it to use US English add the following startup settings:

java -Duser.country=US -Duser.language=EN -Xmx8G -Xms1G -jar server.jar nogui

Prison is using the following code:

DecimalFormat dFmt = new DecimalFormat("0.00000");
dFmt.format( getChance() )

To fix the code in prison so it's always using US EN for the file outputs... the following would work:

NumberFormat nFmt = DecimalFormat.getInstance( Locale.US );
if ( nFmt instanceof DecimalFormat ) {
DecimalFormat df = (DecimalFormat) nFmt;
df.applyLocalizedPattern( "0.00000" );
}
nFmt.format( getChance() );

In most situations within Prison's source code, it's safe to allow the locale to make adjustments in the formatting, but in this situation the format is being used to save the data, but the same format is not being used to parse it back to a double.

Therefore hard coding with US would fix the issue to ensure its always using a ".". Or the other solution is to use the same DecimalFormat to parse the String value back to a double.

A note will be made to make adjustments to correct this properly in the future. Other I/O functions will need to be validated to ensure they are corrected too.