Commands, Permission Groups, Player Statistics, Reports, Roles, Scenario,
Server UPS and Module Utilities get a readme covering their config,
permissions, commands, web pages and Lua and Node API.
The existing readmes are brought up to date: Auto Restart now that
clusterio marks a restart after a plugin install, Discord Auth gets the
code timeout, command aliases and its Lua API, and the GUI guide says what
the plugin is and has its toolbar examples and an iterator name fixed.
The main readme gets a Plugins section listing each plugin by name and
package with a one line description.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
exp_reports, exp_roles and exp_groups wrapped the json they send to Lua in
a fixed [=[ ]=] long bracket. A report reason, role name or group name
containing ]=] closed it early and the rest ran as Lua through /sc. Any
player can make a report, so any player could run code on the server.
Use the next level the json does not contain, like the other plugins do.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The plugin is now exp_player_statistics (@expcluster/player-statistics),
with the module, global, permission, route and database directory
renamed to match. The exp-statistics locale section keeps its name.
Every statistic is tracked unconditionally, so the enable flags are gone
from config.lua. Playtime and JoinCount are no longer counted in game:
clusterio already keeps online time and joins for each user, so the
controller fills them in from the user when a player's totals are
requested, and the web page does the same from the user list. They are
not stored or adjusted by the plugin.
The web table has a column picker, a multiple select with check boxes,
Select all and Reset buttons, showing "N statistics selected". The
choice is kept in local storage. The user page shows the statistics of
the player in a grid like the core player stats.
The readme statistics table drops its second title and uses the short
time format.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The tab listed the legacy player data, its required, settings and misc
groups and the data saving preference. None of that is synced or
relevant any more, so the tab is now Statistics and lists the totals
from exp_statistics in display order.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Remove the tracking and config from exp_legacy along with its
exp-statistics locale, which now ships with exp_statistics.
The player stats GUI stays in exp_scenario and reads the new module. It
uses the online player dropdown from exp_scenario's elements, so moving
it would make exp_statistics depend on exp_scenario, and its
exp_scenario.gui.playerdata permission is already in the seeded roles.
The readme data tab shows the statistics from the new module above the
remaining PlayerData.Statistics children, which is only LocalLanguage
now.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Player statistics move out of exp_legacy into their own plugin, with the
totals kept on the controller instead of the PlayerData datastore, which
was never synced anywhere.
The lua module tracks the same statistics with the same rules. Gains are
kept per player as unsent in storage and sent over IPC every 5 minutes
for every player with changes, and for one player when they leave. Sent
values move into the totals the controller gave when the player joined,
so get() is the total on every server either way.
Nothing is resent. The instance plugin sends everything left when the
server stops and drops anything unsent when it starts. A leftover can
only come from a save made before it was sent, such as the autosave
loaded after a crash, so dropping it loses a few minutes at worst but
never counts twice.
The controller adds the deltas to a record per player name in
database/exp_statistics/players.json. Instances fetch a player's totals
on join and hand them to lua over rcon. The web UI gets a sortable table
of every player at /exp_statistics, behind exp_statistics.view.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Add a community_details feature for the community name and links
The community name, Discord, website, status, GitHub, and Patreon links
lived in exp_legacy/config/server_detail.lua, so changing them meant
editing the scenario. They are now the community_details feature and can
be edited from the Scenario Features page.
Chat auto reply, help bubbles, and the readme read the live config
instead of copying the values when the file loads, so an edit shows up
without a restart. Help bubbles store the location name in their task
and build the messages each cycle; the readme tab tooltip can be a
function which is called when the readme opens.
Every feature gets an enabled switch from the framework. There is no
sensible meaning for a disabled community name, so the values are
always used and the feature description says the switch does nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Move greetings to exp_scenario and drop preset colours
The greeting reads the community name and Discord link from the new
community_details feature, which exp_legacy can not depend on, so it moves
to exp_scenario/control/greetings.lua along with its commands and
locale. The custom message still lives in PlayerData for now.
The hardcoded per-player join messages in config/join_messages.lua are
removed with their fallback, as are the preset player colours. Player
sync already restores the colour of returning players, so new players
keep the colour Factorio gives them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The toolbar order, favourites, and open panels were saved into
exp_legacy's PlayerData, which was never synced, and the file doing so
was no longer loaded. When a player leaves, the lua side now sends
Gui.toolbar.get_state as json compressed with helpers.encode_string,
and the controller stores the string on the player record.
When the player joins again the instance plugin sends the stored string
over rcon to exp_scenario.player_settings.receive_toolbar, which
decodes it and calls Gui.toolbar.set_state. exp_gui builds the toolbar
in on_player_joined_game, so it exists by the time the rcon arrives.
A string which does not decode, or a state naming buttons which no
longer exist, is logged and ignored rather than raising in the game.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
exp_legacy recorded each player's locale in PlayerData statistics
which nothing read. The lua side now sends one ipc event with the
player's locale when they join and when they change language, the
instance forwards it, and the controller stores it on the player
record.
The Scenario section of the user page shows the language by name with
a flag made from regional indicator symbols. Locales with a region use
it directly, the rest map to a country through a small table covering
Factorio's locale list. Arabic, Catalan, Basque, and Esperanto have no
single country and get no flag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Join messages were stored in exp_legacy's PlayerData, which nothing
ever synced. The controller now keeps a players.json datastore of
per-player settings keyed by player name, starting with the join
message, and saves it on the save and shutdown hooks. Records with
nothing set are removed.
When a player joins, the instance plugin fetches their record and
prints the message to everyone over rcon in the player's colour, so no
lua is needed to show it. The in-game /set-join-message and
/remove-join-message commands send ipc which the instance forwards to
the controller; /set-join-message without a message asks the instance,
which prints the stored message back to the player.
Greetings is now a feature. Disabling it stops the greeting, the
commands, and the printed join messages. The private greeting with the
community name and Discord link is shown to every joining player, even
those with a join message, since one is a welcome for the player and
the other an announcement to everyone else.
Two controller permissions cover the web interface:
exp_scenario.join_message.set for your own message and .set_other for
anyone's, checked against the requesting user the same way
exp_discord_auth checks unlinking. The seed grants them to Supporter
and Moderator alongside the in-game commands. The user page gets a
Scenario section showing the message with an edit button for users who
may change it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The greeting reads the community name and Discord link from the new
community_details feature, which exp_legacy can not depend on, so it moves
to exp_scenario/control/greetings.lua along with its commands and
locale. The custom message still lives in PlayerData for now.
The hardcoded per-player join messages in config/join_messages.lua are
removed with their fallback, as are the preset player colours. Player
sync already restores the colour of returning players, so new players
keep the colour Factorio gives them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The community name, Discord, website, status, GitHub, and Patreon links
lived in exp_legacy/config/server_detail.lua, so changing them meant
editing the scenario. They are now the community_details feature and can
be edited from the Scenario Features page.
Chat auto reply, help bubbles, and the readme read the live config
instead of copying the values when the file loads, so an edit shows up
without a restart. Help bubbles store the location name in their task
and build the messages each cycle; the readme tab tooltip can be a
function which is called when the readme opens.
Every feature gets an enabled switch from the framework. There is no
sensible meaning for a disabled community name, so the values are
always used and the feature description says the switch does nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The controller and instance plugins are init functions with closures.
The controller batches refreshes with setMany and deleteMany, and the
instance gates updates on its status instead of a started flag.
short_name is now display_name. New always_on_top field sorts servers
first in get_servers. The record carries has_password from the game
password in factorio.settings, never the password itself, and the
description falls back to the one in factorio.settings. A controller
welcome is used when the instance has none, and the readme falls back
to a default welcome from the locale.
Lua gets is_synced for connect.lua. The readme passes an empty detail
instead of nil to the join tooltip so the player count stays in __2__,
restores the Password status, shows the welcome title as a centered
label and shortens long descriptions with the full text as a tooltip.
The Lua tests assert the lookups they index, which fixes the lint.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The controller keeps a record per instance with its name, mod pack,
Factorio version, players online, status and address, and the instance
plugin pushes the list into lua over rcon. The readme and the connect
commands read it through modules/exp_server_list, so expcore/external
and its hardcoded server fallback are removed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Add exp_discord plugin for Discord login and account linking
Players log in to the web interface with Discord through OAuth2 with the
identify scope, so no bot token is needed. After logging in they get a
code from the login page and type /link-discord <code> in game to link
that Factorio account. One Discord account can hold up to
exp_discord.max_accounts Factorio accounts (default 3), and linking a
name moves it off any other Discord account.
Sessions and link codes live in memory on the controller plugin, the
links are stored in database/exp_discord/accounts.json. The user page
shows the linked Discord account and lets the user, or anyone with
exp_discord.link.delete, unlink it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Link Discord from the user page and document the setup
The user page gets a Link Discord button. It asks the controller for a
one-time ticket bound to the logged in user, then goes through the
authorize route with it. The callback links the Discord account to that
user directly, without the in-game code, and goes back to the user page.
The link flow always shows the Discord consent screen.
The README covers registering the redirect URL and the config.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Address review of the Discord plugin
The plugin is now exp_discord_auth, so later Discord plugins can sit
next to it. Config keys, permissions, routes and the Lua module moved
with it, and the Discord redirect is now api/exp_discord_auth/callback.
The controller registers its handlers and routes in the constructor and
uses the express types, the instance plugin is a closure, and the Lua
commands file returns its commands. The get and unlink responses carry
the controller url so the in game messages can name the website.
The login form asks the new status route whether Discord is configured
and shows the error straight away instead of a button that fails. The
button is full width like the link button, and a "Not you?" link next
to the Discord name replaces the separate switch account button.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The plugin is now exp_discord_auth, so later Discord plugins can sit
next to it. Config keys, permissions, routes and the Lua module moved
with it, and the Discord redirect is now api/exp_discord_auth/callback.
The controller registers its handlers and routes in the constructor and
uses the express types, the instance plugin is a closure, and the Lua
commands file returns its commands. The get and unlink responses carry
the controller url so the in game messages can name the website.
The login form asks the new status route whether Discord is configured
and shows the error straight away instead of a button that fails. The
button is full width like the link button, and a "Not you?" link next
to the Discord name replaces the separate switch account button.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The user page gets a Link Discord button. It asks the controller for a
one-time ticket bound to the logged in user, then goes through the
authorize route with it. The callback links the Discord account to that
user directly, without the in-game code, and goes back to the user page.
The link flow always shows the Discord consent screen.
The README covers registering the redirect URL and the config.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Players log in to the web interface with Discord through OAuth2 with the
identify scope, so no bot token is needed. After logging in they get a
code from the login page and type /link-discord <code> in game to link
that Factorio account. One Discord account can hold up to
exp_discord.max_accounts Factorio accounts (default 3), and linking a
name moves it off any other Discord account.
Sessions and link codes live in memory on the controller plugin, the
links are stored in database/exp_discord/accounts.json. The user page
shows the linked Discord account and lets the user, or anyone with
exp_discord.link.delete, unlink it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The instance plugins of exp_groups, exp_reports, exp_roles, exp_scenario
and exp_server_ups, and the controller plugins of exp_reports and
exp_scenario, were classes only to hold their handlers. They are now
init functions with closures, like clusterio's own plugins.
The exp_roles and exp_groups controller plugins stay classes because
exp_scenario reaches their datastores through get(controller).
AutoRestart stays a class because its tests step check() with a fake
clock.
Tests spy on handle() and the hooks to call the handlers. The reports
webhook tests stub fetch instead of replacing postWebhook, and the
feature reconcile test writes the stored records to disk before start.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Inventory sync already stores the player colour, tag, quickbar and alt
view (game view settings), so the legacy alt-view, quickbar and tag
modules and the colour persistence are removed along with
/save-quickbar and its quickbar presets.
The /tag, /tag-color and /tag-clear commands move to exp_scenario and
write player.tag directly, which inventory sync then carries between
servers. /tag-color reads the current text back out of the tag, so it
now needs a tag to be set first. It also used to concatenate the colour
table into the tag and error, it now formats it as rich text.
player-colours keeps giving new players their preset or a random
colour on creation, inventory sync replaces it with the stored one for
anyone who has played before.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Each plugin class now has a private constructor and a static async
fromContext(context) that loads its datastores, constructs the instance
and attaches its handlers and hooks. This replaces the public constructor
followed by init(), and AutoRestart's start().
Datastores are loaded before construction and passed to the constructor,
so the definite assignment assertions on them are gone. Tests build the
plugins through fromContext and pass a wrapped logger in the context
instead of overwriting plugin.logger before init().
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
- The instance sends every value of a feature, defaults included, so
update_config is one loop which sets each field and compares. The
stored table is the last set of values, and _apply is gone.
- values_equal compares table sizes before the contents.
- Protected entities are registered with register_on_object_destroyed
and forgotten in on_object_destroyed, which covers every way an
entity can go. The four removal handlers and the validity checks are
gone. Entities destroyed while the feature is disabled are swept when
it is enabled again. Saves from before the registrations table get it
through the Storage on_init callback.
- Spawn area applied the water offset twice and the pattern offset
never. The pattern tiles now move with the entities above them.
- pruneFeatureValues reads a validation result instead of catching an
error, and FeaturesPage hands its pending state and unsaved bar to
helpers.
- Shorter comments throughout.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- 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>
- The page waited for nothing, so before the subscription delivered
the records every feature looked enabled with its defaults, and an
Apply in that window would have written that state. It now shows a
spinner until synced, like the role page.
- Values stored for a setting which was since renamed, removed, or
changed type made every later save of that feature fail validation.
The controller now reconciles the stored records with features.ts on
start: stale values are dropped with a warning, records of removed
features are deleted, and new features get their defaults.
- update_config no longer stores overrides for unknown paths, so a
stale key is warned about once instead of on every load.
- The armor and gun inventory handlers of nuke protection are new to
this branch and asserted on get_inventory, which is nil without a
character. They return instead.
- The AFK check ran every 30 minutes while afk_minutes and kick_minutes
can be set as low as 1. It runs every minute.
- sameValue lives in features.ts and isDefaultValue uses it, and the
custom input branch of FieldInput is a single narrowed check.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Feature.to_set made every feature turn its config lists into sets on
each lookup, which is work the framework should do once. Sets are now a
field type of their own. Feature.set{...} declares one, the controller
sends a list, and _apply converts it when the override is applied, on
load and on update alike. Features index the config directly, and
to_set and its cache are gone.
Lists are explicit too. Feature.list{...} declares one, where before
any table of strings, and any empty table, counted as a list. Untagged
tables with string keys are nested sections, and other tables can not
be overridden. Feature.optional uses the same marker as list and set.
On the web side a string list can no longer name an input component,
so the cast that made one look like an object field is gone.
Co-Authored-By: Claude Opus 5.5 <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>
phidias
Cooldude2606