Paper 26.x support, update Gradle to 9.5.1, migrate deprecated APIs

[taranovegor]

Adds paper-helper-26x, a new helper module for Paper 26.x with Mojang mappings, using SerializableChunkData for thread-safe chunk access.
Paper 26.x requires paperweight 2.x, which requires Gradle 9. To support this:

• Gradle wrapper updated to 9.5.1; shadow plugin migrated to com.gradleup.shadow:9.4.2
• Deprecated Gradle APIs removed across all modules (archivesBaseName, sourceCompatibility, archivePath, jcenter())
• Fabric modules switched from shadow to bundle; Forge modules excluded from shadow (ForgeGradle 6.x is incompatible with Gradle 9)
• Spigot helper dependencies changed from implementation to runtimeOnly — loaded via reflection

java -version
openjdk version "25.0.3" 2026-04-21
OpenJDK Runtime Environment (build 25.0.3+9-2-deb13u1-Debian)
OpenJDK 64-Bit Server VM (build 25.0.3+9-2-deb13u1-Debian, mixed mode, sharing)

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by net.rubygrapefruit.platform.internal.NativeLibraryLoader in an unnamed module (file:/home/rat/.gradle/wrapper/dists/gradle-9.5.1-bin/iq79hdu3mqx29lgffhp8bfmx/gradle-9.5.1/lib/native-platform-0.22-milestone-29.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/9.5.1/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon will be stopped at the end of the build 

> Configure project :fabric-1.14.4
Fabric Loom: 1.15.5

> Configure project :fabric-1.15.2
Fabric Loom: 1.15.5

> Configure project :fabric-1.16.4
Fabric Loom: 1.15.5

> Configure project :fabric-1.17.1
Fabric Loom: 1.15.5

> Configure project :fabric-1.18.2
Fabric Loom: 1.15.5

> Configure project :fabric-1.19.4
Fabric Loom: 1.15.5

> Configure project :fabric-1.20.6
Fabric Loom: 1.15.5

> Configure project :fabric-1.21.11
Fabric Loom: 1.15.5

> Configure project :fabric-1.21.6
Fabric Loom: 1.15.5

> Configure project :fabric-1.21.9-10
Fabric Loom: 1.15.5

[Incubating] Problems report is available at: file:///home/rat/projects/taranovegor/dynmap/build/reports/problems/problems-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/9.5.1/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 18s
172 actionable tasks: 2 executed, 170 up-to-date
Consider enabling configuration cache to speed up this build: https://docs.gradle.org/9.5.1/userguide/configuration_cache_enabling.html

ls target | xargs -n 1 basename
Dynmap-3.9-SNAPSHOT-fabric-1.14.4.jar
Dynmap-3.9-SNAPSHOT-fabric-1.14.4.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.15.2.jar
Dynmap-3.9-SNAPSHOT-fabric-1.15.2.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.16.4.jar
Dynmap-3.9-SNAPSHOT-fabric-1.16.4.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.17.1.jar
Dynmap-3.9-SNAPSHOT-fabric-1.17.1.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.18.2.jar
Dynmap-3.9-SNAPSHOT-fabric-1.18.2.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.19.4.jar
Dynmap-3.9-SNAPSHOT-fabric-1.19.4.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.20.6.jar
Dynmap-3.9-SNAPSHOT-fabric-1.20.6.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.21.11.jar
Dynmap-3.9-SNAPSHOT-fabric-1.21.11.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.21.6.jar
Dynmap-3.9-SNAPSHOT-fabric-1.21.6.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.21.9-10.jar
Dynmap-3.9-SNAPSHOT-fabric-1.21.9-10.jar.MD5
Dynmap-3.9-SNAPSHOT-spigot.jar
Dynmap-3.9-SNAPSHOT-spigot.jar.MD5
dynmap-api-3.9-SNAPSHOT.jar
DynmapCore-3.9-SNAPSHOT.jar
DynmapCoreAPI-3.9-SNAPSHOT.jar

[jacob1]

Awesome port! Lots of big changes around the codebase for gradle, but they are definitely necessary. Now that it uses official mappings + paperweight, I think the paper wrapper should work for most future versions, rarely needing changes.

The forge builds requiring gradle 8 is a bit weird. I see an announcement on their forums about ForgeGradle 7.x which should work with gradle 9. I don't build or use forge plugins though, no experience there. Wonder if it's even worth fixing, with NeoForge replacing Forge for modern MC versions.

[taranovegor]

Thanks! Keeping the Gradle 8 workaround for Forge for now is on purpose. I don't have a Forge setup to test the builds. It's probably worth opening a separate issue for the ForgeGradle 7.x migration, especially considering where NeoForge seems to be heading for newer MC versions.

[sfphoton]

26.2 came out recently and I noticed your PR could also be compatible with it (and potentially some future versions).

Currently, in spigot/src/main/java/org/dynmap/bukkit/Helper.java line 43 you explicitly check for the version 26.1. You could change it to something like else if (v.contains("(MC: 26.")) {.

I have tested this idea under Spigot and it seems to work.

[taranovegor]

Good point. Now that it's on official mappings + paperweight the helper isn't pinned to one minor version, so widening to 26. makes sense, thanks for testing it on 26.2. I'll get it in next time I'm on this. The next major should make things clearer, and this same approach might well carry over.

[Tsoccerguy3]

Good point. Now that it's on official mappings + paperweight the helper isn't pinned to one minor version, so widening to 26. makes sense, thanks for testing it on 26.2. I'll get it in next time I'm on this. The next major should make things clearer, and this same approach might well carry over.

i compiled your fork and had to add this updated
models_1.txt
to get this jar with updated blocks , for testing with Paper 26.2 build 23 .

[Tsoccerguy3]

Dynmap-3.9-SNAPSHOT-26.1-2.zip

[vpzomtrrfrt]

I'm unable to build this branch, getting this error:

* What went wrong:
A problem occurred configuring project ':paper-helper-26x'.
> Failed to notify project evaluation listener.
   > Unable to resolve a dev bundle, which is required for paperweight to function.
     Add a dev bundle to the 'paperweightDevelopmentBundle' configuration (the dependencies.paperweight extension can help with this), and ensure there is a repository to resolve it from (the Paper repository is used by default).

[Tsoccerguy3]

I'm unable to build this branch, getting this error:

* What went wrong:
A problem occurred configuring project ':paper-helper-26x'.
> Failed to notify project evaluation listener.
   > Unable to resolve a dev bundle, which is required for paperweight to function.
     Add a dev bundle to the 'paperweightDevelopmentBundle' configuration (the dependencies.paperweight extension can help with this), and ensure there is a repository to resolve it from (the Paper repository is used by default).

you need to compile the 26.x with JDK 25

[vpzomtrrfrt]

I am, otherwise it would have failed earlier

[Tsoccerguy3]

I am, otherwise it would have failed earlier

compile Paper and Spigot to local maven on your computer . Do gradlew tasks for commands ,edit settings.gradle for stuff you don't want . start with JDK21 then switch to JDK25 . you need to update the models+1.txt . or get the compiled jar above.

[Tsoccerguy3]

zipped jar
Dynmap-3.9-SNAPSHOT-26.1-2_spigot.jar.zip

zipped checksum
Dynmap-3.9-SNAPSHOT-26.1-2_spigot.jar.zip.sha256.zip

updated
models_1.txt
models_1.txt

texture_1.txt
texture_1.txt

[Schneidertm]

Thank you so much for your work! I really do appreciate it!

I did delete my whole world and a rerender after. Can someone might explain why there are certain black spots. I check them on the map the chunks are not deleted.

[Tsoccerguy3]

Thank you so much for your work! I really do appreciate it!

I did delete my whole world and a rerender after. Can someone might explain why there are certain black spots. I check them on the map the chunks are not deleted.

i think those are lighting errors get this plugin https://github.com/bergerhealer/Light-Cleaner , /tp to the center of the affected region and run the command .

[Tsoccerguy3]

then run a /radiusrender

[Schneidertm]

i think those are lighting errors get this plugin https://github.com/bergerhealer/Light-Cleaner , /tp to the center of the affected region and run the command .

Thanks so much! It worked

[taranovegor]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍

Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip
A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

[Chevels]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍

Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

Hello!
First of all, thanks for your work on Dynmap <3
Unfortunately, ever since I installed this version ("Build of the current branch") and ran /dynmap fullrender, the plugin has stopped working after the server reboot (the web interface shows nothing but a black screen), and the following message appears at startup:
[dynmap] Invalid rotate error - line 1642 of file: models_1.txt

I don't see any file with that name in my Dynmap folder. Can this issue be fixed on my end, or should I switch back to a different fork? It's a shame, because your version seems technically much better 😥

[reusteur73]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍
Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

Hello! First of all, thanks for your work on Dynmap <3 Unfortunately, ever since I installed this version ("Build of the current branch") and ran /dynmap fullrender, the plugin has stopped working after the server reboot (the web interface shows nothing but a black screen), and the following message appears at startup: [dynmap] Invalid rotate error - line 1642 of file: models_1.txt

I don't see any file with that name in my Dynmap folder. Can this issue be fixed on my end, or should I switch back to a different fork? It's a shame, because your version seems technically much better 😥

You could try using one of the versions listed here: https://github.com/reusteur73/dynmap/releases/tag/26.1.fix1

It contains the fixes mentioned above, as well as a fix for bed rendering. Let me know if you run into any issues with it.

[Chevels]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍
Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

Hello! First of all, thanks for your work on Dynmap <3 Unfortunately, ever since I installed this version ("Build of the current branch") and ran /dynmap fullrender, the plugin has stopped working after the server reboot (the web interface shows nothing but a black screen), and the following message appears at startup: [dynmap] Invalid rotate error - line 1642 of file: models_1.txt
I don't see any file with that name in my Dynmap folder. Can this issue be fixed on my end, or should I switch back to a different fork? It's a shame, because your version seems technically much better 😥

You could try using one of the versions listed here: https://github.com/reusteur73/dynmap/releases/tag/26.1.fix1

It contains the fixes mentioned above, as well as a fix for bed rendering. Let me know if you run into any issues with it.

Thanks a lot for your help. Unfortunately, I tested your build—as well as the one provided by taranovegor that included the two fixes—but in every case, I ran into a strange issue:
Everything seems to work fine until the full render of my overworld finishes. At that point, Dynmap becomes inaccessible; ; the page loads indefinitely, only the interface remains, but no matter which map is displayed, there is nothing—everything is black. I should mention that each time, I had to delete the following files:
dynmap.db
dynmap.db-shm
dynmap.db-wal
Heavy.pending (Heavy is the name of our overworld)

Otherwise, upon the next restart, Dynmap indicates "resuming full render..." during startup, but nothing actually resumes since it had already finished before the reboot. Plus, the web interface stops working.

I’ve been using Dynmap on my server for over 15 years and have never encountered this problem.
I don't want to be a bother, so I’m going to roll back to the first build supporting 26.1-2 that I installed a few weeks ago, hoping that sorts things out.

In any case, Pl3xmap is still working perfectly (I use it alongside Dynmap), and just to check, I tested Bluemap, which works correctly too. I’m not sure why Dynmap is struggling so much...

Regardless, thank you all for your work on developing Dynmap ❤

[Schneidertm]

@Chevels why would you run dynmap with storage type sqlite?

After solving the lighting issues mentioned above on one world I'm running extremely well in filetree storage-type. I'm about 10 GB with my biggest world 4000 radius rendered in flat and surface.

I'm extremely thankful for taranovegor and reusteur73 for this PR. Thank you so much!

[okano-softworks]

@taranovegor @Chevels — I think there are two separate faults tangled together here, and only one of them belongs to this PR.

1. Invalid rotate error - line 1642 of file: models_1.txt

This is a four-year-old upstream typo that only becomes fatal on 26.x.

DynmapCore/src/main/resources/models_1.txt line 1640 reads:

[1-14-]modellist:id=campfire,data=12,data=13,data=14,data=15,box=...

That should be [1.14-]. It came in with f433454 (Jan 2022).

HDBlockModels.checkVersionRange splits the range on -, so 1-14- parses as low=1, high=14, and parseVersion weights the first component by 1e10. So the gate has always meant "MC 1 through 14" — which every 1.x version satisfied. On 26.2 the major is 26 > 14, and it evaluates false for the first time in four years.

The unlit-campfire modellist is therefore skipped, so the patchrotate on line 1642 looks up a model that was never built. That lands in the else at HDBlockModels.java:538:

else {
    Log.severe("Invalid rotate error - line " + lineNum + " of file: " + fname);
    return;
}

Note the return — it aborts the parse of the whole file at line 1642 of 4732, so 2,784 further model definitions never load, which is essentially every block model from 1.14 onward. It isn't a cosmetic warning.

The fix is one character:

-[1-14-]modellist:id=campfire,data=12,data=13,data=14,data=15,box=...
+[1.14-]modellist:id=campfire,data=12,data=13,data=14,data=15,box=...

I checked whether there were more of these: I evaluated every line-start version gate in models_0.txt, models_1.txt, texture_0.txt, texture_1.txt and biome_rainfall_temp.txt (138 distinct gates over 7,439 gated lines) against 1.21.11 and 26.2 using the real checkVersionRange/parseVersion/normalizeVersion semantics. [1-14-] is the only gate whose meaning changes. The hardcoded ranges in Java are all open-ended except 1.7.0-1.17.1 in BiomeMap, which already excluded 1.21.11. So it's a family of one.

@Chevels — worth knowing that this is still present in the build you were pointed at: reusteur73/dynmap 26.1.fix1 carries the same [1-14-] on line 1640 with the same three live patchrotate lines under it, so switching builds wouldn't have cleared that error.

Possibly worth a separate look: that return on line 540 could be a continue, as the sibling rotate branch at line 490 already does. One malformed line silently discarding 60% of the model file is a harsh failure mode, and it's what turned a dormant typo into a total loss of block models.

2. The black map after a fullrender — I don't think this is 26.x at all

@Chevels, your second report (black on every world, UI loads but nothing renders, Heavy.pending left behind, "resuming full render" that resumes nothing, cleared only by deleting dynmap.db* and the pending file) matches #3434 almost word for word. That was filed in July 2021 against 3.2-beta on MC 1.16.5, and is still open:

broken "ghost" tasks: tasks that get saved at the time of closing the server, regardless if they are actually finished or not. Those show up again every time the server restarts and either resume, or, if they are actually done, they complete instantly [...] But never get removed! [...] When one (or more) of those render tasks present, the web interface stops working altogether, all dimensions are black and no user skin shows up. If i delete those tasks manually, dynmap initializes properly and the web map works

And @VL4DST3R's follow-up on that issue names the trigger:

this is still an issue if using database storage. Recently I tested by switching to loose files to compare and contrast, and while the crashing/lockup reported here no longer happens...

You listed dynmap.db, dynmap.db-shm and dynmap.db-wal, so you're on SQLite storage. There's also #3720 — "Dynmap fails with large SQLite database using internal webserver or standalone" — closed, same territory.

So before rolling back any further, the thing I'd try is: switch storage/type in configuration.txt from sqlite to filetree, delete the leftover Heavy.pending, and re-run the fullrender. That's the workaround that was actually verified to stop the lockup, and it's independent of which 26.x build you're on.

To be straight about the limits of that: I have not reproduced it myself — my own server runs flat-file storage — so this is pattern-matching your report onto an existing issue, not a diagnosis from a repro. If it does still happen on filetree, that's genuinely new information and worth saying so here, because it would mean #3434 has a second cause.

One theory I chased and ruled out

I first suspected the unreleased post-3.8 commits sitting on v3.0 — the ones rewriting IsoHDPerspective, TexturePack and cutting a net 95 lines out of ShadowHDLighting. Anyone building this branch gets them and no release does, which fit "never seen this in 15 years" nicely. Having read the diffs, I don't think they're implicated: the dropped defLightingTable != null guard is dead code (the field is final and assigned in the constructor), the incremental top/direction hoist in IsoHDPerspective.render() is algebraically exact because Matrix3D is a pure linear 3×3 with no translation term, and the suspicious-looking TexturePack changes are either in the OBJ-export path or are dead stores. Recording that so nobody else spends an evening on it.

@taranovegor — thanks for the quick turnaround on the dev bundle bump and the loaded field access; both confirmed good here on Paper 26.2.

[taranovegor]

Thanks @blackfist666 for the detailed writeups — they've been a big help closing these out quickly. The Invalid rotate error in models_1.txt is fixed, so that point is closed.

@reusteur73, I've cherry-picked 22e830b9, 5ab46bae and 83b79d41 (texture assets, block model/texture definitions, and your bed rendering fix) into my branch — the models1.txt/texture1.txt work is now part of this PR, and the beds issue you flagged on 26.2 should be resolved too.

Fresh builds with all of the above are attached if anyone would like to test.

Dynmap-3.9-SNAPSHOT-spigot.jar.zip

[Chevels]

Hello, and thanks for the replies!

I did actually use the file-based directory structure for storage for over 10 years, but I switched to the .db format in recent years for practical reasons: my Dynmap was generating millions of files (I know it was in the millions, though I don't recall the exact figure). This caused huge issues with SFTP transfers : both during backups and when I needed to transfer the entire server to my pre-production environment. As you know, a vast number of small files (several million in this case) creates an I/O bottleneck and drastically slows down transfers (it would have taken me days to move everything...). I switched to a single .db file not only to facilitate these transfers but also to optimize disk space usage on my SFTP server's SSD (since, again, thousands of small files take up far more space than necessary when they are smaller than the filesystem cluster size).
Going back to the directory-based structure is something I want to avoid at all costs, especially since the previous build I used for version 26.2 worked perfectly with my database.

Thanks for all the explanations; I think I’ll just revert to my old build for now, hoping that in the future I’ll be able to install the newer builds you’re working on while still keeping my database intact 😬

Good luck with the development, and take care!

[jacob1]

I agree that the file-based storage is bad for those same reasons. It was wasting a ton of space due to all the small filesizes, I switched to mysql and that brought the size way down. Never used sqlite.

Haven't seen those issues on my version, although I will say I started a fullrender about a month ago and it's still going lol. I can tell it makes very slight progress every day. I've never seen it go so slow, but it really doesn't bother me since I was only fixing a few small black areas and the biome colors, but I'll report back if the webapp goes unresponsive once it finishes.

[Tsoccerguy3]

Tested Paper 26.3 Pre 2 with this Dynmap build and it seems to be working. Will still need to add new textures #4262 (comment)

[taranovegor]

Tested Paper 26.3 Pre 2 with this Dynmap build and it seems to be working. Will still need to add new textures #4262 (comment)

Good to hear 26.3 runs on the current build, that points to a stable internal API from 26.2.

For now I'm waiting for Paper to publish 26.3 to the Maven repo, which hasn't happened yet. Once the dependency is published, I'll make the changes to this PR and push a separate commit.

Meanwhile, I've put the new 26.3 block models/textures in a temporary PR on my fork: taranovegor#1. I'm not sure I'll be able to test it myself anytime soon, so I'd really appreciate any help with testing and feedback.

[Tsoccerguy3]

Just tested your 26.3 compiled PR only 1 missing texture error reported in console

[23:16:56 ERROR]: [dynmap] Block minecraft:poplar_sign[rotation=0,waterlogged=true] - not enough textures for faces (10 > 6)

[reusteur73]

@taranovegor I haven't tested your 26.3 jar, but looking at the commit in taranovegor#1 (models/textures only), I don't think it can work as-is: 26.3-pre-2 also changes things at runtime, not just block content. Here is what I had to change on my side to get 26.3-pre-2 rendering on Fabric: https://github.com/reusteur73/dynmap/tree/26.3

Platform-independent (DynmapCore):

• Block state palette format changed (BlockState.CODEC is now Codec.either(BLOCK.byNameCodec(), FULL_CODEC)). Palette entries are a plain string minecraft:stone, or {"": "minecraft:stone"}, or {id: ..., properties: {...}} instead of {Name, Properties}. GenericMapChunkCache didn't recognize any of them, so every block resolved to air and the whole map rendered black (tiles written as empty, no error in the log). Commit 13f105e.
• An entry without properties now means the block's default state, not the first registered one. Dynmap picked the first state, so e.g. every bottom slab rendered as type=top,waterlogged=true. Only the game knows default states, so the palette lookup now goes through the block registry in the 26.x chunk caches (Fabric, Forge and paper-helper-26x). Commit 43101c7.
• PatchDefinition.validate() bug: two corners were computed with vmin/vmax on the U axis. It only bites with the partial UVs of the new models (hanging signs, shelf mushroom, straw bed), which were rejected with Invalid modellist patch and dropped from the model. Commit 175be39.

Fabric only:

• ServerboundSignUpdatePacket became a record (pos()/slot()) and SignBlockEntity.updateSignText takes a SignTextSlot instead of a boolean, which broke the sign mixin and kicked players on join. Commit 57396d8.

The palette changes are in SerializableChunkData, which paper-helper-26x uses too, so I'd expect the same black map on Paper. @Tsoccerguy3, when you say it seems to work on Paper 26.3 pre-2, was that with tiles rendered by a previous version, or a fresh fullrender? Freshly rendered chunks are what breaks here: when I ran Dynmap with only the new textures and models on a fresh world, the map was completely black, even though there was no texture or model error in the console.

Since #4263 already sits on top of your branch, the simplest is probably that you cherry-pick the DynmapCore commits (175be39, 13f105e) and the paper-helper-26x part (43101c7) into #4262, and I keep the Fabric/Forge parts in #4263 and rebase once you've pushed, as we did last time.

[Tsoccerguy3]

I Just now Pulled a bunch of Paper 26.3 commits and had time to put Dynmap 26.x through some tests . I purged all the map images. I ran a radiusrender 500 and no map images were generated .

[taranovegor]

@reusteur73 Cherry-picked all three: 175be39 (PatchDefinition.validate corner fix), 13f105e (26.3 palette format support), and the paper-helper-26x part of 43101c7 (default-state resolution via block registry) — dropped the fabric-26.1/forge-26.1 hunks since those modules aren't on this branch, so that part's still yours to land in #4263.

While testing on top, also fixed a few things in my own 26.3 additions:

• Reworked the straw_bed texture/model — now displays with the correct, valid texture instead of the wrong shape/mapping.
• Same for poplar_sign/poplar_wall_sign — texture mapping was off, now renders correctly.
• red_shrub had a texture but no geometry model at all, so it never rendered — added the standard cross-plant patchblock (same as dead_bush).

All pushed on top of your three commits. Thanks you.

taranovegor#1 Dynmap-3.9-SNAPSHOT-spigot.jar.zip

[Tsoccerguy3]

The copper Golem statues got missed in texture and models . They dont get rendered

[taranovegor]

Thanks for flagging this.

You're right, and to be clear that's not something this PR ever addressed, it's a separate, pre-existing gap. Originally noted in #4240: the textures live under /entity, which DynmapBlockScan doesn't pick up, so the statue never got a block/texture mapping in the first place. #4271 later tried a workaround too, though just as a flat single-texture cube (allfaces=0:copper_block).

I spent a bit of time on it and got something a little more detailed working, pulled the face sprite out separately and modeled actual leg/torso/head/arm boxes instead of a flat cube:

Still just an approximation though, not a proper fix, no per-copper_golem_pose geometry (standing/sitting/running/star all render the same shape), same limitation #4240 and #4271 already flagged. Just a bit closer to the real thing than a solid cube.

Since it's unrelated to what this PR is actually about, I think it'd make more sense as its own PR rather than folding it in here.