You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 inEntities[<id>].config.colors
and lei accumulation inEntities[<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.
The text was updated successfully, but these errors were encountered: