Add split times and other info to race UI

[noodlebox]

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.