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
The `isSavedGame` attribute has been introduced in ea12766834. The
variable has been turned in a member variable in 3a6540110b this
occurrence was missed when rebasing.
Fixes: #8417
When loading a savegame more settings are loaded then normally. Thous
settings (such as TriggerScripts) can't be changed from the
matchsetting-screen.
With this commit the saved matchsettings.mp.json isn't overritten when
loading a savegame.
Fixes: #7632
Filtering the maps sometimes changes the selection. Also it's not
required to filter the maps as the setting is already selected and
frozen.
This reuses the code which is used by campains since there the map might
also be frozen.
Fixes: #7682
If a human player is set to “Removed” in Game Setup, leaves to the
main menu, and re-enters, they are auto-assigned back to the same
slot but still flagged as removed, triggering an instant defeat when
the match starts.
GameSettingsController::onLoad already reconciles **playerAI** against
current player assignments, but the analogous check for the new
**playerRemoved** setting was missing. The flag therefore survived
persisted-settings reloads.
This mirrors the existing AI-conflict logic and resets the flag
whenever a human player occupies the slot.
Bug reported by *elexis*.
`PlayerData` didn't contain the playerNames when serialized because they
should not be loaded when a new game is made. This lead to the issue
that client didn't receive the initial player names of saved games.
Now `fromInitAttributes` gets as a second parameter whether the
initAttributus are from persistent settings.
Defect introduced in b90280855f.
Summary:
The persistent settings have historically often led to bugs (see A26,
but that's far from the only example).
The trouble is that this usually leads to the game setup being
completely unusable, often requiring clearing the MatchSettings.json
file (or de-activating it in the settings if one knows that is there).
Furthermore, mods can make the persistentSettings take 'bad' values, and
in general this behaviour is prone to unexpected breakage and difficult
to defend against.
This wraps it in a try-catch block to ensure the game remains usable. It
still relays the error with a more useful error message.
Differential Revision: https://code.wildfiregames.com/D4794
This was SVN commit r27314.
Fixing issues in dc18d94030
Everyone make sure to delete savegames, saved campaigns an most
importantly your matchsettings.json's (regular alpha players won't
notice since there is a version check, but if you already have your
stuff at A26/svn, you will have some issues)
Reported By: elexis
Comments By: wraitii, Freagarach
Differential Revision: D4240
This was SVN commit r26393.
- Settings weren't sent to the server when mapfilters change.
- Because of ordering issues, the 'multiplayer' mapfilter would be
activated at the wrong time and things would go haywire.
- Likewise, selecting a non-default map with a non-default filter
wouldn't work well.
Fixes#6208
Differential Revision: https://code.wildfiregames.com/D4111
This was SVN commit r25731.
This allows switching to the gamesetup, with a harcoded map, from the
campaign screen. Lets player sets up a few things (e.g. their civ &
favorite AI), which can be convenient for some simple campaigns that
lack options.
Differential Revision: https://code.wildfiregames.com/D4039
This was SVN commit r25636.
This prints out a stack trace, which is quite helpful when debugging.
Also fixes an issue with stack trace not always being reported.
Differential Revision: https://code.wildfiregames.com/D3210
This was SVN commit r25365.
- Random lanscape option now works properly.
- Non-host clients now see the game attributes correctly in the loading
screen, including in particular the map name.
- AI bots are again translated.
- 'Cheat' setting is persisted correctly in MP gamesetup.
Reported by: myself, Freagarach, nwtour
Differential Revision: https://code.wildfiregames.com/D3841
This was SVN commit r25257.
Reintroduced in fa3b341b57, as I changed the execution order of onLoad.
This fixes the problem by explicitly handling this case, which should
avoid accidentally reintroducing the problem.
Differential Revision: https://code.wildfiregames.com/D3724
This was SVN commit r25103.
- rename 'Controls' class to 'Controllers' to avoid ambiguity and mimic
MVC lingo.
- rename GameRegisterStanza into LobbyGameRegistration, and make it
explicitly a controller.
- rename GameSettingsFile to PersistentMatchSettings & move it to its
own folder (since it could be reused independently of the controllers)
- remove the StartGameController & move `launchGame` to the
GameSettingsController (simplifies the control flow)
- the GUI Object "setupWindow" was actually the GameSettingsPage, this
is corrected.
- the LoadingPage was showing the GameSettingsPage -> in the current
code, it makes more sense to have both handle their own visibility.
- make the NetMessages class independent of other gamesetup logic, so
that it can be reused by other code. Remove the custom XML object.
Differential Revision: https://code.wildfiregames.com/D3719
This was SVN commit r25101.
Dunedan