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.
Check for existence explicitly in the lobby GUI.
It would probably be better to not trigger errors in the cache
laoder/JSON code but instead print at the caller, depending, but that
requires changing a lot more code.
Reported by: Asger
Fixes#5988
Differential Revision: https://code.wildfiregames.com/D3506
This was SVN commit r24821.
This grid-based system allows browsing all available maps at a glance,
encouraging more diversity and making it nicer to pick a map.
Moves the mapCache and the map filters controller to the gui maps/
folders, and include that folder where it is used, instead of them being
in common/ or the gamesetup.
Comments By: Freagarach
Patch By: Nani (reworked by elexis then wraitii)
Fixes#5315 (though further work, such as proper scrolling, would be
nice).
Differential Revision: https://code.wildfiregames.com/D1703
This was SVN commit r24459.
2020-12-27 15:26:19 +00:00
Renamed from binaries/data/mods/public/gui/common/MapCache.js (Browse further)
