Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cached ship images are not redrawn when a player changes their sails #1

Open
noodlebox opened this issue Jan 19, 2024 · 0 comments
Open
Labels
bug Something isn't working

Comments

@noodlebox
Copy link
Owner

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.

@noodlebox noodlebox added the bug Something isn't working label Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant