This happens because, for simplicity of implementation, cached ship images are never redrawn during a session. They're also never discarded, so could potentially accumulate undesirably if many unique players are seen within a single session. As a workaround, anything starting a fresh session (by reloading, docking, or hitting the Anchor button) will clear the cache.

As the cost of fully redrawing a ship is not excessively high, we could avoid ever showing the wrong ship details by simply invalidating the cache on any event that could result in a new configuration. When a player's sail preferences are updated (or a player undocks, possibly after acquiring another lei at a new island), the server sends an entity message (e:{"<id>":{...}}), with the entity object's new sail settings in Entities[<id>].config.colors and lei accumulation in Entities[<id>].config.progress.

Unfortunately, entity messages can be quite large if they include all of the local player's data, with up to 150kb of fish data for the pescadex in fishCaught. Parsing this can take multiple server ticks (during races, no less), and as we can't easily remove or replace the existing socket message handler, it's probably best not to create an additional one that duplicates this work by parsing entity messages again.

We should probably invalidate the cache whenever a player disconnects or docks at the very least, where the server sends a disconnect message (x:<id>), to avoid letting the cache grow without bound. Or to avoid adding another socket message handler at all, it could be eagerly invalidated during the render loop whenever a ship would be culled for being off-screen, or based on some additional stored metadata.

Because of the cost of parsing entity messages required to do it "correctly" and the low impact of this issue, I didn't worry about handling it before, but it wouldn't hurt to add some functionality to limit the size of the cache if I ever end up cleaning up that part of the code.

During races, the local player entity's object gains some extra properties that aren't used by the stock UI:

Properties

• keyState contains a bitmask for player input. This is only updated by the server when hitting flags, so it contains the input recorded by the server when the most recent flag was hit.

• raceId is a UUID unique to each race attempt.

• raceTimes is an array of nanosecond-precision timestamps for each race waypoint in the format, [<sec>, <ns>]. Both values are integers, with the first measuring seconds since some epoch (probably server start) and the other measuring nanoseconds in the range, [0, 1e9). A timestamp for the final waypoint is never received, but could be inferred from the final time given in the race results message (m:{type: "race_results", ...}).

• raceKeystrokes is an array of timestamp/keyState pairs in the format [<t>, <keyState>], where <t> is a timestamp the same format as in raceTimes.

• startConfig is an object containing the keyState and position/velocity data at the start of the race, but unfortunately contains the value for y in the place of x. These values should otherwise be identical to those given in the first message containing this property, so the correct values could be substituted from there.

Feature ideas

Split times

The best segments of each race could be recorded based on raceTimes for more fine-grained live feedback during races, similar to a speedrun overlay.

Ghosts of previous trials

With some adaptation of the existing prediction code, we could render ghosts of previous trials (by raceId) based on the data from raceKeystrokes and startConfig (correcting for its error mentioned above). These could be used to compare live performance against our own best time or to see a visualization of many attempts.

Other notes

keyState and raceKeystrokes could also be used to help verify whether our earlier predictions were in sync with server ticks or for creating initial routes in the path editor.

One major issue is that some entity messages (including the specific ones we'd want to check during races) contain all player data, including up to 150kb of fish facts in fishCaught. Parsing this is slow (multiple server ticks) and we may not want to exacerbate the problem during races by duplicating the work. There may be some other way to grab this data in a timely manner before it's deleted without adding excessive processing cost.