• Dynmap Version: 3.6 (build from curseforge 2023-07-08)
• Server Version: 1.19.2 forge 43.2.14
• Pastebin of Configuration.txt: https://pastebin.com/NZKqHZsk
• Server Host (if applicable): self hosted

A player moved to the left which made the world generate 4-5 chunks further to the left. However only outer 1-2 chunks get rendered in dynmap. The chunks in between do not. I can't really say that it is always just the outer chunks.

Again reproduced intentionally:

[x] I have looked at all other issues and this is not a duplicate
I found other bugreports that complain about not all chunks becoming rendered but they also do not with fullrender (and they say that's fixed with 3.6)
In my case, if i trigger a full- or radiusrender these chunks do indeed become rendered.

Also found this: #2075
Closed because of outdated version.

Also getting this exact issue, you can see the unrendered newly generated chunks right next to perfectly fine ones:

A fullrender fixes the issue until new chunks are generated.

Dynmap Version: 3.6 
Server Version: 1.20.1 forge 47.1.44
Pastebin of Configuration.txt: https://pastebin.com/Pg8EAAvR
Server Host (if applicable): ShockByte

I talked about that on their Discord but the only answer you,ll get is to use their "recommended settings" which amplifies the problem instead of helping. There is definately a problem with new chunks generation and rendering.

My guess would be something like, Dynmap is trying to read the chunk files too fast, while it is still not fully generated by the server, thus failing and so it moves on reading to the next chunk to render. It's only my guess. Maybe it is totally something else.

Having the same issue. Tagging @JurgenKuyper because he was in the last issue as well. Hi, @JurgenKuyper! I see that you are still active on this repo. Are you perhaps still experiencing this issue?

the only answer you,ll get is to use their "recommended settings" which amplifies the problem instead of helping.

What are those recommended settings exactly? Also have they said how/why exactly is using the recommended settings going to help? What do they do differently? Maybe we can figure out what's causing chunks to be dropped like that and adjust for each server owner's hardware.

the above stated issue is because of forge's async generation, and dynmap is not catching them all, the best is to do a periodic fullrender or radiusrender to update the tiles, I don't have enough coding experience to start to debug this

because of forge's async generation

I'm guessing that's not exclusive to forge? As we're using paper which has the same artifacts.

I tried to reduce maxchunkspertick
Hoping it would give some time to the server to generate the chunks fully before Dynmaps tries to render it... it "seems" to be better, but still have holes.

Asking us to do some periodic fullrender is a bit frustrating... it takes 72h to render my map and eats tons of CPU during that time.

👆🏻 this as well. Re-rendering blindly any "normal" survival map is a multi hour endeavor at best (with no players and all cores churning tiles) or multiple days, which comes with the well known issues of chunks failing to generate for whatever reasons or not picking up from where they left off properly.

I know, but it is the best I can offer, as the dev stated he is not going to investigate if there is no clear explanation and reproducible show-case where it happens, a mitigation is to fully generate the map, and enable the playermove trigger, that seems to fix it somewhat

Assuming the plugin has access to the map file itself, can nothing like a fullupdaterender be made by checking if actual map chunks have dynmap tile equivalents WITHOUT causing them to re-render if already rendered?

I was hoping initial-zoomout-validate kinda did this for dealing with issues with interrupted processing, but not even that seem to correctly find cases where indeed LOD0 exists but the lower res zoom out tiles do not.

that can be done for sure, for example, get first block in chunk, check if tile with that name exists, if not, render, and add a switch for zoomouts only, then you have zoomout-validate also implemented.

Are you by chance involved with the project? Is the above something that maybe you could look into to at least better fix potential holes caused by async chunk gen?

I don't know enough of the code to fix it, and am not a Java dev, this is kind of deep in the code of dynmap itself, but anyone is free to add their code in a pull request

I realised something, looking at the pattern of chunks not generated when this happens, it seems to follow the height of the chunks in some way, being more prone to issues in areas where the Y is taller (on average) and thus spilling over other chunks "behind" it in the isometric view:

Notice how the water seems to be more consistently generated properly than the hills with trees around it.

Any update on this problem? I am experiencing the same problem with current 3.7 snapshot. It is unusable because I have to re-render the whole map after every session, because new areas are generated and many are updated.

This problem is not that visible on already generated chunks, but sometimes it is obious, because there are missing parts of structures that we built/destroyed. Looks like the updated chunks are queued for re-render, but the old version rendered because the new one is not on the disk yet?