[Collection] Dynmap not rendering all player-generated chunks

[prenetic]

Minecraft version: 1.10.2 Mod pack: FTB Beyond v1.1.0 Dynmap version: DynmapForge v2.4 Dynmap instance: http://prenetic.com:8123/

As the title states, when players are exploring map tiles are not reliably rendering upon chunk generation. If the server is overloaded at the time (< 18 TPS) the expectation is that these chunks will be added to a queue and processed when server load lessens. Since this is a new, small server, Dynmap keeps up just fine and renders during periods of play assuming we're not out exploring. We can observe in the link above that even once players log off, these tiles for chunks generated while exploring are not rendered.

Ideally we would avoid a scenario where we have to issue "dynmap /fullrender" once a week to ensure the map is up to date. Attempts to fill in the gaps with "dynmap /updaterender" fail because these chunks don't have any activity since being generated to have triggered an update. From our perspective, it just looks like these chunks drop from the queue and are never rendered.

Willing and able to provide any configurations or information to help facilitate resolution on the issue.

[wioxjk]

Do a radiusrender when you are close, but not loading thoose chunks. /dynmap radiusrender 500

[prenetic]

Thanks wioxjk, I'm aware of that workaround, but unfortunately it doesn't do anything to resolve the issue. We can of course issue renders of the world manually, but that sort of defeats the purpose and adds management overhead to something that should be automatic by design.

[ghost]

Hello! I have the same issue. Wouldn't it be possible to store the coordinates of none rendered/updated chunks and just render the stored values? I'm talking about a queue, first in, first out. Best Regards / Rasmus

[prenetic]

There is a queue, you can view this with /dynmap stats. The queue is saved when Dynmap is reloaded or the server stops.

[floomat]

I had the same problem, i searched around for days for a solution and the cause of this problem and i found something...but to directly dissapoint you - no real solution. Sorry! :(

The dynmap does ignore all trigger-events settings in the configuration.txt except "blockupdate" which seems to be "blockchange" in /dynmap triggerstats. Normally triggerstats should provide a list of all trigger-events that occured in the whole runtime of the server, but in the latest versions it just shows blockchange.

Doing fullrender or radiusrender is a stupid workaround recommended by people who have nothing better to do than running around on the world and doing radiusrender all the time, thats freaking annoying isn't it? Even more when you come from a time where the dynmap was working just as it should and renders all the newly generated chunks automatically.

With the latest commits in SpongeForge 1.11.2 they implemented a new feature called async light, i don't know what exactly it's doing but it fires an massive amount of blockchange triggers to the dynmap which causes it to render really good again., except from the Nethermap but i think thats useless anyway.

To be honest this is no fix at all....i think it is a bug in spongeforge which accidentally fixes this problem. Look around in the SpongeForge releases, this should also be implemented in a newer build of 1.10.2.

best regards Flo

[richraid21]

I'm also having the same issue with dynmap using the latest forge build.

[Kingdingbat]

I have also been having this infurating problem.

[MilesBHuff]

Still an issue in v3.2.0-b2.

[prenetic]

Any update on this, or just an acknowledgement that there's a real issue here? Still a problem with the latest builds of Dynmap and PaperMC, years later and through multiple machines, configurations, Forge and Minecraft builds, etc. This doesn't seem to be specific to any given setup and it looks like there have been more than a few reports over the years.

[thtroyer]

I'm not involved with this project, but I've been looking into this issue.

A workaround I've been doing on my servers is a periodic /dynmap fullrender. For me on Paper, this fills in all the areas generated in Minecraft but failed to render tiles.

As a Java dev, I've done some testing and debugging several weeks ago. I've learned a lot, but haven't found a root cause or better workaround yet. What I know so far:

• Based on some limited testing, dynmap with spigot seems to be working as expected, but as noted in this issue, dynmap with paper either fails to render tiles or renders entirely black tiles.
• The in-game fullrender command seems to work as expected for paper, but not the radiusrender command. I haven't yet looked into why or how these commands work/fail.
• Running paper also causes a ton of other dynmap render events to fire constantly, like "blockspread". Disabling these render events in dynmap's configuration had no effect and they didn't seem to clog dynmap's render queue whether on or off. Interesting, but doesn't seem important here.
• When a chunk is generated on paper, dynmap correctly sees the chunk generation event and queues up all the tiles to be rendered. This portion appears to be working correctly.
• I've followed the render process fairly deep. The issue seems to be in/around DynmapPlugin, createMapChunkCache method. The tile fails to render when the returned MapChunkCache object, cache.isEmpty() is true (here) When this cache object is populated correctly (i.e. not empty), the tile renders as it should.

I'm planning to continue to look at this when I have free time and energy, but I'm sharing this in case someone more familiar with the code can spot and fix the problem based on what I've found so far.

(I tested with: spigot -- tested on Manjaro, using spigot package from AUR. paper: tested on Manjaro using papermc from AUR and Ubuntu using paper via AMP.)

[masmc05]

• I've followed the render process fairly deep. The issue seems to be in/around DynmapPlugin, createMapChunkCache method. The tile fails to render when the returned MapChunkCache object, cache.isEmpty() is true (here) When this cache object is populated correctly (i.e. not empty), the tile renders as it should.

what version of dynmap did you use? i made a mistake in my paper's async chunk load support, so in beta4 dynmap was working only with chunks which were saved to disk, this was fixed in beta5

since your comment is relatively new, i may assume it also may be this mistake

[thtroyer]

Sorry, work and life have been crazy and I haven't had a chance to retest on latest yet -- should have some time in a couple weeks.

I can confirm I was running something earlier than beta5. I pulled from the v3.0 branch and it was building as Dynmap-3.4-beta-4-spigot.jar.

[masmc05]

Sorry, work and life have been crazy and I haven't had a chance to retest on latest yet -- should have some time in a couple weeks.

I can confirm I was running something earlier than beta5. I pulled from the v3.0 branch and it was building as Dynmap-3.4-beta-4-spigot.jar.

then most possible it was fixed, but take your time, no need to hurry, because there are only 2 possibilities

1. it was a new mistake and it was fixed already, everyone is happy and you'll just confirm that
2. it was the old issue and nobody has enough time to make a proper test (didn't see anyone making better investigation than yours, but i'm new to dynmap dev community so maybe was something better)

since this issue didn't have any updates for more than a year, and suddenly 2 confirmations in relatively same time, i have big suspicions that it was it (also i had a server without pregenerations and render, and didn't saw such an issue, or it was fixed, or the situation is much better now, not like in newest provided screenshot)

[prenetic]

I'm running Paper 1.19 so is it safe to say that if I pull the latest build, I shouldn't see this issue either? I can do that and provide some feedback if so.

[masmc05]

I'm running Paper 1.19 so is it safe to say that if I pull the latest build, I shouldn't see this issue either? I can do that and provide some feedback if so.

feedback would be appreciated at any time, but most possible even if it will happen, it will be more like in first 3 screenshots, not that bad as in latest screenshot

but a confirmation that it still happens, and if it does, if it's better or worse, would be appreciated (and be sure to wait untill dynmap finishes the render)

[JurgenKuyper]

feedback would be appreciated at any time, but most possible even if it will happen, it will be more like in first 3 screenshots, not that bad as in latest screenshot

but a confirmation that it still happens, and if it does, if it's better or worse, would be appreciated (and be sure to wait untill dynmap finishes the render)

I just tested this on paper build 138 and dynmap-3.4-release, and it seems to be fixed, thanks for all your effort mastermc05!

[Dragule]

Hi, I have the exact same bug on last version of PaperMC (build 200) and Dynmap 3.4 release.

I have to manually render the map after exploring because there are so many chunks missing. Do you guys know what I can do ? :)

[prenetic]

Same here, still occurring.

paper-1.19.2-189 Dynmap-3.4-spigot

[JurgenKuyper]

@prenetic and @Dragule that is not a dynmap issue, seen by the lack of trees around the border of the chunks, thus the chunks not fully being generated. closing this issue as it is no longer relevant because there have since been many builds that require new testing to see if this issue is still apparent, please make a new request if that is deemed so.