Dynmap: Dynmap 1.15 & 1.15.1

Created on 11 Dec 2019  ·  86Comments  ·  Source: webbukkit/dynmap

It's that time again and Mojang has given a new Minecraft version. And many sleepless nights to solve problems.
I have now loaded the latest Spigot 1.15 version and Dynmap would have to be adjusted.

java.lang.IllegalArgumentException: Error initializing dynmap - bukkit version incompatible!
at org.dynmap.bukkit.helper.BukkitVersionHelperGeneric.(BukkitVersionHelperGeneric.java:159) ~[?:?]
at org.dynmap.bukkit.helper.BukkitVersionHelperCB.(BukkitVersionHelperCB.java:45) ~[?:?]
at org.dynmap.bukkit.Helper.getHelper(Helper.java:55) ~[?:?]
at org.dynmap.bukkit.DynmapPlugin.onLoad(DynmapPlugin.java:791) ~[?:?]
at org.bukkit.craftbukkit.v1_15_R1.CraftServer.loadPlugins(CraftServer.java:356) [minecraft_server.jar:git-Spigot-530f668-de42aa1]
at net.minecraft.server.v1_15_R1.DedicatedServer.init(DedicatedServer.java:202) [minecraft_server.jar:git-Spigot-530f668-de42aa1]
at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:783) [minecraft_server.jar:git-Spigot-530f668-de42aa1]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_231]

Feature Implemented

Most helpful comment

Seems like minecraft supports multiple biomes on different y levels now.
I've got a running version for 1.15 / 1.15.1, but it's definitely just a hack till there is proper support available.
I clearly had no Idea what I'm doing at some parts of the patch..
It uses hard-coded y=64 for getting the biome of a location.
(Thrown away older forge support as my java version was too high to build them)

dynmap-1.15.1-experimental3.zip
This works fine on my server (in the meantime till proper support is built in)

Patch: https://github.com/pk910/dynmap/commit/a117a2913b0bf2e6e305e9d91398a3973a4efac8

Edit:
Replaced link to experimental2 build.
First version had an issue with the new BiomStorage format. See comment below.

Edit 2:
Replaced link to experimental3 build.
Added support for 1.15.1

All 86 comments

I removed all conditions but
BukkitVersionHelper.helper = new BukkitVersionHelperSpigot114_1();
for temp.

it just works but I don't know if it is safe.

↑↑↑↑↑↑↑↑↑↑↑↑

Sorry for that, is not works.

@Tilerphy
Can you tell me more? Id like to get it going at 1.15 to

Tilerphy , I just pulled your git and compiled and tested with spigot 1.15 , its not working unless there are commits that you have not pushed yet

That doesnt work theres other changes that need to be made such as biome chunk mapping

@Tsoccerguy3 @Furuss I cannot build it now, too. The mave pom file cannot be downloaded today. as the pom is online file, I cannot modify it and I don't know the new path of that pom files.

-=--=-=-=-=
I tried a moment ago, it was failed.
sorry for that.

https://github.com/webbukkit/dynmap/pull/2670 . is your compile issue because of this maven change

I do these in my repo.:

  1. write a bukkit_helper for 1.15R1
  2. change some code
  3. change the gradle settings

I really built a jar, but when I loaded it in my spigot 1.15, the map view is black, all black.
I found some functions of IBlockData had been changed. But I don't know what changed, so I can do nothing after that.

Mojang/Microsoft has released the deobfuscated source for some of the code , get that and you will have the names functions and methods .

has mikeprimm already written a word about the 1.15?

@tilerphy more changes needed for chunk mapping code

In MapChunkCache class for 1.15

Seems like minecraft supports multiple biomes on different y levels now.
I've got a running version for 1.15 / 1.15.1, but it's definitely just a hack till there is proper support available.
I clearly had no Idea what I'm doing at some parts of the patch..
It uses hard-coded y=64 for getting the biome of a location.
(Thrown away older forge support as my java version was too high to build them)

dynmap-1.15.1-experimental3.zip
This works fine on my server (in the meantime till proper support is built in)

Patch: https://github.com/pk910/dynmap/commit/a117a2913b0bf2e6e305e9d91398a3973a4efac8

Edit:
Replaced link to experimental2 build.
First version had an issue with the new BiomStorage format. See comment below.

Edit 2:
Replaced link to experimental3 build.
Added support for 1.15.1

That zip works fine for me also.

@pk910 Nice work, maybe make a pull request with your changes, you never know they could be perfect

diff --git a/build.gradle b/build.gradle
index a1e9a0e3..92bbd828 100644
--- a/build.gradle
+++ b/build.gradle
@@ -13,7 +13,7 @@ allprojects  {
      maven { url "http://repo.mikeprimm.com" }
      maven { url "http://repo.maven.apache.org/maven2" }
      maven { url "https://hub.spigotmc.org/nexus/content/repositories/snapshots/" }
-     maven { url "http://repo.bstats.org/content/repositories/releases/" }
+     maven { url "https://repo.codemc.org/repository/maven-public/" }
   }

   apply plugin: 'java'
diff --git a/bukkit-helper-114-1/build.gradle b/bukkit-helper-114-1/build.gradle
index 4e2e14e8..08a70441 100644
--- a/bukkit-helper-114-1/build.gradle
+++ b/bukkit-helper-114-1/build.gradle
@@ -5,6 +5,6 @@ dependencies {
   compile project(':bukkit-helper')
   compile project(':dynmap-api')
   compile project(path: ':DynmapCore', configuration: 'shadow')
-  compile group: 'org.bukkit', name: 'bukkit', version:'1.14.1-R0.1-SNAPSHOT'
-  compile group: 'org.bukkit', name: 'craftbukkit', version:'1.14.1-R0.1-SNAPSHOT'
+  compile group: 'org.bukkit', name: 'bukkit', version:'1.15-R0.1-SNAPSHOT'
+  compile group: 'org.bukkit', name: 'craftbukkit', version:'1.15-R0.1-SNAPSHOT'
 }
diff --git a/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/BukkitVersionHelperSpigot114_1.java b/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/BukkitVersionHelperSpigot114_1.java
index ba5cd292..10d59ee7 100644
--- a/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/BukkitVersionHelperSpigot114_1.java
+++ b/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/BukkitVersionHelperSpigot114_1.java
@@ -19,13 +19,13 @@ import org.dynmap.renderer.DynmapBlockState;
 import org.dynmap.utils.MapChunkCache;
 import org.dynmap.utils.Polygon;

-import net.minecraft.server.v1_14_R1.BiomeBase;
-import net.minecraft.server.v1_14_R1.Block;
-import net.minecraft.server.v1_14_R1.BlockFluids;
-import net.minecraft.server.v1_14_R1.BlockLogAbstract;
-import net.minecraft.server.v1_14_R1.IBlockData;
-import net.minecraft.server.v1_14_R1.IRegistry;
-import net.minecraft.server.v1_14_R1.Material;
+import net.minecraft.server.v1_15_R1.BiomeBase;
+import net.minecraft.server.v1_15_R1.Block;
+import net.minecraft.server.v1_15_R1.BlockFluids;
+import net.minecraft.server.v1_15_R1.BlockLogAbstract;
+import net.minecraft.server.v1_15_R1.IBlockData;
+import net.minecraft.server.v1_15_R1.IRegistry;
+import net.minecraft.server.v1_15_R1.Material;

 /**
  * Helper for isolation of bukkit version specific issues
@@ -130,7 +130,7 @@ public class BukkitVersionHelperSpigot114_1 extends BukkitVersionHelperCB {
            }
            Material mat = bd.getMaterial();
             DynmapBlockState bs = new DynmapBlockState(lastbs, idx, bname, sb, mat.toString());
-            if ((!bd.p().isEmpty()) && ((bd.getBlock() instanceof BlockFluids) == false)) {    // Test if fluid type for block is not empty
+            if ((!bd.getFluid().isEmpty()) && ((bd.getBlock() instanceof BlockFluids) == false)) { // Test if fluid type for block is not empty
                bs.setWaterlogged();
             }
             if (mat == Material.AIR) {
@@ -168,7 +168,7 @@ public class BukkitVersionHelperSpigot114_1 extends BukkitVersionHelperCB {
     */
     @Override
    public int getBiomeBaseWaterMult(Object bb) {
-       return ((BiomeBase)bb).m();
+       return ((BiomeBase)bb).o();
    }

     /** Get temperature from biomebase */
diff --git a/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/MapChunkCache114_1.java b/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/MapChunkCache114_1.java
index 5c2f4ef2..e0b5cbfc 100644
--- a/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/MapChunkCache114_1.java
+++ b/bukkit-helper-114-1/src/main/java/org/dynmap/bukkit/helper/v114_1/MapChunkCache114_1.java
@@ -2,7 +2,7 @@ package org.dynmap.bukkit.helper.v114_1;

 import org.bukkit.block.Biome;
 import org.bukkit.craftbukkit.libs.jline.internal.Log;
-import org.bukkit.craftbukkit.v1_14_R1.CraftWorld;
+import org.bukkit.craftbukkit.v1_15_R1.CraftWorld;

 import java.io.IOException;
 import java.util.Arrays;
@@ -19,12 +19,12 @@ import org.dynmap.renderer.DynmapBlockState;
 import org.dynmap.utils.DynIntHashMap;
 import org.dynmap.utils.VisibilityLimit;

-import net.minecraft.server.v1_14_R1.Chunk;
-import net.minecraft.server.v1_14_R1.ChunkCoordIntPair;
-import net.minecraft.server.v1_14_R1.ChunkRegionLoader;
-import net.minecraft.server.v1_14_R1.DataBits;
-import net.minecraft.server.v1_14_R1.NBTTagCompound;
-import net.minecraft.server.v1_14_R1.NBTTagList;
+import net.minecraft.server.v1_15_R1.Chunk;
+import net.minecraft.server.v1_15_R1.ChunkCoordIntPair;
+import net.minecraft.server.v1_15_R1.ChunkRegionLoader;
+import net.minecraft.server.v1_15_R1.DataBits;
+import net.minecraft.server.v1_15_R1.NBTTagCompound;
+import net.minecraft.server.v1_15_R1.NBTTagList;

 /**
  * Container for managing chunks - dependent upon using chunk snapshots, since rendering is off server thread
@@ -48,7 +48,7 @@ public class MapChunkCache114_1 extends AbstractMapChunkCache {
        private final long inhabitedTicks;

        private static final int BLOCKS_PER_SECTION = 16 * 16 * 16;
-       private static final int COLUMNS_PER_CHUNK = 16 * 16;
+       private static final int COLUMNS_PER_CHUNK = 32 * 32; //16 * 16;
        private static final byte[] emptyData = new byte[BLOCKS_PER_SECTION / 2];
        private static final byte[] fullData = new byte[BLOCKS_PER_SECTION / 2];

diff --git a/bukkit-helper/src/main/java/org/dynmap/bukkit/helper/BukkitVersionHelperGeneric.java b/bukkit-helper/src/main/java/org/dynmap/bukkit/helper/BukkitVersionHelperGeneric.java
index b973db38..2d9de1e6 100644
--- a/bukkit-helper/src/main/java/org/dynmap/bukkit/helper/BukkitVersionHelperGeneric.java
+++ b/bukkit-helper/src/main/java/org/dynmap/bukkit/helper/BukkitVersionHelperGeneric.java
@@ -38,6 +38,7 @@ public abstract class BukkitVersionHelperGeneric extends BukkitVersionHelper {

     /** CraftChunkSnapshot */
     protected Class<?> craftchunksnapshot;
+    private Field ccss_biomestorage;
     private Field ccss_biome;
     /** CraftChunk */
     private Class<?> craftchunk;
@@ -47,6 +48,7 @@ public abstract class BukkitVersionHelperGeneric extends BukkitVersionHelper {
     private Method cw_gethandle;

     /** BiomeBase related helpers */
+    protected Class<?> biomestorage;
     protected Class<?> biomebase;
     protected Class<?> biomebasearray;
     protected Field biomebaselist;
@@ -130,8 +132,10 @@ public abstract class BukkitVersionHelperGeneric extends BukkitVersionHelper {
         cw_gethandle = getMethod(craftworld, new String[] { "getHandle" }, new Class[0]);
         /* CraftChunkSnapshot */
         craftchunksnapshot = getOBCClass("org.bukkit.craftbukkit.CraftChunkSnapshot");
+        biomestorage = getNMSClass("net.minecraft.server.BiomeStorage");
+   ccss_biomestorage = getPrivateField(craftchunksnapshot, new String[] { "biome" }, biomestorage);
         biomebasearray =  getNMSClass("[Lnet.minecraft.server.BiomeBase;");
-        ccss_biome = getPrivateField(craftchunksnapshot, new String[] { "biome" }, biomebasearray);
+        ccss_biome = getPrivateField(biomestorage, new String[] { "f" }, biomebasearray);
         /* CraftChunk */
         craftchunk = getOBCClass("org.bukkit.craftbukkit.CraftChunk");
         cc_gethandle = getMethod(craftchunk, new String[] { "getHandle" }, new Class[0]);
@@ -223,6 +227,7 @@ public abstract class BukkitVersionHelperGeneric extends BukkitVersionHelper {
             }
         }
         if(!nofail) {
+            Log.severe("1. " + type);
             Log.severe("Unable to find field " + ids[0] + " for " + cls.getName());
             failed = true;
         } 
@@ -375,7 +380,8 @@ public abstract class BukkitVersionHelperGeneric extends BukkitVersionHelper {
     }

     public Object[] getBiomeBaseFromSnapshot(ChunkSnapshot css) {
-        return (Object[])getFieldValue(css, ccss_biome, null);
+        Object storage = getFieldValue(css, ccss_biomestorage, null);
+        return (Object[])getFieldValue(storage, ccss_biome, null);
     }
 //    public boolean isCraftChunkSnapshot(ChunkSnapshot css) {
 //        if(craftchunksnapshot != null) {
diff --git a/spigot/src/main/java/org/dynmap/bukkit/Helper.java b/spigot/src/main/java/org/dynmap/bukkit/Helper.java
index c785ba54..13e6ead8 100644
--- a/spigot/src/main/java/org/dynmap/bukkit/Helper.java
+++ b/spigot/src/main/java/org/dynmap/bukkit/Helper.java
@@ -35,8 +35,7 @@ public class Helper {
                 Log.info("Loading Glowstone support");
                 BukkitVersionHelper.helper = new BukkitVersionHelperGlowstone();
             }
-            else if (v.contains("(MC: 1.14.1)") || v.contains("(MC: 1.14.2)") ||
-                v.contains("(MC: 1.14.3)") ||  v.contains("(MC: 1.14.4)")) {
+            else if (v.contains("(MC: 1.15)")) {
                 BukkitVersionHelper.helper = new BukkitVersionHelperSpigot114_1();
             }
             else if (v.contains("(MC: 1.14)")) {

this is my temporary patch
working server: http://mine.iruis.net/map

Seems like minecraft supports multiple biomes on different y levels now.
I've got a running version for 1.15, but it's definitely just a hack till there is proper 1.15 support available.
I clearly had no Idea what I'm doing at some parts of the patch..
It uses hard-coded y=64 for getting the biome of a location.
(Thrown away older forge support as my java version was too high to build them)

dynmap-1.15-experimental.zip

on boot it does not create a directory and commands just bring up the help on screen as if you enter a wrong command after the /dynmap

7:36:24 PM [warning] [dynmap] Task #5404 for dynmap v3.0-beta-6-Dev generated an exception
7:36:24 PM [javastacktrace] java.lang.NullPointerException: null
7:36:24 PM [javastacktrace] at org.dynmap.bukkit.DynmapPlugin$3$1.run(DynmapPlugin.java:1110) ~[?:?]

For it to work with Lucky Perms 5 you will need to pull https://github.com/webbukkit/dynmap/pull/2670 as well . It does work when i remove the lucky Perms plugin

Mojang/Microsoft has released the deobfuscated source , get that and you will have the names functions and methods .

I really want to know how to get that deobfuscated source, even though @pk910 provided a great solution before. Does Mojang or MS publish the code in github or other where? It is so difficult to write plugins without the source code. Thank you man, please tell me the way.

Mojang/Microsoft has released the deobfuscated source , get that and you will have the names functions and methods .

I really want to know how to get that deobfuscated source, even though @pk910 provided a great solution before. Does Mojang or MS publish the code in github or other where? It is so difficult to write plugins without the source code. Thank you man, please tell me the way.

https://github.com/Mojang , to start , you can also reach out to Nathan Adams https://twitter.com/dinnerbone?lang=da .
https://www.minecraft.net/en-us/article/programmers-play-minecrafts-inner-workings
Check here for links to other resourses https://help.minecraft.net/hc/en-us

Mojang/Microsoft has released the deobfuscated source , get that and you will have the names functions and methods .

No, they haven't. They've released a few specific libraries that are used in Minecraft, not the source of the entire game.

You can find the deobfuscation mappings under .minecraft/versions/1.15/1.15.json under "client_mappings". It links to https://launcher.mojang.com/v1/objects/b52d82f713bfa18764b35f26d8fff5dc3d9476cd/client.txt

has mikeprimm already written a word about the 1.15?

It's unfortunately not working correctly, yet.
I've noticed some strange biome borders:
http://mc.pk910.de/?worldname=world1&mapname=flat&zoom=4&x=172&y=64&z=99

I'd hit it.

In 1.15 biome information is no longer stored as a 16x16 field array, it stores them in a 4x4x64 (x,z,y) cube...
That really makes no sense in my eyes - especially as the 64 layers on the y axis hold the exact same data at the moment.
image

The result out of this is that biome information is now only available per 4x4 (x,z) field, which is a visible quality loss on the map :/

For chunks that have not been loaded since 1.15 the old biome information is still stored, which is incompatible with the new format.
I've added proper handling for both formats to my patch (https://github.com/webbukkit/dynmap/pull/2692/commits/168850f61e816522c5115ebe28c38df6d164ce56).
That solves the strange biome borders I've mentioned before.

New version: dynmap-1.15-experimental2.zip
(Again: This is not an official patch, it's just a hack and should be replaced when proper 1.15 support is built in)

@pk910 could you merge this pull request into yours https://github.com/webbukkit/dynmap/pull/2670

This all looks very promising! And I really appreciate the work on understanding the new biome format - I usually need to do the reverse engineering myself there :)

good to see you. I hope you can do it. Goofy that you have to invest so much time again and again with each new version .... this gives you gray hair ^^

Hi everyone,
I post this here because it's biome related

When I start the PaperMC 1.15 #8 This what I get :

[20:51:45 ERROR]: [dynmap] Unable to find field biome for org.bukkit.craftbukkit.v1_15_R1.CraftChunkSnapshot
[20:51:46 ERROR]: [org.bukkit.craftbukkit.v1_15_R1.CraftServer] Error initializing dynmap - bukkit version incompatible! initializing dynmap v3.0-beta-7-224 (Is it up to date?)
java.lang.IllegalArgumentException: Error initializing dynmap - bukkit version incompatible!
        at org.dynmap.bukkit.helper.BukkitVersionHelperGeneric.<init>(BukkitVersionHelperGeneric.java:159) ~[?:?]
        at org.dynmap.bukkit.helper.BukkitVersionHelperCB.<init>(BukkitVersionHelperCB.java:45) ~[?:?]
        at org.dynmap.bukkit.Helper.getHelper(Helper.java:55) ~[?:?]
        at org.dynmap.bukkit.DynmapPlugin.onLoad(DynmapPlugin.java:791) ~[?:?]
        at org.bukkit.craftbukkit.v1_15_R1.CraftServer.loadPlugins(CraftServer.java:361) ~[patched_1.15.jar:git-Paper-8]
        at net.minecraft.server.v1_15_R1.DedicatedServer.init(DedicatedServer.java:226) ~[patched_1.15.jar:git-Paper-8]
        at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:884) ~[patched_1.15.jar:git-Paper-8]
        at java.lang.Thread.run(Thread.java:835) [?:?]

FYI : I use http://dynmap.us/builds/dynmap/Dynmap-3.0-beta-7-spigot.jar build on the 14th december.

Thanks for your work

can you already estimate whether it will be a lot of work and how long days a week? I hope you don't have to put so much work back into it. It is annoying to rebuild all plugins with every new version. thank you for doing that for us

2696 fix water color (waterFogColor -> waterColor)

Just finished a few hours of merging PRs and sorting out problems with them - new development builds are up, and appear to be running well on 1.15. Good amount of testing remaining, but definitely give the latest dev builds at https://dynmap.us/builds/dynmap/ a look. Specifically, only check the Dynmap-3.0-beta-7-*.jar builds

Hmm, the deta-7 build does not handle the new biome data correctly.
(you're actually just using the fist 256 numbers from the array as the old 16x16 matrix)

This way it generates strange biome borders (or call it a feature "chunk barcode" :D):
image

To be fair:
I've noted this bug only after releasing "the first try of 1.15 support" (experimental1), too.
Everything seems to be working fine (with correct biome borders), but as soon as you trigger a chunk load (just fly along a biome border in creative mode) the biome data is replaced by the new format and dynmap generates the strange biome borders.
image

I suggest using a sea biome border for testing. It's happening on other biome borders, too, but it's not as clearly visible as on sea biomes:
image

Hi, I tried your latest Dynmap-3.0-beta-7-spigot.jar, but it generated a lot of noise and it did not work.
I got this on our console....

[12:38:37] [Server thread/ERROR]: Error occurred while enabling dynmap v3.0-beta-7-236 (Is it up to date?)
java.lang.NoClassDefFoundError: net/luckperms/api/LuckPerms
at org.dynmap.bukkit.permissions.LuckPermsPermissions.create(LuckPermsPermissions.java:29) ~[?:?]
at org.dynmap.bukkit.DynmapPlugin.onEnable(DynmapPlugin.java:865) ~[?:?]
at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:263) ~[spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:352) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:417) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at org.bukkit.craftbukkit.v1_15_R1.CraftServer.enablePlugin(CraftServer.java:462) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at org.bukkit.craftbukkit.v1_15_R1.CraftServer.enablePlugins(CraftServer.java:376) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at net.minecraft.server.v1_15_R1.MinecraftServer.a(MinecraftServer.java:456) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at net.minecraft.server.v1_15_R1.DedicatedServer.init(DedicatedServer.java:266) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:783) [spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_221]
Caused by: java.lang.ClassNotFoundException: net.luckperms.api.LuckPerms
at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.8.0_221]
at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:135) ~[spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:81) ~[spigot-1.15.jar:git-Spigot-047b6f8-61d4b09]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_221]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_221]
... 11 more

I did a bit of searching for info on the new biome format and found this. Not sure if anyone found that but this part in particular seemed a bit concerning:

The actual concrete biome on a block is calculated with an algorithm that interpolates between the existing data with a noise map in some way. Since 1.14 did not do that and instead saved the biome for every single block column, the biome borders change when a world is upgraded to 1.15 (see MC-160939).

If that's true, it seems like this noise generation algorithm will need to be reverse engineered to calculate the block by block biome data needed for smooth biome borders.

Yep - I think you hit it on the head, there. I'm going to try detecting which format it is - should be easy enough since the length of the data is distinct (256 vs 1024). Lemme give that a go - if anyone locates the code for the interpolate, that'd be great: at worst, I'll just do a 2-d linear interpolate between them (which the water and grass tinting already do - just between adjacent blocks vs the center of 4x4 blocks)

On the LuckPerms one - I just received that update, and didn't do further testing. It allegedly was for supporting a newer version of LuckPerms - might need to see what version you are using vs the version that that PR incorporated (v5.0). If using v5.0 is a problem, I might alter the code for the PR to include both the older version and the newer version.

New builds up - give them a try as far as the 1.15 biome rendering

Also, from what I can tell, the random biome stuff being discussed is likely a jitter on translation from the block coordinate to the actual 4x4x4 biome data: when rendering coordinate X, Y, Z, apply a noise function that generates a smooth offset from X, Y, Z, and then pick the biome corresponding to the 4x4x4 at that offset. So it's a noise field around the 4x4x4 grid of biome that effectively jitters the 'edges' of that uniform grid. The code for this appears to not to be in the server side (which makes sense, since this a purely rendering-side behavior), so supporting it will involve digging that up, and seeing if using the related noise functions are practical.

This is how it looks with the latest version. You can see it is getting slow :)

dynmap

For what it's worth, here is the biome jittering code from the 1.15 client source:
`
package net.minecraft.world.level.biome;
import net.minecraft.util.LinearCongruentialGenerator;
public enum FuzzyOffsetBiomeZoomer implements BiomeZoomer {
INSTANCE;

   public Biome getBiome(long var1, int var3, int var4, int var5, BiomeManager.NoiseBiomeSource var6) {
      int var7 = var3 - 2;
      int var8 = var4 - 2;
      int var9 = var5 - 2;
      int var10 = var7 >> 2;
      int var11 = var8 >> 2;
      int var12 = var9 >> 2;
      double var13 = (double)(var7 & 3) / 4.0D;
      double var15 = (double)(var8 & 3) / 4.0D;
      double var17 = (double)(var9 & 3) / 4.0D;
      double[] var19 = new double[8];

      int var20;
      int var24;
      int var25;
      for(var20 = 0; var20 < 8; ++var20) {
         boolean var21 = (var20 & 4) == 0;
         boolean var22 = (var20 & 2) == 0;
         boolean var23 = (var20 & 1) == 0;
         var24 = var21 ? var10 : var10 + 1;
         var25 = var22 ? var11 : var11 + 1;
         int var26 = var23 ? var12 : var12 + 1;
         double var27 = var21 ? var13 : var13 - 1.0D;
         double var29 = var22 ? var15 : var15 - 1.0D;
         double var31 = var23 ? var17 : var17 - 1.0D;
         var19[var20] = getFiddledDistance(var1, var24, var25, var26, var27, var29, var31);
      }

      var20 = 0;
      double var33 = var19[0];

      int var34;
      for(var34 = 1; var34 < 8; ++var34) {
         if (var33 > var19[var34]) {
            var20 = var34;
            var33 = var19[var34];
         }
      }

      var34 = (var20 & 4) == 0 ? var10 : var10 + 1;
      var24 = (var20 & 2) == 0 ? var11 : var11 + 1;
      var25 = (var20 & 1) == 0 ? var12 : var12 + 1;
      return var6.getNoiseBiome(var34, var24, var25);
   }

   private static double getFiddledDistance(long var0, int var2, int var3, int var4, double var5, double var7, double var9) {
      long var11 = LinearCongruentialGenerator.next(var0, (long)var2);
      var11 = LinearCongruentialGenerator.next(var11, (long)var3);
      var11 = LinearCongruentialGenerator.next(var11, (long)var4);
      var11 = LinearCongruentialGenerator.next(var11, (long)var2);
      var11 = LinearCongruentialGenerator.next(var11, (long)var3);
      var11 = LinearCongruentialGenerator.next(var11, (long)var4);
      double var13 = getFiddle(var11);
      var11 = LinearCongruentialGenerator.next(var11, var0);
      double var15 = getFiddle(var11);
      var11 = LinearCongruentialGenerator.next(var11, var0);
      double var17 = getFiddle(var11);
      return sqr(var9 + var17) + sqr(var7 + var15) + sqr(var5 + var13);
   }

   private static double getFiddle(long var0) {
      double var2 = (double)((int)Math.floorMod(var0 >> 24, 1024L)) / 1024.0D;
      return (var2 - 0.5D) * 0.9D;
   }

   private static double sqr(double var0) {
      return var0 * var0;
   }
 }

`

OK - modified the updated LuckPerms code to use the LuckPerms 5 API for the 5.x LuckPerms, while restoring the support for the LuckPerms 4 API for the older/existing mods. I don't have a viable LuckPerms configuration, so I'll need someone using LuckPerms with realistic settings to gauge if this helped with the previously reported issues. Check newest beta-7 builds.
@MrKiller01

Thanks for the quick update on this!

OK - just pushing support for the new 1.15 blocks - latest dev builds should have them in a few minutes (build 241 or later).

Where would I find these latest dev builds?

Where would I find these latest dev builds?

https://dynmap.us/builds/dynmap/Dynmap-3.0-beta-7-spigot.jar

OK - just pushing support for the new 1.15 blocks - latest dev builds should have them in a few minutes (build 241 or later).

I hope you can do it with the water with the different water biomes. Then the plugin would be usable again

OK - just pushing support for the new 1.15 blocks - latest dev builds should have them in a few minutes (build 241 or later).

I hope you can do it with the water with the different water biomes. Then the plugin would be usable again

Not clear what you mean - what about the current state of the water shading makes it 'not usable'? If you're waiting for the noise field processing, you're gonna be waiting for a bit.... and you've got much higher level definition of 'usable' than most....

but is usable .. I'm also glad I think it's just a shame that they always screw so much on it that they get so much work. I am thankful for your work. it is the best plugin from spigot

Just tagged and released 3.0-beta-7 to spigotmc and dev.bukkit.org, so folks should have official build available now. Pivoting dev build back to 3.0-SNAPSHOT.

Im currently running 1.15 on my server with 3.0-beta-7 and I'm getting some weird lighting bugs

screenshot of world flat
Screen Shot of world flat

screen shot of world surface
Screen Shot of world surface

If the chunks were generated using anything other than vanilla client activity (e.g. WorldBorder fill), there is literally nothing I can do about the fact that they don't properly generate lighting data: in the absence of properly produced lighting data, all I have the option to do is a) assume full sky lighting (which will make under-water bright, but land look OK) or b) assume no sky lighting (which creates black patches. If it gets better after you fly a player via the client over the area and then rerender, then that is where we are.

I can make them black again.... ;) . As I said on the defect thread: if
you use WorldBorder or other tools to 'fill' or otherwise generate chunks,
and those chunks don't have properly generated lighting data, I basically
have two choices (short of creating my own version of the lighting
code....): a) assume the missing lighting data is 'full daylight" (which is
what I do now), or b) assume the missing lighting data is "no daylight"
(the black that everyone was whining about).

On Mon, Dec 16, 2019 at 3:52 PM Blueeyestar notifications@github.com
wrote:

Can you do something about it that the whole sea changes to bright cube
colors? or just wait until more time has passed?

[image: dynmap115]
https://user-images.githubusercontent.com/35557302/70946048-bd188b00-2056-11ea-99f9-b9f980bdf94e.png


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/webbukkit/dynmap/issues/2689?email_source=notifications&email_token=AAE7ZF4Q5KFVRWCXQIAIY6TQY72CHA5CNFSM4JZHCMDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHAHH3I#issuecomment-566260717,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAE7ZF663FPOK32NPCFQLLDQY72CHANCNFSM4JZHCMDA
.

--
--Mike

I don't think the lighting issue is related to WorldEdit. Here's what I did: I upgraded my plugin and server from 1.14.4 to 1.15. We have a small world (4096 x 4096), So I went in game and manually flew over every chunk to load and update them. I then did a full render of the world. Afterward I had the same "too bright" underwater lighting as pictured above. Even in normal oceans you can see all the sand and gravel at the bottom. Perhaps there's an issue with how Minecraft is updating the chunk lighting data when converting the chunks to 1.15 format?

We only use two plugins, dynmap and my own custom block protection / economy plugin.
So bright

I. DON'T. MAKE. LIGHTING. DATA. SO. I. CANNOT. FIX. LIGHTING DATA. :) If they changed the lighting data generation, then that is what they did - if you look underwater, you do seem to have a lot more light than I recall seeing (and this would explain some of the issues with un-migrated chunks with old lighting data vs newer chunks with new lighting data).

2019-12-17_08 34 56

So you mention that vanilla client activity is the only way for proper lighting data to be generated. Does this mean that lighting data is calculated by the client at some point or only generated by the server when a client enters those chunks? I am curious about how this all work. Is there anywhere I can go to learn more about this?

Here's the root of it: it's not that client activity is the ONLY way to get the lighting right - by definition, it is the CORRECT way to get chunks generated properly, including lighting (Mojang bugs notwithstanding). If a mod or plugin or other process produces the SAME result, then it is also correct - but only if that is true. If using WorldBorder or WorldEdit or Chunkster or whatever yields world data inconsistent with that resulting from vanilla client driven world generation, they are at fault - and you really cannot expect folks that depend on the correctness of that world data to handle their errors. Please don't take this as a slam on WorldBorder - it's been, and continues to be, an amazing plugin, and the challenge of doing the 'fill' process is a tough one, as is the challenge of Spigot providing APIs to enable this to be done right - I know, I worked as a contributor Bukkit and Spigot for multiple years (and developed some of the chunk APIs that Dynmap used to use). Dynmap specifically AVOIDS the chunk generation business because of the fact that this is a hard (and dangerous) problem to solve.

Also, it's not the client that does the lighting generation - it's done server side: it's just that the code paths used by the 'vanilla' code to drive this are almost never exactly the same as those used by mods and plugins: we can and do see differences at times between what happens when you call the 'loadChunk()' API in Spigot and when the chunk is generated 'naturally' by the server supporting client activity. Sometimes the difference is due to the order of things (clients always cause chunks to be loaded in square 21x21 contiguous regions, so every chunk generated in that way always has at least 3 neighbors, while an API call call can cause a chunk to generate with no prior neighbors), but more often it's just that the API code path isn't quite the same - and the fact that chunk generation now has a lot more stages than before has made this tougher for the API to get it right (it used to be there were just 2 stages - now there are around 5, and each stage is dependent upon the neighboring chunks being at least up to stage N-1 when moving a chunk to stage N).

What I can do, and am willing to consider, is if there are things I can do to 'just in time' fix data I've loaded from a chunk - but it needs to be safe and reliable, which means not using generally thread-unsafe Spigot and MC APIs from outside the server thread (but doing so from inside it is a lag concern) and often means producing my own safe versions.

I'm also completely on board if it turns out that the client rendering is doing something new that my custom ray tracer isn't - I know that the 'fog' under water only used to be used when you were under water, but perhaps they're using it even when looking through the water from the air above: if that is true, I'll be happy to try to emulate that behavior. If there is something like this, or some other client-side processing going on, and WE can figure out what it is, I'm completely on board with trying to implement it! The goal of the Dynmap ray tracer is to try to produce equivalent views to that of the vanilla client (with some additional support for OptiFine enhanced resource packs) - just adjusted to be isometric vs perspective - so anything within that wheelhouse is something I'm quite ready to try to do. That said, I'm working without OpenGL or a GPU, so it sometimes need to be 'good enough approximations'.

Here's the root of it: it's not that client activity is the ONLY way to get the lighting right - by definition, it is the CORRECT way to get chunks generated properly, including lighting (Mojang bugs notwithstanding). If a mod or plugin or other process produces the SAME result, then it is also correct - but only if that is true. If using WorldBorder or WorldEdit or Chunkster or whatever yields world data inconsistent with that resulting from vanilla client driven world generation, they are at fault - and you really cannot expect folks that depend on the correctness of that world data to handle their errors. Please don't take this as a slam on WorldBorder - it's been, and continues to be, an amazing plugin, and the challenge of doing the 'fill' process is a tough one, as is the challenge of Spigot providing APIs to enable this to be done right - I know, I worked as a contributor Bukkit and Spigot for multiple years (and developed some of the chunk APIs that Dynmap used to use). Dynmap specifically AVOIDS the chunk generation business because of the fact that this is a hard (and dangerous) problem to solve.

What I can do, and am willing to consider, is if there are things I can do to 'just in time' fix data I've loaded from a chunk - but it needs to be safe and reliable, which means not using generally thread-unsafe Spigot and MC APIs from outside the server thread (but doing so from inside it is a lag concern) and often means producing my own safe versions.

I'm also completely on board if it turns out that the client rendering is doing something new that my custom ray tracer isn't - I know that the 'fog' under water only used to be used when you were under water, but perhaps they're using it even when looking through the water from the air above: if that is true, I'll be happy to try to emulate that behavior. If there is something like this, or some other client-side processing going on, and WE can figure out what it is, I'm completely on board with trying to implement it! The goal of the Dynmap ray tracer is to try to produce equivalent views to that of the vanilla client (with some additional support for OptiFine enhanced resource packs) - just adjusted to be isometric vs perspective - so anything within that wheelhouse is something I'm quite ready to try to do. That said, I'm working without OpenGL or a GPU, so it sometimes need to be 'good enough approximations'.

I think you're doing great work. Thank you for never giving up the many years. You are the soul of the Dynmap. I wish you a Merry Christmas and many thanks for everything :)

Merry Christmas and Happy Holidays to you guys, as well! We'll keep working on this - and with the great PRs I've gotten, I know that a few of you guys are well able to help with figuring this stuff out with me :)

For my part, I'm gonna do some investigation of the specifics of the lighting data 1.15 is generating, and see if I can understand why things are different: it very well may be that they've messed with the rendering on the client side, and the interpretation of the lighting data needs to be adjusted. Gotta start with looking at the details, and go from there. The fact that there IS migration of the chunks happening on-demand when the clients go over a formerly 1.14 (or earlier) chunk to, at least, the new biome layout does make it suspicious that there might be other reinterpretations of the data (whether new data, or different ways the existing data is being processed).

Thank you for your attention to this and, even if it is unresolvable, dynmap is still amazing and it won't stop me from using it! Thanks again and happy holidays!

Now the 1.15.1 is outside unfortunately the dynmap is not usable again .. why is it this time?

java.lang.IllegalArgumentException: Error initializing dynmap - bukkit version incompatible!
at org.dynmap.bukkit.helper.BukkitVersionHelperGeneric.(BukkitVersionHelperGeneric.java:166) ~[?:?]
at org.dynmap.bukkit.helper.BukkitVersionHelperCB.(BukkitVersionHelperCB.java:45) ~[?:?]
at org.dynmap.bukkit.Helper.getHelper(Helper.java:59) ~[?:?]
at org.dynmap.bukkit.DynmapPlugin.onLoad(DynmapPlugin.java:809) ~[?:?]
at org.bukkit.craftbukkit.v1_15_R1.CraftServer.loadPlugins(CraftServer.java:356) [spigot.jar:git-Spigot-2ee05fe-30a1b69]
at net.minecraft.server.v1_15_R1.DedicatedServer.init(DedicatedServer.java:202) [spigot.jar:git-Spigot-2ee05fe-30a1b69]
at net.minecraft.server.v1_15_R1.MinecraftServer.run(MinecraftServer.java:783) [spigot.jar:git-Spigot-2ee05fe-30a1b69]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]

It will always fail for new versions as the supported versions are hardcoded in source.
Updated my experimental build: dynmap-1.15.1-experimental3.zip

Official build gives me the bright water lightning described by others, too...
(I don't really like it, so I stayed with my build for now)

@pk910 What changes did you make to get 1.15.1 working? I see your forked repository but the last change there is 3 days old.

@ttshivers you're right, just pushed the commit :)

Already building beta-8 release based on my changes - sorry :)

Edit: v3.0-beta-8 released and posted! Should work on v1.10 throough v1.15.1

If there's any interest in Fabric, I made an issue here: https://github.com/webbukkit/dynmap/issues/2697

Is there a Dynmap 1.15.1 build for Forge? I might be looking in the wrong place, but i'm only seeing up to version 1.3.2. Thanks!

Is there a Dynmap 1.15.1 build for Forge? I might be looking in the wrong place, but i'm only seeing up to version 1.3.2. Thanks!

The is no forge 1.15.1 yet ,

I haven't actually gotten 1.13.2 Forge really 'done' (man, did that break friggin everything - big reason why so few forge mods are still around for 1.13.x+ vs the ones still supported on 1.12.2). Once I've got it working well, moving forward to 1.14.4 and 1.15.1 will likely be more manageable, as neither of these is nearly as big an impact on the world/chunk/block data as 1.13.2 was.

Unfortunately, a lot of the breaks in 1.13.2 for Forge were due to Forge changes, beyond the changes intrinsic to MC - I basically reworked the whole rendering system around dealing with the intrinsic 1.13.x changes, which is why Spigot support works well both for pre 1.13 and post, but the forge changes were also significant enough that things were kind of working but I haven't had time to go back and really deal with all of them.

After a fullrender I get these random black lines on some maps and when i zoom in really close , they disappear . I have teleported to the area and run /cleanlight to fix lighting and then run a /dynmap radiusrender to fix the map , but then there is a dash black line . Can you tell whats causing this . I ran a --forceUpgrade on all the maps , so that all chunks should be updated

Solid line

line3

Afer running a radiusrender the solid line becomes a dash line

line

Zooming in really close the lines disappear

line2

@Tsoccerguy3

I. DON'T. MAKE. LIGHTING. DATA. SO. I. CANNOT. FIX. LIGHTING DATA. :) If they changed the lighting data generation, then that is what they did - if you look underwater, you do seem to have a lot more light than I recall seeing (and this would explain some of the issues with un-migrated chunks with old lighting data vs newer chunks with new lighting data).

2019-12-17_08 34 56

So dear sir, I think that Dynmap is only reading the data that MC is creating itself. I had myself also a few places that were weirdly dark, and it reflected on Dynmap of course, but when I placed torches everywhere the 'darkness' changed to lighter area, so, that reflected also on dynmap.
The most worrying part I recently discovered was the custom-made signs, they are all gone....
When finding an empty map on a wall, there used to be a map of some sort, and those are all gone since 1.14.4 to 1.15+.
So, all I am saying, MOJANG screws up a bit here and there, and we have to live with it and restore it as far as possible.... I hate that, and hope those bozo's at Mojang had a way a bit shorter to get this message to them, but by the time they respond to a mail plea, they are 5 versions higher.......
Happy holidays everyone, and keep counting your fingers if you light a cracker! (👍 ) :)

Had to render my map without shadows in order to fix the water lighting issue.
image

Had to render my map without shadows in order to fix the water lighting issue.
image

How did you do this ? what have you set in the config?

I used LightCleaner to regenerate lightening for every chunk in the world.
Worked fine for me.
https://www.spigotmc.org/resources/light-cleaner.42469/
Command: /cleanlight world

Before:
Image of Yaktocat
After:
Image of Yaktocat

I used LightCleaner to regenerate lightening for every chunk in the world.
Worked fine for me.
https://www.spigotmc.org/resources/light-cleaner.42469/
Command: /cleanlight world

Before:
Image of Yaktocat
After:
Image of Yaktocat

Unfortunately you cannot use it in 1.15.1 as it only goes up to 1.14. Too bad my dynmap would have been so beautiful again without stains

It's working also in 1.15.1 (My server is on Paper-1.15.1 too)
You just have to download the latest dev-build of BKCommonLib!
https://ci.mg-dev.eu/job/BKCommonLib/
https://ci.mg-dev.eu/job/Light-Cleaner/

i'm watching a 1.15.1 snapshot let's see if it works

Normal that the plugin destroys the clean edge?

dynmap

Uhm. Yes? The chunks are loaded fully.
Run a /wb trim after that and restart your server.
After that do /dynmap fullrender

the black border cannot be fixed or undone. do I have to have the map created from scratch?

Use the fill and trim commands from WorldBorder

then does the plugin have to stay on when you have fixed it properly or can you remove it?

Use the fill and trim commands from WorldBorder

Great it worked great thanks for the tip :)

So now I have the server map re-rendered. Unfortunately with a rather modest result. Thanks to the tip from J0schlZ, at least the stains are now gone. Unfortunately, a clean circle border cannot be generated with Worldborder and Dynmap. Who still has the problem?

dynmap

I created the server card from scratch. I did the following:

/wb world fill 20 208

/wb world trim 5000 208

then finally I had the map rendered with:

/dynmap fullrender

as a result, I got it. Mind you there was no user on the server. So what is it now?

did you restart your server after /wb world trim and before /dynmap fullrender?

did you restart your server after /wb world trim and before /dynmap fullrender?

No. Is that important?

Yes.
Also it is maybe helpful to delete the files in %dynmap_folder%/web/tiles/%world%
And be sure to clear the cache in your Browser

I even restarted the server after the trim. but it was immediately to be seen that it will be nothing
dynmap

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Military-Doctor picture Military-Doctor  ·  3Comments

ThorinEk picture ThorinEk  ·  5Comments

uncovery picture uncovery  ·  7Comments

BluCobalt picture BluCobalt  ·  5Comments

MissFox0810 picture MissFox0810  ·  3Comments