BlueMap tasks
Task guides and troubleshooting for BlueMap. Check the installed release before changing configuration or data.

Find why a BlueMap build still shows old blocks
A stale-looking build can come from rendering, a frozen map or the browser’s cached view. Check those layers separately before deleting map data. BlueMap normally detects changed chunks automatically, so a full purge should not be the first response to one outdated roof.
Commands beginning with a slash are player chat commands. Use them in game with the required role; check console support before adapting them for the hosting panel.
Work through the change
Write down the affected world, map ID and coordinates. Confirm the build is saved in the running world and compare it with another recently changed location on the same map.
Use 
/bluemap maps and 
/bluemap to check the loaded map and render status. Inspect whether that map is frozen or rendering has been stopped, preserving the reason if it was an intentional maintenance setting.
Inspect 
/bluemap tasks and use the documented troubleshoot command at the affected coordinates. Save the output before requesting a small targeted update using the syntax for your installed release.
Wait for that work to finish, then open the map in a fresh browser session and compare the exact location. Check a second client before concluding the rendered files are still outdated.
Check the result
The changed blocks should become visible after the relevant task completes and the client fetches current data. If only one browser remains stale, inspect its requests or cache rather than restarting Java. If every client shows the old build, retain the task and troubleshooting output for diagnosis.
Check the exact map ID in any targeted command. Similar display names can conceal several views of the same world, each with a different render queue and storage location.
Recover or stop safely
Restore any intentional freeze or rendering pause changed during the test. Avoid 
/bluemap purge for a small update problem: it deletes rendered map data and starts a much larger job. Keep world files untouched while investigating an issue confined to the web map.
Related guidance and maintainer reference
For the broader setup, read Set up a BlueMap web map and control rendering load. Check the installed plugin version before applying syntax from the official BlueMap documentation.

Hide live player locations on BlueMap without removing the terrain map
A public terrain map does not have to publish online player positions. BlueMap separates live player markers from the rendered landscape. Test the public page as a logged-out visitor after changing privacy settings, rather than relying only on an administrator’s browser.
Work through the change
Identify every public map URL and any external web host serving the same data. Back up the installed BlueMap plugin configuration and record the current live-player-markers value.
Read the current plugin configuration reference. Disable live player markers in the documented setting and review related player-list or third-party marker integrations if your privacy policy requires those to be hidden too.
Apply the configuration using BlueMap’s supported method for the installed release. Keep terrain rendering and the web service enabled, then join with a consenting test player and move between several locations.
Open the public map in a fresh browser without staff access. Check the player list, position markers and any separate marker layer supplied by another plugin, including after a normal page refresh.
Check the result
The landscape should remain available while the selected live player information is absent. A removed position marker does not automatically erase names written into signs, static markers or chat integrations. Review those separately before claiming that the entire map is anonymous.
Ask the test player to change worlds as well as move within one map. Privacy should be checked across every public view that can expose their current position.
Recover or stop safely
Restore the recorded configuration if the change breaks the web app, then inspect logs for configuration errors before trying again. Do not remove world data or rendered terrain to hide one information layer. If another plugin republishes player markers, disable that integration through its own supported controls.
Related guidance and maintainer reference
For the broader setup, read Set up a BlueMap web map and control rendering load. Check the installed plugin version before applying syntax from the official BlueMap documentation.

Exclude a private area from a BlueMap render and verify existing tiles
A render mask controls which part of a world BlueMap renders. It is useful for limiting a public map’s scope, but it is not authentication. Already downloaded images and third-party copies cannot be recalled by changing a mask, so plan privacy before publishing sensitive builds.
Work through the change
Record the map ID and the exact horizontal and vertical bounds of the area that should remain public. Back up the map configuration and inspect existing render-mask rules for combined or overlapping shapes.
Read the official mask reference for your BlueMap release. Construct the intended allowed or excluded shape using its documented combination rules, checking boundary coordinates instead of guessing from a zoomed-out map.
Apply the changed map configuration through the supported method. Monitor rendering and removal of tiles outside the new limits, allowing the resulting update work to finish before testing the public page.
Inspect the boundary from several zoom levels and a fresh browser. If edges remain incorrect, review the documented fix-edges control for that map rather than purging every world’s rendered data.
Check the result
The served map should display only the intended footprint after updates complete, with no unexpected cut through a neighbouring public build. Check both low-detail and close-up views. A render mask changes content generation and should not be described as a substitute for access controls on a private map.
Inspect a known coordinate just outside the mask as a negative test. Checking only the public centre proves visibility there but says little about the intended exclusion boundary.
Recover or stop safely
Restore the previous mask configuration if the public area is wrong, then monitor the correction job. Keep private map access restricted while investigating. Do not assume that restoring the old configuration removes previously cached public copies; review web caching and any external storage separately.
Related guidance and maintainer reference
For the broader setup, read Set up a BlueMap web map and control rendering load. Check the installed plugin version before applying syntax from the official BlueMap documentation.

Check a BlueMap resource pack when custom blocks render incorrectly
A custom block that looks right in Minecraft can look wrong on BlueMap if its rendering resources differ. Treat the server map renderer and the player’s resource pack as separate consumers. Test one unmistakable block before adding a large collection of packs.
Work through the change
Record the installed BlueMap version, Minecraft version and exact resource-pack release. Check pack licensing and compatibility before placing a copy where the renderer loads resources.
Read the maintainer’s resource-pack instructions for your installation type. Add the pack in the documented location and preserve the existing pack order, since later resources can override earlier definitions.
Apply a full resource reload through the supported BlueMap control; a light reload deliberately skips resources. Watch the console for missing textures, invalid models and pack-loading errors.
Render a small test area containing the chosen custom block and compare it with the client’s view. Check another vanilla block nearby so a general lighting or missing-chunk issue is not mistaken for a pack problem.
Check the result
The renderer should load the expected resource without new model errors, and the test block should resemble the intended design within BlueMap’s supported features. Client-only rendering features may not have a direct server-map equivalent. Record those limits rather than promising perfect visual parity.
Keep the pack-loading log with the exact tested asset name. A successful resource reload can still contain warnings about one model that explain the remaining visual difference.
Recover or stop safely
Remove only the newly added pack and restore the prior resource order if rendering regresses. Reload resources again and retest the small area. Keep original world blocks intact; replacing a build’s materials is not an appropriate fix for a renderer that cannot interpret one pack feature.
Related guidance and maintainer reference
For the broader setup, read Set up a BlueMap web map and control rendering load. Check the installed plugin version before applying syntax from the official BlueMap documentation.

Diagnose BlueMap mixed-content errors behind an HTTPS map address
An HTTPS map page can still request resources through HTTP if its public and internal addresses are confused. Browsers may block those requests and leave an empty map. Diagnose the failing URL before opening extra ports or changing the Minecraft server’s network rules.
Work through the change
Open browser developer tools on the public map address and record a failed request and its console message. Remove session tokens from any screenshot before sharing it with support.
Compare the public HTTPS hostname with the internal BlueMap web service and the reverse proxy’s documented upstream. Keep the internal service private where the existing design requires it; do not expose it merely to bypass the proxy.
Read BlueMap’s reverse-proxy guidance for your web server. Check path handling and forwarded request settings against the actual deployment, then back up and validate the proxy configuration before applying a targeted correction.
Reopen the public URL in a fresh session and inspect both page assets and map-data requests. Test a deep map link too, since a working homepage can hide an incorrect subpath rule.
Check the result
The public page should load map resources through the intended secure origin without mixed-content blocks. Check the certificate and HTTP response status for the actual failed request. A browser success on a local HTTP address does not establish that the public reverse-proxy path is correct.
Test another map page after correcting a proxy rule. Shared host configuration can affect unrelated views even when the originally failing URL now responds correctly.
Recover or stop safely
Restore the previous validated proxy configuration if unrelated pages fail after the change. Preserve the failing URL and logs so the next adjustment remains targeted. Do not disable browser security or publish internal credentials as a workaround for a map address mismatch.
The game panel lists assigned network allocations. Reverse-proxy configuration is managed separately; this screen does not configure HTTPS or proxy headers.
Related guidance and maintainer reference
For the broader setup, read Set up a BlueMap web map and control rendering load. Check the installed plugin version before applying syntax from the official BlueMap documentation.

Add a second BlueMap view without accidentally pointing it at the wrong world
BlueMap can show several views of the same world or maps of different worlds. The map identifier, displayed name and world save path have different jobs. Set each deliberately so a new menu entry does not silently show terrain from the existing survival map.
Commands beginning with a slash are player chat commands. Use them in game with the required role; check console support before adapting them for the hosting panel.
Work through the change
List current map IDs with 
/bluemap maps and record the intended world’s actual save-folder path. Back up the map configuration you will use as a starting point.
Create the new map configuration using the documented map directory structure. Give it a distinct configuration identity and display name, then set world and dimension to the intended save and dimension.
Check storage choice and render footprint before loading the map. A second view can create additional rendered data even when it reads the same underlying world, so verify available space first.
Apply the configuration and inspect the newly loaded map list. Visit known landmarks on the public menu entry and compare them with the exact target world, not merely with a similar spawn design.
Check the result
The new entry should have its own clear identity and show the intended world or deliberate alternate view. Renaming the displayed name alone does not change the source world. Keep an eye on the render queue so the additional view does not compete unexpectedly with active players.
Record which new data belongs to the extra view before cleanup. Several views may share a source world while keeping separate rendered assets and configuration identities.
Recover or stop safely
Disable the mistaken map configuration through the supported process if it references the wrong save, preserving its files while you inspect the error. Restore the prior map list before deleting any rendered storage. A display configuration mistake does not require removing or regenerating the Minecraft world.
Related guidance and maintainer reference
For the broader setup, read Set up a BlueMap web map and control rendering load. Check the installed plugin version before applying syntax from the official BlueMap documentation.