Dynmap: Full render not rendering entire map after 1.14.4 update

[Adam759]

Hello everyone,

I recently migrated my world over to 1.14.4 and completely reinstalled all plugins and am in the process of reworking all permissions. The biggest one, as far as size, was Dynmap. The old tiles table in my MySQL server was about 146GB (it is on a 2TB drive, so no worry for space). I have configured a new consolidated database, of which Dynmap is using as well. After fail after fail of attempting to get Dynmap to read the old tiles table, I decided to just bite the bullet and do a new full render. However, I noticed something odd. Dynmap is only loading a small portion of my maps around spawn and reporting "Full Render Completed". Before, there were countless snaking trails and very remote areas of the map. It seems that it is only recognizing chunks where I've been since the update. This is majorly concerning since I already dropped the old Tiles table. What is causing Dynmap to not recognize already generated chunks?

If anyone needs any more info let me know. I have a fairly slim lineup of plugins, am running the newest Paper Spigot 1.14.4 on Ubuntu Server 18.04.

[Adam759]

I did find issue 2503 however that seemed to be concerning pre 1.13. I am coming directly from 1.13.2. I will possibly try the migration setting, at this point I've got nothing to lose.

[Adam759]

After attempting to turn experimental migration on and that failing to provide any results as well, I did a few more hours of research. I found a solution! The old 1.13 chunks are "different" from the 1.14 chunks it would seem, thus the new Dynmap wasn't recognizing them. This is paraphrasing on how I think this works. I thought that Paper would automatically "upgrade" all the chunks from the old world, but it indeed does not. At the end of your starting statement in your start.sh script, if you put the switch --forceUpgrade it will upgrade every single already generated chunk to a 1.14 chunk.

I don't know why this switch isn't more widely known or documented. This has made things a lot more stable and smooth. If any of you are having similar issues, this is how I fixed it!

[XLS202]

Hello,
I think I have the same problem. But nothing seems to fix it. I tried already:

• --forceUpgrade
• --forceUpgrade --eraseCache
• Using migrate-chunks: true
• Optimizing the world in the single player
• rendering the world a few times

But something like this still keeps happening:

[Adam759]

When it renders the "edge" like that it means dynmap thinks any chunks beyond that are not generated so it skips them and renders the literal edges of the chunks it knows are generated. forceUpgrade should have marked the older chunks as generated triggered dynmap to render them.

Are you doing a fullrender?

[XLS202]

Yes i am doing a fullrender.
Also i noticed that there are some spots (to which someone was teleported, so they don't have a connection to the main land) that the dynmap ignores completely.

[fichdlmaa]

Dynmap 3.0 beta 5 -> https://dev.bukkit.org/projects/dynmap/files/2746049
Latest Spigot 1.14.4 build

Hello,

I've got the same problem even with new worlds. 2D and 3D same issue.

I reduced map size to radius about 1k blocks.
Filling and Trimming with worldborder doesn't get rid of missing areas

The only functional way seemes to be:
/tp to every area to trigger chunk (re)loading and then doing a small /radiusrender there (r = 10 .. 50; bigger areas result in more necessary /tp)

But after resizing world to a bigger radius, /fullrender produces large(r) black areas within the additional land. To much work for doing by hand:

Any idea?

Last commit to Dynmap is long ago. Selfcompiling would only produce same Beta 5 ...

[fichdlmaa]

Update: (no player online; all commands via console)

wb welt set 50 -1000 -1100
wb welt fill 10
wb fill confirm
dynmap fullrender welt

welt:flat after nearly 1200 tiles:

What? render NOT withinin "new world area" (red circle) but outside (region most far from X=0|Z=0) !?!

[XLS202]

I think what might help would be to use the force flag in the fill command:
/wb [worldname] fill [freq] [pad] [force]
in youre case:
wb welt fill 10 208 true

Also dynmap renders the world from the center if you use this command from the console.

[fichdlmaa]

Hi @XLS202 - and mny tnx :-)
already got same idea ... some minutes after posting; therefore already results ...

wb welt set 25 -880 -890 <- radius adopted, so that black area border close to red wb line
wb welt fill 10 50 true <- !
wb fill confirm
dynmap fullrender welt:flat

2nd Test Results: (nearly 2400 tiles rendered)

Seems to work this way :-D

[bartymc]

This is still an issue. migrate-chunks does not solve the issue. Dynmap is still incapable of seeing that the chunks are actually generated.

[WoutervanderLoopNL]

same issue here i've an servers its started in 1.6.2. and got the update every time when it comes out.

when upgrading from 1.12 to 1.13/1.14 i needed to rerender de dynmap because of corrupt images during the past years. (and i also moved the tiles to an other storage location).

after that, dynmap is not seeing the chunks which where discovered in 1.6-1.12 and not been visited after the upgrade to 1.14.

the worldborder isnt an option for me. because it renders all the chunks in an radius, i dont want that. because in an futher update. people heve to walk for mile to find new chunks (with new resources)

done al the stuff like this, but nothing is working.

• --forceUpgrade
• --forceUpgrade --eraseCache
• Using migrate-chunks: true

[armeetjatyani]

After attempting to turn experimental migration on and that failing to provide any results as well, I did a few more hours of research. I found a solution! The old 1.13 chunks are "different" from the 1.14 chunks it would seem, thus the new Dynmap wasn't recognizing them. This is paraphrasing on how I think this works. I thought that Paper would automatically "upgrade" all the chunks from the old world, but it indeed does not. At the end of your starting statement in your start.sh script, if you put the switch --forceUpgrade it will upgrade every single already generated chunk to a 1.14 chunk.

I don't know why this switch isn't more widely known or documented. This has made things a lot more stable and smooth. If any of you are having similar issues, this is how I fixed it!

Thank you so much! There was almost nothing about this online.

[bartymc]

After attempting to turn experimental migration on and that failing to provide any results as well, I did a few more hours of research. I found a solution! The old 1.13 chunks are "different" from the 1.14 chunks it would seem, thus the new Dynmap wasn't recognizing them. This is paraphrasing on how I think this works. I thought that Paper would automatically "upgrade" all the chunks from the old world, but it indeed does not. At the end of your starting statement in your start.sh script, if you put the switch --forceUpgrade it will upgrade every single already generated chunk to a 1.14 chunk.
I don't know why this switch isn't more widely known or documented. This has made things a lot more stable and smooth. If any of you are having similar issues, this is how I fixed it!

Thank you so much! There was almost nothing about this online.

Just want to put it out there that Mojang, Paper, and Spigot have all recommended using --forceUpgrade every time you update your server between each major version.

[L4R5]

+1
I reactivated my 1.8 spigot minecraft server and upgraded to paper 300+. (1.15.2) with Dynmap 3.0.1

• --forceUpgrade is doing something but it seems, dynmap only renders things, that I have visited in person since the upgrade
• migrate-chunks: true
  
  
  
  • on the original 1.8 world, it renders everything but in a very distorted way with stripes of black and rendered areas. Update: same as here: https://github.com/webbukkit/dynmap/issues/2704
  
  
  • with forceUpgrade'ing first and this option enabled, dynmap renders the same amount of tiles as with migrate-chunks: false - feels as if chunks are migrated but invisible to dynmap
  
  

[FedUpWith-Tech]

Duplicate of #2282