Up to now `eslint-plugin-brace-rules` was used to enforce a common brace
style for JavaScript code. This plugin was however updated the last time
over 9 years ago and will be incompatible with ESLint v10, as that
[removes `context.getSourceCode()`][1], the plugin relies on.
To keep the eslint config working with ESLint v10, this replaces
`eslint-plugin-brace-rules` with the [`@stylistic/brace-style`][2] rule
from `@stylistic/eslint-plugin`, a package we already use.
While `@stylistic/brace-style` doesn't offer an option to format braces
in exactly the same way as before, the "allman" style seems to be the
one closest to the existing code.
[1]: https://eslint.org/blog/2025/11/eslint-v10.0.0-alpha.0-released/#removed-deprecated-rule-context-members
[2]: https://eslint.style/rules/brace-style
Split the gamesetup in two: the 'GameAttributes' part into gamesettings/
and the GUI/Presentation part in gamesetup/. This makes it easier to
separate the presentation from the data.
The immediate benefit is that campaigns & autostart scripts don't need
to load the gamesetup folder at all. This also makes it much easier for
any modder that would want to to change the GameSetup itself.
Each 'game attribute' is given a unique class extending GameSetting
(with a few exceptions), in charge of:
- 'Serializing' to the JSON-compatible 'InitAttributes' format, which is
used for persisted settings, network synchronization, map script
settings, hotloading.
- Deserializing from the same format.
- Watching for settings it depends on (such that e.g. unexploring the
map also unreveals it).
The GUI controls remain in charge of presenting the state accurately,
however they now directly subscribe to changes of the GameSettings for
update. The updating logic in general has been lightened on the GUI
side, making it more straightforward to know when something will update,
and reducing un-necessary computations (in theory - in practice, I
believe the gamesetup was already fairly good about this).
The 'Controller' class of the gamesetup have also been lightened, since
more responsibility now lies with GameSettings. In particular, this
include code to actually launch a game.
In general the GameSettings class is permissive - the GUI gamesetup has
tighter restriction for what the player can/cannot modify. This is
intended to give flexibility for campaign maps, which may want to change
arbitrary settings.
Further work would be useful, non-exhaustively:
- the setting of default values remains messy. They currently exist
somethings in GameSettings, sometimes in the GUI gamesetup, and in the
simulation itself (in case attributes are not set).
- the availability and 'lockedness' of settings remains a
work-in-progress.
- some attributes, like disabled technologies, should probably be
removed and triggers used instead.
- the Handling of AI and player-specific data could be improved.
- settings Persistence should follow its own path - not all settings are
worth persisting.
- GAIA settings are added simulation-side but not in the GUI, which is
confusing.
Thanks langbart & Freagarach for testing.
Follows the gamesetup rewrite in 34138a7764.
Refs #3049
Differential Revision: https://code.wildfiregames.com/D3243
This was SVN commit r25077.
