HOP EARTH
NOT WORKING?

INDEPENDENT CHECKLIST · REVIEWED 31 OCT 2026 · CHECKED AGAINST THE 31 OCT 2026 BUILD · NOT A LIVE OUTAGE REPORT

Start with the stage that failed, not the symptom

The official page is small, but it pulls in six things in sequence. Each one fails in a visible way, and the order tells you where to look. Open the browser developer tools once, keep the Network panel on, and reload a single time rather than repeatedly: fast repeated reloads hide the first failure.

• Spinner never clears — the client bundle did not finish
• Splash works, joining fails — a CDN library or the socket did not load
• World loads but objects, sound or cars are missing — asset host blocked or slow
• Worked yesterday, stuck after an update — service-worker cache
• Menus fine, 3D view black — WebGL2 context refused
• Map panel blank while driving works — public tile servers

If you would rather start from what you can see, the five symptom sections lower down cover the same ground in the order people usually hit them: menus work but the world is black, loading never finishes or roads are missing, keys do nothing, joining or sharing a race fails, and the page or sign-in will not open.

Stage 1: the page shell and the client bundle

The HTML file at hop.earth is short: a splash background image, a hidden spinner element and a list of scripts. The last script is the client itself. On 31 October 2026 that file was bundle10300335.js at about 2.5 MB (2,600,093 bytes), loaded asynchronously from hop.earth. The page also loads front.js and a MapLibre build from assets/scripts/maplibre-gl.js.

Because the scripts are async, the splash screen can paint before the client is ready. That is normal. What is not normal is the spinner staying on screen: the spinner is shown once the client starts and is expected to clear when the world is ready.

The decisive check: in the Network panel, filter for bundle. A 200 with roughly 2.5 MB means this stage passed. A cancelled, blocked or failed request means the fix is at this layer: a proxy or firewall blocking the domain, an extension rewriting script requests, or an interrupted download on a slow connection. A half-downloaded 2.5 MB script on mobile data is a common cause of a spinner that never clears.

Stage 2: two libraries come from a third-party CDN

The official page loads lodash 4.17.21 and socket.io 4.3.2 from cdnjs.cloudflare.com, both with subresource-integrity hashes and crossorigin="anonymous". The client uses them for real-time features rather than for drawing the first frame, which is why this failure looks selective: the game can open, but joining, racing or lobbies never connect.

The decisive check: filter the Network panel for cdnjs. If either request is blocked, the console shows a script error, and an integrity failure reports a digest mismatch instead. Blocking is usually a privacy extension, an ad-blocker with a broad third-party rule, a DNS filter at router level or a corporate proxy. Allowlist cdnjs.cloudflare.com for hop.earth rather than switching off every extension at once, so you learn which one was responsible.

Stage 3: the world assets live on a second domain

The 3D world does not come from hop.earth. The client requests its assets from assets.bad.city under /file/badassets/. That is a separate origin, so a filter that allows hop.earth does not automatically allow it. When this stage fails the result is distinctive: the world appears, but objects are missing, the drive feels empty, sound is absent, or a vehicle never arrives.

The decisive check: filter the Network panel for assets.bad.city and look for failed or pending requests. A handful of slow requests is normal on a first visit because nothing is cached yet. A wall of failures is a block. Because the requests are cross-origin, a CORS or content-blocker message in the console points at the same cause.

Stage 4: a service-worker cache can keep serving an older build

hop.earth registers a service worker at /sw.js. It is small and specific: the cache is named assets-bad-city-v1, and it only handles two hosts, assets.bad.city and cdnjs.cloudflare.com. Everything else, including the client bundle, goes to the network.

The important detail is the order of operations. For those two hosts the worker returns the cached copy before it asks the network. There is no revalidation step. After a change on the server, a browser that already holds the old cache can keep replaying it, and the symptom is exactly what players describe: it worked yesterday, nothing changed locally, and today it hangs. The worker deletes other caches when it activates, but it does not refresh its own entries.

The decisive check: open Application, then Cache Storage, and look for assets-bad-city-v1. Delete that entry and reload. If the page recovers, this was the cause. Clearing all site data for hop.earth does the same thing more thoroughly, but it also signs you out, so record anything you need from the session first.

Stage 5: the 3D view requires WebGL2, not WebGL1

The renderer's capability check is blunt. If the graphics context is not a WebGL2 context, the client throws Error("WebGL2, required to run this app is not supported"). The bundle does contain a WebGL1 fallback path for map drawing, but the main renderer does not accept it. This is why a machine can run the menus, the splash and the map while the world stays black or never appears.

Common reasons a browser refuses WebGL2: hardware acceleration turned off, a graphics driver on the browser blocklist, a remote desktop or virtual machine session without GPU passthrough, or WebGL disabled in the browser settings. Old integrated graphics are not automatically excluded; a current browser with acceleration enabled usually negotiates WebGL2 even on modest hardware.

The decisive check: read the console before changing anything. That exact string is a definitive answer, and it saves you from clearing caches that were never the problem. Then confirm acceleration: chrome://gpu in Chromium browsers, or the graphics section of about:support in Firefox. If acceleration is disabled, enable it and restart the browser rather than reloading the tab.

Stage 6: the map panels use public tile servers

The location picker and route maps are drawn from raster tiles. The client lists three sources: tile.openstreetmap.org, a.tile.openstreetmap.fr/hot and a.basemaps.cartocdn.com/rastertiles/voyager. These serve the flat map imagery. They are not the source of the 3D road geometry, which is built from OpenStreetMap road data as described in the road data guide.

This stage failing is easy to misread, because the game itself keeps working: you can drive, but the map panel stays blank or grey. Public tile services are shared infrastructure with usage limits, so a slow or refused response is a normal thing to see occasionally and is not evidence of a fault in your account.

The decisive check: filter the Network panel for tile and compare one successful request with a failing one. If the panel is the only broken part, the world is fine and you can keep driving.

Menus load but the world stays black

This is the most reported symptom and the least ambiguous one. Work in this order, because each step rules out a whole layer:

1. 01

   Read the console first

   If the WebGL2 error from stage 5 appears, stop here. No amount of cache clearing, reinstalling or account changes will produce a world without a WebGL2 context.

2. 02

   Check hardware acceleration

   Enable it and restart the browser. A restart is required; a tab reload keeps the old process and the same failure.

3. 03

   Watch the asset host

   If the console is clean and the scene is still empty, filter for assets.bad.city. A blocked asset host yields a world that draws its sky and terrain but not its objects.

4. 04

   Compare one clean setup

   One second browser, or one private window with extensions off, separates a device problem from an account or service problem. Do not change several things at once, or you will not know which one mattered.

The world keeps loading or roads are missing

A world that loads slowly and a world that fails to load look similar for the first thirty seconds. Distinguish them by watching whether new requests keep arriving: a large first visit downloads the bundle and then its assets, so a slow connection produces a long but progressing load, while a blocked host produces failures rather than slow successes.

If one location fails while another works, record both. A single location that will not build is a different problem from a client that cannot start, and it is the kind of evidence the developers can act on. Early-access builds have had road-generation and server-pressure problems, so an occasional empty location is plausible without anything being wrong on your side. For a place that stays empty across two browsers, note the approximate coordinates and the time rather than switching pins rapidly.

When the whole client is the problem, revisit stage 4 before anything else: a stale asset cache is the most common reason a working setup stops working after a build change.

The world loads but keys do nothing

Input is a separate layer from rendering, so a live world with dead keys says nothing about your graphics. Click once inside the game area first: if the page scrolls when you press an arrow key, focus never reached the canvas. Then check whether a text field, chat box or overlay is capturing input — while a typing state is active the client ignores most key presses by design, which reads as a frozen game.

Confirm which input mode the client chose. It decides between the desktop, mobile and helicopter control sets from touch capability alone, so a desktop prompt on a phone is a real clue rather than a display quirk. The controls guide covers the current bindings, and the car-not-spawning checklist covers the vehicle and hold-timing cases in full.

Solo works but joining or sharing a race fails

Solo driving is local enough to survive a broken real-time layer, which is why this failure looks partial. The client needs socket.io from cdnjs.cloudflare.com for live sessions, so a blocked CDN produces exactly this shape: everything works until another player is involved.

Confirm the CDN request in the Network panel, then start one fresh session instead of retrying the same link. If a shared link opens the wrong world or nobody can join, the race-link checklist lists what to record, and the unable-to-join guide separates a session problem from a connection problem.

The page or sign-in will not open

If the browser shows its own error page, no game code ran at all, so nothing above applies yet: check the connection, then open hop.earth in a normal tab rather than an embedded player or an in-app browser. In-app browsers differ in storage rules and permitted scripts, and they can hide touch events, which changes how the client configures itself.

A private window is a useful comparison, not a guaranteed fix. Sign-in failures need their own check: confirm the current official interface shows the expected account state before retrying, and never enter credentials on a domain other than hop.earth. The download guide explains why an unofficial client or fixer is a worse idea than a slow first load.

When it is the service, not your device

Nothing on this page can see the game servers, and a checklist cannot prove an outage. The useful test is a clean comparison across two independent things: if the same failure appears in a second browser and on a second network, the device and the client are both ruled out. Record the time with its timezone, the device, the exact message and the last stage that succeeded, then check the official game and its official channels. The server-status checklist covers that distinction without guessing.