- Feature.register returns the config as a second value, so files
write `local feature, config = Feature.register(...)`.
- The lib is ExpScenario.Features and the instance class with its
fields sits on Feature._prototype, which is the __index, the same
shape as exp_commands.
- update_config only looks at values whose override was added,
removed, or replaced. _apply_field sets one value and returns it, so
the comparison happens while applying and the second loop only
raises. Overrides dropped from the previous set count as candidates
because the value reverts to its default.
- The `@setting name` tags are gone from the config comments.
- Protection is guarded as a whole instead of checking config.enabled
in one handler. The handlers also forget mined entities, so
get_entities and is_entity_protected now drop invalid references,
which also covers entities destroyed without an event. The list
getters are gone, the selection overlay builds its lists from
Protection.config.
- Chat and damage popups are one feature in control/popups.lua.
- ignore_admins and command_admin_only are removed, roles cover them.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Review points from Cooldude:
- Feature.register(name[, config]) is required again and returns a
feature object. Each feature has its config, its fields, and its
overrides, so one registry holds all the data. Only the overrides are
stored. On load each feature points at its own stored table again.
- The methods are feature:guard(lib), feature:update_config(enabled,
values), and feature:is_enabled(). Feature.get(name) looks up a
feature, and commands flag the feature object.
- update_config raises on_config_updated once per changed value, with
the feature name, path, old value, and new value. The gui refresh only
reacts to the "enabled" path.
- apply only sets values. on_apply is gone. Lookup sets built from
lists use Feature.to_set, which is cached by the list itself. A
replaced list gets a new set, so the sets are also correct after a
load. Protection exposes getters for its protected names and types.
Web: settings use small inputs, the same size as the config pages.
Fields are shaped like clusterio config field definitions. A field
with an inputComponent renders the component registered with the web
interface, so the role setting now uses core's role input, and other
plugin inputs can be used later.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Framework:
- Intervals are gone. Update periods are hardcoded on_nth_tick values
again, since nobody has needed to change them.
- apply is a single loop over the declared fields and logs a warning
when an override is invalid. receive_update also warns about
unknown keys.
- Nested tables are addressed as "section.key". Lists of strings can be
overridden. Features.optional declares a value with no default.
- Features.on_apply rebuilds values derived from the config, such as
lookup sets. It also runs during on_load.
exp_roles is assumed to be present:
- AFK Kick picks a role (active_role_id) instead of a custom check
function.
- Chat Auto Reply, Protection, and Nuke Protection no longer take a
permission as a setting.
New features, each chosen for an edge case:
- Discord Alerts: conditional handlers, and a command map that becomes
a list.
- Entity Protection: lists turned into sets at load, and bookkeeping
that must keep running while disabled.
- Nuke Protection: config keyed by defines, flattened to a banned items
list.
- Popups: one config shared by two control files.
- Spawn Area: nested sections, and settings that only apply when the
map is created.
Page: now laid out like the role page. It has a search across every
setting, one long list with a sticky sidebar to jump between sections,
and the enabled switch separated at the front of each header with
Reset to defaults on the right. Changed rows are highlighted, and a
bottom bar offers Revert and Apply. Role settings use a role picker and
lists use a tag select.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review feedback from Cooldude on the first version.
Features.register is renamed to Features.config, and guard also takes a
feature name so a feature without settings needs no config call.
Autofill uses this. Small configs now live at the top of the file that
uses them: death markers, mine depletion, station auto name, and
lawnmower. AFK kick and chat auto reply keep separate files because
they contain functions.
Periods no longer need a restart. A lib can list intervals, which map a
config key to a handler that runs every config[key] seconds. They are
checked once a second with a stateless tick check. AFK kick and death
markers use this and expose their periods on the page.
Guis: receive_update raises on_feature_changed, and control/features.lua
refreshes every player's gui when it fires. Autofill's toolbar button
checks Features.is_enabled, and hiding the button also hides its left
element. Quick actions refresh on the event too.
Commands: add_flags{ feature = ... } ties a command to a feature, and a
new authority denies it while the feature is disabled. The custom help
and quick actions already leave out denied commands. Lawnmower uses this
and is now added as a lib, so its destroy_decoratives handlers are
actually registered.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Features can now be enabled, disabled, and configured from the web UI
while the game is running, without editing Lua files. The first five
features covered are AFK Kick, Chat Auto Reply, Death Markers, Mine
Depletion, and Station Auto Name.
Lua side: module/features.lua holds each feature's defaults, keeps the
overrides from the controller in storage, and patches them onto the
config table in place. Features.guard skips a feature's handlers while
it is disabled. The five config files move from exp_legacy into
exp_scenario/module/config and their control files now read config at
runtime instead of deciding at load which handlers to register. AFK
Kick times are now in minutes.
Controller side: features.ts lists the editable settings and their
defaults. Overrides that differ from the default are stored in
exp_scenario/features.json and guarded by the existing
exp_scenario.config.view/edit permissions. The instance plugin sends
them over rcon on start, on every change, and again after the
controller restarts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
