SetFilterOptions
Options for `FilterManager.set`, controlling where the payload is written and whether the node is checked for support. | given | envelope | `validate` default | | --- | --- | --- | | nothing, registered filter | whatever the registry resolves | `true` | | nothing, unknown filter | `pluginFilters[name]` (flat) | `false` | | `plugin: true` | `pluginFilters[name]` (flat) | `false` | | `plugin: "some-plugin"` | `pluginFilters["some-plugin"][name]` | `false` | | `top: true` | `filters[name]` (top level) | `false` | Passing a routing option always wins over the registry, so an explicit envelope can be forced for a registered name too.
Signature
export interface SetFilterOptionsProperties
plugin?: string | true;Write the filter under `pluginFilters`: `true` places it flat, a plugin name nests it under that plugin (the shape the Lavalink spec defines for plugin filters).
top?: boolean;Write the filter at the top level of the payload, next to the built-in Lavalink filters — where a fork exposes its own filters. Hoshimi does not check which server it is talking to: whether a fork-specific filter is safe to send is the node's business, so pointing a player at the right node is the caller's. Registering the filter (scope {@link FilterScope.Core}) buys routing by name and a check against the node's advertised list, when the fork does advertise it.
validate?: boolean;Whether to check that the node advertises the filter (and installs its backing plugin) before writing. Only meaningful for registered filters — there is nothing to check an unknown key against. See the table above for the defaults.