Version mismatch on Curseforge latest release

[mjb2k]

template is bold
sample data is italicized

Issue Description: File version is 3.8, on server seeing it has 3.7-SNAPSHOT-1015.

• Dynmap Version: 3.8
• Server Version: Paper 1.21.11 build 116
• Pastebin of Configuration.txt: I can provide on request but I have some personal passwords here for a MySQL DB. This shouldn't matter however.
• Steps to Replicate: Download the Curseforge latest 3.8 bundle release, copy to plugins folder of server and start. One of the first logs...

[19:56:13] [ServerMain/INFO]: [PluginInitializerManager] Initialized XX plugins
[19:56:13] [ServerMain/INFO]: [PluginInitializerManager] Bukkit plugins (XX): ..., dynmap (3.7-SNAPSHOT-1015), ...

I downloaded straight from the curse forge page: https://www.curseforge.com/minecraft/bukkit-plugins/dynmap into my plugins folder, and I got this.

[x] I have looked at all other issues and this is not a duplicate
[x] I have been able to replicate this

[kalinowskitmk]

I noticed the same thing, how to download the correct version?

[adamwbb]

Technical Deep-Dive: Dynmap Asset Build Failure & Version Handshake Bug
System Environment
Mislabeled Release: Plugin JAR marketed as 3.8-spigot, but identifies internally as 3.7-SNAPSHOT-1015.

Server Core: Paper 1.21.11 build 117.

Deployment: External web server (Apache).

1. Evidence of Build Process Failure
   The core of the issue appears to be an uninitialized build template within the JAR's internal resources:

Unprocessed Template Strings: Upon extracting the internal assets, version.js contains a raw Gradle/Maven template variable rather than a hard-coded version.

Current Content: var dynmapversion = "${version}-${buildnumber}";.

Stale Timestamps: The version.js file within the repository structure shows a last-modified date from approximately 8 years ago, suggesting the build script failed to overwrite the placeholder during the packaging of the "3.8" release.

2. Handshake Protocol Breakdown
   The web UI's red banner reporting (undefined) is a direct result of a failed comparison between the web client's local variable and the server's JSON output:

JSON Schema Omission: The plugin-generated standalone/dynmap_config.json is missing the mandatory version key.

Observed JSON Start: {"loginrequired":false, ...}.

Expected JSON Start: {"version":"3.7-SNAPSHOT-1015", "loginrequired":false, ...}.

Variable Scope Issues: Even when manually injecting the version into the JSON, the UI fails to resolve the version, indicating that the logic in map.js or minecraft.js within the 3.7-SNAPSHOT branch may be looking for a differently scoped variable than what is provided in the root version.js.

3. Documented Failure of Manual Overrides
   The following attempts were made to force a version match, all resulting in a persistent (undefined) error state:

Forced Variable Definition: Manually updating version.js to var dynmapversion = "3.7-SNAPSHOT-1015";.

JSON Injection: Using sed to manually insert the version string into the standalone/dynmap_config.json file.

Cache-Buster Removal: Stripping the hard-coded ?_=3.7-SNAPSHOT-1015 suffixes from all <script> and tags in index.html to ensure the browser was not hitting a race condition during file resolution.

Direct Script Injection: Defining var dynmapversion globally within the of index.html prior to loading the map engine.

4. Conclusion for Developers
   The "3.8-spigot" release on Curseforge appears to be a "dirty" build where:

The versioning logic in the Java core does not match the versioning expected by the web assets.

The web assets themselves were packed as raw source templates (${version}) rather than built production files.

The internal JSON generator is failing to include the version metadata required for the web frontend to validate the connection.

TL;DR
The Curseforge "3.8-spigot" JAR is a "dirty" build of 3.7-SNAPSHOT-1015 that contains unpopulated web templates, causing a fundamental handshake failure because the internal assets were never properly processed. This led to version.js containing raw ${version} strings and the dynmap_config.json file missing the mandatory version key, making the (undefined) error persistent even after manual string synchronization and cache clears. The web UI remains broken due to this deep-seated logic and packaging inconsistency within the plugin release, which prevents the frontend from successfully validating its version against the backend data.

[adamwbb]

Workaround Addendum: Resolving the "Version Mismatch" and "Reading '3'" Errors
For users encountering the "(undefined)" version banner or the Uncaught TypeError: Cannot read properties of undefined (reading '3') in 3.7-SNAPSHOT on 1.21.1, the primary workaround is to uncomment the entire class: org.dynmap.InternalClientUpdateComponent section in configuration.txt, even when using an external web server with disable-webserver: true. This "hairbrained" configuration forces the plugin to initialize the core mathematical projection matrix and versioning metadata that the JsonFileClientUpdateComponent often fails to generate independently in recent snapshot builds. Although this causes a visible InvocationTargetException and NullPointerException at boot as the internal component fails to find a router, these errors can be safely ignored; the initialization side-effect ensures that the dynmap_config.json written to your storage (such as a 1TB HDD RAID) is fully populated, satisfying the browser's version check and the hdmap.js coordinate engine.

[diskawrs]

Took me a while to figure out what was amist.
Came here and saw this to confirm my findings.