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
{{ message }}
This repository was archived by the owner on Apr 17, 2026. It is now read-only.
settings would be stored in a "context". the "active context" is where settings would be applied to when the mod receives packets.
i have three types of contexts in mind:
default context
active by default when joining a server
resets on world-load by default in order to prevent it's settings from persisting between servers on a proxy
when active, applies to whatever boat the client is riding (so, exactly how obu works right now)
resets when switching contexts by default (when you switch to default context, you get vanilla until you apply settings)
storage context
saves settings sent to it and can be re-applied later (like a form of custom modes)
takes priority over the default context when activated (so, one way to use a custom mode is to switch to a storage context that has already had settings sent to it)
can copy it's settings to another context (this would be the other way to use "custom modes". useful for the next type of context)
switches back to default context on word-load by default to prevent the proxy issue.
has a short string name (256 bytes max, maybe) provided by the server when creating it and used to activate it afterwards
server can query existing storage contexts
entity context
specific to one boat uuid
sidesteps the proxy issue, the server being switched to wouldn't have the same boat entity.
saves settings to the boat entity, doesn't need to be active for them to apply.
takes priority over other two context types (if a boat has entity context settings it will ignore the active default or storage context)
there would be only a handful of things not contained in the context, like:
world-load behavior
the list of storage contexts
interpolation compatibility (needs to apply to all boats if enabled)
so it may make sense to rename the current reset packets to something like "reset context", and provide a reset packet that sets these to their default values as well
settings would be stored in a "context". the "active context" is where settings would be applied to when the mod receives packets.
i have three types of contexts in mind:
there would be only a handful of things not contained in the context, like:
so it may make sense to rename the current reset packets to something like "reset context", and provide a reset packet that sets these to their default values as well