Fixed. Your note "the bots are visible though but no players" is what cracked it — that detail did most of the work.

The players were never missing. They were being thrown hundreds to thousands of pixels off-screen, so they were on the map the whole time, just nowhere near the camera.

When an update arrives late, the game guesses where you went next: it takes your last two positions, works out a speed, and coasts. It limited how LONG it coasted but never how FAST, and those multiply. Updates are timestamped when the SERVER receives them, and the network layer batches messages, so two updates sent 100-200ms apart often arrive 1-5ms apart still carrying a real 10-25 pixel step. That reads as 25x running speed. Coasting it puts a walking character 700px away, a jumping one 3,600px. The play area is 800x600, so they are gone.

Bots gave it away: they run on your machine and send a position every frame, so they never arrive late and never get guessed at. That also proved drawing, depth and animation were fine.

Straight with you: I caused this two days ago. A change to stop reprocessing players who had not moved was right in itself, but the duplicate updates it removed had been holding that speed at zero and masking the bug. The fix limits the coast to the distance actually seen between the last two updates.

I also fixed a second, unrelated way players could vanish: opening and closing the Cash Shop permanently hid everyone whose clothing had not finished loading.

Both are on develop for the next build. To retest: two players in one map walking, one jumping while the other watches, then one opening and closing the Cash Shop. Section A of the checklist is untestable until this works.

Correction — I marked this FIXED too early. Reopening it. My explanation above was wrong and I would rather say so than have you test against it.

I had a second pass check my own reasoning and it knocked the story down on two facts I then confirmed myself:

1. I claimed the network layer bunches updates together so badly that two sent 100-200ms apart arrive 1-5ms apart. It cannot. That batching only ever groups messages sent within 30ms of each other.
2. Because of that, the biggest movement it can compress is about 30ms worth — under 4 pixels at walking speed, not the 10-25 pixels my figures needed. So the "thrown 700 to 3,600 pixels away" number does not hold up.

I also had the bots backwards. Bots are not just simulated locally, they are kept out of the remote-player system entirely. So "bots fine, players missing" clears the drawing code AND points at the whole player-presence pipeline — a wider area than the movement smoothing I changed.

What I shipped is still worth keeping: the smoothing really was unbounded and is now bounded, which removes a genuine rubber-banding source. It is just not what makes players invisible.

The likely culprit is now something else I changed two days ago: when another player is first seen, if their update arrives without a position, the game silently drops them forever. It used to fall back to a default instead. Five different paths feed that code and all of them hide errors, so it fails invisibly.

I have added a log line there. Next time two people are on a map, if that message appears in the browser console (F12) it names the cause outright.

So: still open, still my fault, and now instrumented rather than guessed at. Sorry for the false alarm.

Correcting the record first: this was marked fixed once before and that was wrong, so I am being careful about what is actually proven here.

What was wrong: the game decided ONCE — at the moment you first entered a map — whether it had a live connection to the world server. If that check happened a fraction of a second before the connection finished settling, it wrote down "no connection" and never asked again for the rest of the session. Everything multiplayer hangs off that one decision: joining the map's room, receiving the list of who else is there, and broadcasting your own position. So you were invisible to everyone and everyone was invisible to you, on every map, until you reloaded. The bots kept showing because your own machine draws them and they never travel over the network at all — exactly the detail you reported, and it is what pointed at the connection rather than at drawing.

Why it hit you and not always: if you already have saved characters, the character screen appears instantly from a local copy without waiting for the connection, so it is easy to be standing in the world before the connection is ready.

What changed since the last answer: the game keeps checking instead of deciding once, and it now TELLS you. You will see a line in the chat log when the connection comes up, and another if it stays down. It also stops retrying so aggressively that it fights itself, and it stops retrying entirely once you leave the world.

What to re-test: two DIFFERENT accounts (two windows on the same account count as one player to the server and can never see each other). Stand on the same map both ways. Then deliberately break it: turn your network off for about six seconds while loading in, turn it back on, and confirm the chat line appears within about ten seconds and you both appear without a reload.

Still not done: nobody has confirmed any of this with two real players yet. That is the only thing that will close this.

Closing this — finally confirmed with two real players. The v43 test run verified that two players on the same map see each other move and jump with neither reloading, that nobody arrives invisible, that walking away and back shows the sprite disappear and reappear cleanly, and that no ghost copies are left behind. All passed. This ticket was marked fixed once before and that was wrong, so for the record: the cause was that the game decided ONCE at map entry whether it had a live connection and never asked again, and it now keeps checking and tells you in the chat log. One related problem is still open and tracked separately: closing a tab outright rather than logging out still leaves a ghost standing on the map.

Follow-up, no status change — this stays fixed, seeing each other works. But a related fault turned up afterwards and belongs on this thread: closing a tab OUTRIGHT rather than logging out left a ghost of you standing on the map, and that ghost is what made a following login look broken. A hard tab close only runs the save handler; it never leaves the room, and the engine event that would leave it does not fire on a tab close. The roster was then handed to everyone with no liveness filter, and the platform's own cache put the ghost back even after a sweep. Fixed now. It never showed in development because our local test server evicts a dead connection itself; the real one does not. Worth re-testing by closing the tab outright and having the other player watch you go.