Open-source project
SwingTheVine/Wplace-BlueMarble avatar
SwingTheVine/Wplace-BlueMarble

Blue Marble: a template overlay for wplace.live

A versatile template overlay for wplace.live

1,569 stars733 forksJavaScriptMPL-2.0

At a glance

What is it?
Blue Marble is a JavaScript userscript project that adds template overlays to wplace.live, with configurable templates and a Tampermonkey-oriented distribution. Its documented scope is visual guidance, not automatic pixel placement.
Who is it for?
Blue Marble fits wplace.live users who need a configurable reference overlay and want to build or install a userscript release. It does not fit users seeking documented automatic pixel placement, rollback procedures, or a standalone graphics application.
Can I use it commercially?
Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
Is it still maintained?
Yes. The repository last received commits 35 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Blue Marble's role on wplace.live

Blue Marble addresses a specific problem in wplace.live: giving a user a reference image to consult while drawing or selecting an image on the site. The repository describes itself as a "template overlay," and its topics include `template`, `userscript`, and `tampermonkey-userscript`. That makes the intended user clear enough. A person already using wplace.live can add an image-based guide to the page rather than relying on a separate image viewer or manually switching between the source artwork and the canvas.

The project is a client-side browser customization rather than a separate art editor. Its primary language is JavaScript, `package.json` declares the package as an ES module, and the public project page is `https://bluemarble.lol/`. The repository also includes release and distribution links, but the README excerpt ends before its installation instructions. It therefore supports an identification of the product and its intended use, while leaving browser compatibility, supported image formats, and the exact installation sequence unconfirmed.

Automatic drawing is outside the documented feature boundary. The FAQ asks whether Blue Marble can place pixels for the user, but the README does not include that answer. Based on the explicit "template overlay" description, Blue Marble should be evaluated as a visual aid. A user whose goal is automated placement should not infer that capability from the overlay interface.

Userscript overlay architecture and template flow

The repository layout separates source, generated output, and build infrastructure. Top-level entries include `src/`, `dist/`, `build/`, and `docs/`. The `dist/` entry is consistent with the package topic `userscript`, while `src/` is the place to inspect implementation changes. This separation lets contributors change source code and produce a distributable build rather than editing a generated file as the normal workflow.

The documentation identifies both script settings and template settings. That distinction suggests two configuration layers: settings that affect the userscript or overlay as a whole, and settings associated with the selected template. The README excerpt does not expose the setting names, interface controls, image source behavior, zoom mapping, or persistence mechanism. Those details should not be guessed. They need confirmation in the complete README or installed release before an engineer can judge accessibility, repeatability, or compatibility with a particular wplace.live workflow.

Blue Marble's versioning has its own FAQ entry, and the release list includes stable versions such as `v0.94.0` and `v0.93.0`, plus a prerelease named `pre` for version `0.95.0`. The `package.json` version is `0.95.0`. These identifiers show that source version, package version, and release channel may require attention during upgrades. The README does not document automatic update checks, migration between settings formats, or rollback behavior.

Building version 0.95.0 from the repository

The repository provides a small npm build interface. Since `package-lock.json` is present, a source checkout can use the dependency versions recorded in that lock file. The README does not show a complete user installation tutorial, so the following steps stop at building the repository rather than claiming that a particular release has been installed into a browser.

From the repository root, install the locked dependencies with npm:

bash
npm ci

That command reads `package-lock.json` and installs the dependencies declared for the project. It does not install a browser extension or enable the overlay by itself.

Create the distributable output with the documented build script:

bash
npm run build

The script is defined in `package.json` as:

json
{
  "scripts": {
    "build": "node build/build.js"
  }
}

The build dependency set includes `esbuild`, `terser`, `jsdoc`, and `minami`. The README metadata also states a compression figure, but that badge is not a reproducible installation result and should not be treated as a performance claim.

After a build, inspect the generated output under `dist/` and compare it with the release you intend to use. The README does not say whether `npm run build` creates exactly the same artifact as a tagged GitHub release, nor does it identify the browser installation file. That is an important verification boundary for supply-chain review and troubleshooting.

Choosing a release and handling upgrades

Blue Marble is not archived, and the last push was on 2026-09-18. The recorded releases were version `0.94.0` on 2026-09-08, the `pre` release for version `0.95.0` on 2026-09-14, and version `0.93.0` on 2026-09-07. The source package version is `0.95.0`, while the README badge also displays `0.95.0` as its latest version. This close correspondence does not establish that every installation receives the same artifact.

The upgrade cost appears tied to userscript and template compatibility rather than a server migration. The project is distributed as browser-side code, and its repository includes a patch script in addition to the build script. `package.json` defines `patch` as:

json
{
  "scripts": {
    "patch": "node build/patch.js && npm run build"
  }
}

The README does not explain what `build/patch.js` changes, whether patches are tied to particular wplace.live releases, or whether templates require conversion. It would therefore be unsafe to promise painless upgrades. Users should compare the installed userscript version, inspect any stored settings, and verify the overlay against the current wplace.live page before replacing an older release.

There is also no documented rollback command in the README. GitHub releases can contain prior versions, but the text does not say which older release is suitable or how settings should be restored. Upgrade planning must remain manual until the complete documentation specifies compatibility and rollback.

MPL-2.0 scope for users and contributors

The repository identifies `MPL-2.0` as its software license, and `LICENSE.txt` is present at the repository root. That designation matters when deciding whether to modify or redistribute the project, but the README does not reproduce the license text or project-specific notices. This review can identify the declared license, not provide legal advice or interpret how a particular deployment satisfies it.

For users installing the compiled userscript, the practical concern is identifying which source release produced the file they received. The repository offers GitHub releases and an official project website, while contributors are directed to `docs/CONTRIBUTING.md`. Those are the relevant places to trace an artifact back to its source and inspect any accompanying terms.

For contributors, the split among `src/`, `build/`, and `dist/` suggests that modifications belong in source rather than generated output. The project exposes linting and formatting configuration through `.eslintignore`, `.prettierignore`, and `.gitignore`, while `jsdoc.json` indicates documentation generation support. The README does not document a full contributor test suite or release procedure, so it does not support claims about automated verification beyond the existence of build and workflow-related repository entries.

Why Blue Marble is not an automated pixel-placement tool

A template overlay and an automated drawing client solve different problems. Blue Marble's documented role is to display a reference for manual work on wplace.live. A standalone graphics viewer would also provide a reference image, but it would require the user to manage zoom and alignment separately. Blue Marble is more integrated with the page because it is implemented as a userscript for that environment.

Conversely, an automation-oriented tool would submit pixel operations. The repository description does not identify such behavior, and the project should not be described as placing pixels automatically. The missing answer to the README's "How can Blue Marble place pixels for me?" FAQ entry leaves that question unresolved. This distinction matters because automation can change failure modes, server interaction, resource use, and the risks associated with modifying another service. None of those claims should be attached to Blue Marble without explicit documentation.

The overlay also has display constraints. The README's FAQ headings mention missing overlay pixels and game notifications appearing above it. The answers are absent, so the cause and remedy are unknown. Their presence does confirm that stacking, rendering, or missing-pixel behavior are known areas of interest, but it does not establish the severity or frequency of those issues. Users who need exact pixel validation, compositing output, or guaranteed z-order control should seek explicit documentation rather than treating the overlay as an editing canvas.

Editorial conclusion

Blue Marble fits wplace.live users who need a configurable reference overlay and want to build or install a userscript release. It does not fit users seeking documented automatic pixel placement, rollback procedures, or a standalone graphics application. Check the selected release file and template settings first, because the README names the distribution points but does not document the complete installation procedure or supported template formats.

Frequently asked questions

How do I install Blue Marble for wplace.live?

The repository points users to its installation instructions, official website, and GitHub releases, but the README excerpt ends before the actual procedure. It does not preserve the exact release file or browser installation steps.

Can Blue Marble place pixels automatically?

The repository identifies Blue Marble as a template overlay and does not document automatic pixel placement. The README includes an FAQ question about this capability, but its answer is absent.

How do I build Blue Marble from source?

The documented package workflow uses `npm ci` followed by `npm run build`. The build command executes `node build/build.js`.

What license does Blue Marble use?

The repository declares `MPL-2.0` and includes `LICENSE.txt` at the root.

Official sources

  1. License: MPL-2.0
  2. Project website
  3. README
  4. Releases
  5. SwingTheVine/Wplace-BlueMarble on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/swingthevine-wplace-bluemarble.svg)](https://hysenlabs.com/projects/swingthevine-wplace-bluemarble)

Was this useful?