Dynmap 1.15 & 1.15.1

[Blueeyestar]

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.

[01:52:07] [Server thread/ERROR]: [dynmap] Unable to find method getById for net.minecraft.server.v1_15_R1.Block [01:52:07] [Server thread/ERROR]: [dynmap] Unable to find method a for net.minecraft.server.v1_15_R1.BiomeBase [01:52:07] [Server thread/INFO]: [dynmap] Unload queue not found - default to unload all chunks [01:52:07] [Server thread/INFO]: [dynmap] inhabitedTicks field not found - inhabited shader not functional [01:52:07] [Server thread/ERROR]: Error initializing dynmap - bukkit version incompatible! initializing dynmap v3.0-beta-5-218 (Is it up to date?) 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]

[mikeprimm]

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

[CraigParton]

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.

[mikeprimm]

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).

[ttshivers]

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?

[mikeprimm]

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'.

[Blueeyestar]

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 :)

[mikeprimm]

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).

[CraigParton]

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!

[Blueeyestar]

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

[01:01:19] [Server thread/INFO]: [dynmap] Loading dynmap v3.0-beta-7-241 [01:01:19] [Server thread/INFO]: [dynmap] version=git-Spigot-2ee05fe-30a1b69 (MC: 1.15.1) [01:01:19] [Server thread/ERROR]: [dynmap] Unable to find field f for net.minecraft.server.v1_15_R1.BiomeStorage [01:01:19] [Server thread/ERROR]: Error initializing dynmap - bukkit version incompatible! initializing dynmap v3.0-beta-7-241 (Is it up to date?) 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]

[pk910]

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)

[ttshivers]

@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.

[pk910]

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

[mikeprimm]

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

[magneticflux-]

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

[spacegriffin]

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!

[Tsoccerguy3]

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 ,

[mikeprimm]

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.

[Tsoccerguy3]

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

Afer running a radiusrender the solid line becomes a dash line

Zooming in really close the lines disappear

[MrKiller01]

@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).

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! (👍 ) :)

[partydev]

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

[Blueeyestar]

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

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

[ghost]

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: After:

[Blueeyestar]

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: After:

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

[ghost]

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/

[Blueeyestar]

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

[Blueeyestar]

Normal that the plugin destroys the clean edge?

[ghost]

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

[Blueeyestar]

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

[ghost]

Use the fill and trim commands from WorldBorder

[Blueeyestar]

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

[Blueeyestar]

Use the fill and trim commands from WorldBorder

Great it worked great thanks for the tip :)

[Blueeyestar]

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?

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?

[ghost]

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

[Blueeyestar]

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

No. Is that important?

[ghost]

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

[Blueeyestar]

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