Makes for less duplicated logic, easier modding and better split
responsibilities.
Differential revision: D3638
Closes: #5884
This was SVN commit r25139.
Wall turrets/towers have more HP & are cheaper than free-standing
towers, and have no build restriction distance. Their attack, while
limited, is still high when garrisoned, and this makes them awkward to
balance and is poor design in general.
This removes their attack capability entirely, and standardizes the rest
of their statistics.
Patch by: Nescio
Accepted By: borg-, wowgetoffyourcellphone, wraitii
Differential Revision: https://code.wildfiregames.com/D3706
This was SVN commit r25135.
Reverts D3404 / 3731886e2c, thus making economic technologies more
effective.
The lower values led to resource shortages in the late game.
Patch by: Nescio
Accepted By: borg-, chrstgtr, wowgetoffyourcellphone
Differential Revision: https://code.wildfiregames.com/D3703
This was SVN commit r25134.
Towers, unlike walls, palisades, and outposts, counted towards the
required Town Phase structures for City Phase. Given the requirement to
build 4 structures, this pushed players into making them.
This removes that, and lowers the requirement to 3.
Patch by: Nescio
Accepted By: ValihrAnt, borg-, wowgetoffyourcellphone, wraitii
Differential Revision: https://code.wildfiregames.com/D3686
This was SVN commit r25133.
This can give Iberian an edge at defensive play earlier, fitting their
civ theme.
Approved by: borg-, wowgetoffyourcellphone, berhudar
Differential Revision: https://code.wildfiregames.com/D3685
This was SVN commit r25132.
This new bonus makes the tech more predictable.
Cost has been reduced slightly.
Patch by: Nescio
Differential Revision: https://code.wildfiregames.com/D3671
This was SVN commit r25131.
All foundations now have a resistance of 1 Hack, 1 Crush, 10 pierce.
Patch by: Nescio
Differential Revision: https://code.wildfiregames.com/D3600
This was SVN commit r25130.
The early-game cavalry rush was overly nerfed in A24 with longer train
time, slower speed, and the need for stables.
This rolls that back slightly by reducing train tim from 16 to 15, and
increasing the movement speed of ranged cavalry from 15 to 16.
Patch by: borg-
Differential Revision: https://code.wildfiregames.com/D3664
This was SVN commit r25129.
Was previsouly bumped to 3 in A24.
Patch by: borg-
Approved By: ValihrAnt, chrstgtr, wraitii
Differential Revision: https://code.wildfiregames.com/D3666
This was SVN commit r25128.
Fixes:
- A logic issue in the attack name tooltip.
- A missing context in the status effects tooltip
Patch by: nwtour
Reviewed By: wraitii
Differential Revision: https://code.wildfiregames.com/D3745
This was SVN commit r25127.
Since siege engines are not capturable anymore, since d583048690.
Fixes: d583048690.
Differential revision: D3742
Reviewed by: @Nescio
This was SVN commit r25124.
While they often look alike, their behaviour is totally different.
This split has some implications:
- There are now separate auras for garrisoning and turrets.
- Entities can now have both turret points and garrison slots,
independent of eachother.
In general previous behaviour is maintained as much as possible.
Differential revision: D3150
Comments by: @Nescio, @wraitii
Tested by: @v32itas
This was SVN commit r25123.
Allows for easier differentiation. No values were changed in this patch.
Differential revision: D2886
Comments by: @Angen, @borg-, @Stan, @ValihrAnt, @wraitii
This was SVN commit r25122.
- Removed some useless comments.
- Don't assume an item only has either a tech or a unit in
ProgressTimeout.
- Don't initialise boolean values (refs. #5979).
Differential revision: D3739
Comment by: @wraitii
This was SVN commit r25119.
Previously this was only done for technologies.
The Viewer tries to determine an appropriate civcode from a passed
template,
however trainable gaia-animals have a template-assigned civ of `gaia`
(and
technologies don't have one at all).
The behaviour of the Viewer isn't changed by this commit: it will still
prefer
whatever civ is set within a template before falling back to the passed
civcode.
However, trained gaia-animals now have something to fall back to,
permitting the
appropriate build list (the list of buildings that train the animal) to
be
displayed.
This was SVN commit r25110.
This is the same commit as 4bb31f084e, reverted in 5d1899785a. Noted
issues were fixed.
Partial revert/fix of 2f19cf86d3 and 2567fee329.
Before this diff, it was possible for a mod containing a cache/ or a
config/ folder to get written to incorrectly.
The issue is VFS can map multiple directories to one 'virtual' path, for
reading mods. However, writing data is problematic: which path to
choose?
The only viable solution is to use a path relative to the highest
priority directory encountered in the VFS path, or write paths could be
'hijacked' by lower-priority mods.
This fixes these issues by:
- Adding a new lookup mode ('Real-path') that explicitly picks the real
path relative to the highest-priority subdirectory in the VFS Path.
- Preventing overwriting a real directory with a lower priority one in
general.
- Revert c0c8132dd4's GetRealPath change, re-introducing the function as
GetOriginalPath.
This also cleans up some duplication that led to empty mod folders in
the user mod path, and cleans up loading the 'user' mod.
It also makes it explicit that a directory must be passed to Mount().
Note that the new 'realpath' lookup can still be somewhat complex with
many mount points at various hierarchy levels, but it is at least
predictable/deterministic without having to be careful about populating
order.
Fixes#2553
Differential Revision: https://code.wildfiregames.com/D3728
This was SVN commit r25107.
Partial revert/fix of 2f19cf86d3 and 2567fee329.
Before this diff, it was possible for a mod containing a cache/ or a
config/ folder to get written to incorrectly.
The issue is VFS can map multiple directories to one 'virtual' path, for
reading mods. However, writing data is problematic: which path to
choose?
The only viable solution is to use a path relative to the highest
priority directory encountered in the VFS path, or write paths could be
'hijacked' by lower-priority mods.
This fixes these issues by:
- Adding a new lookup mode ('Real-path') that explicitly picks the real
path relative to the highest-priority subdirectory in the VFS Path.
- Preventing overwriting a real directory with a lower priority one in
general.
- Revert c0c8132dd4's GetRealPath change, re-introducing the function as
GetOriginalPath.
This also cleans up some duplication that led to empty mod folders in
the user mod path, and cleans up loading the 'user' mod.
Note that the new 'realpath' lookup can still be somewhat complex with
many mount points at various hierarchy levels, but it is at least
predictable/deterministic without having to be careful about populating
order.
Fixes#2553
Differential Revision: https://code.wildfiregames.com/D3217
This was SVN commit r25104.
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.
FindWalkAndFightTargets is used during attack-walk (and a few other
situations) to find new entities to attack. This function can be a bit
slow, taking large chunks of time during battles.
This optimises it by assuming that one of the surrounding unit will
match preferred criteria (which, for most soldiers, are 'Human'), thus
returning the first attackable entity. In the worst case, it should
still be slightly faster than the current code.
Differential Revision: https://code.wildfiregames.com/D3446
This was SVN commit r25102.
- 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.
The NetServer stored a complete copy of the game Init Attributes, which
it sent to new clients on updates from the controller. This worked well,
but prevents incremental updates and other unrelated messages from being
sent.
This changes the system so that:
- in PREGAME state, the server does not update its copy of the game init
attributes
- the server forwards game setup messages from the controller to all
clients
- Joining clients get a full copy of the Settings, when joining, from
the controller (this is a js-driven behaviour - other situations might
not need do it).
- Make the StartNetworkGame message take a copy of the final init
attributes, to ensure synchronization (and simplify some logic).
In practice, this:
- makes it possible to send different types of gamesetup messages (this
introduces two: a regular update and the full 'initial-update' for new
clients).
- moves some C++ hardcoding into JS - here in essence the PREGAME server
state is now init-attributes-agnostic.
- does not change much for readiness control - the server already needed
to force a change at game start to set random elements.
Note that the loading page is currently still receiving the 'local' game
attributes, which assumes that all clients are correctly synchronized
(they should be).
Refs #3806, #3049
Differential Revision: https://code.wildfiregames.com/D3714
This was SVN commit r25099.
Improve the hotkey translations. This adds them to messages.json for
translation, closing the work from 09ad8bfbe5
Refs #5867, refs #5996
Differential Revision: https://code.wildfiregames.com/D3641
This was SVN commit r25097.
Fixes dc18d94030
- Player assignment still had some trouble. This cleans things up by
moving a little more logic in the controller & fixing other usage.
- As a consequence, in MP, if the host swaps two player, the change
will take a few frames to register. It shouldn't be too much of a
problem in practice.
- Fix issues with AI being assigned to player slots for joiners.
- Fix issues with similar color not being correctly picked when swapping
a map.
- Fix issues with rating & locked team settings.
Reported by: langbart
Differential Revision: https://code.wildfiregames.com/D3723
This was SVN commit r25096.
This helps to see compatible mods in the list, which can get a bit long.
For incompatible mods in disabled section use gray colour.
For incompatible mods in enabled section use red colour (what can happen
when using arguments to start the game or they can be in config file).
Add option to filter compatible mods, this does not affect enabled
section, because if there is incompatible mod, it is error and it needs
to be always visible.
Add function recomputeCompatibility and g_ModsCompatibility to avoid
recomputing aredependenciesmet when coloring mods, because every column
is colored separately.
Disable enable mod button if mod is incompatible.
Remove all dependencies met messages as they are now replaced by this
mechanism.
fix getSelectedModUrl in process
Differential revision: D3687
Fixes: #6053
Tested by: @Freagarach
Comments by: @vladislavbelov
This was SVN commit r25095.
All functionality in applyFilters is handled by displayModLists and
modSelected functions.
This is also fixing issue of triggering selected event on the same list
multiple times and not updating mod description and buttons when
applying filters.
Differential revision: D3722
This was SVN commit r25094.
Do not check for undefined when result is returning undefined or the
variable and nothing else is done.
Dont create variables when might not be used or are returned without
other usage after.
Dont call get with same parameter more than necessary.
Differential revision: D3652
Comments by: @Freagarach
This was SVN commit r25093.
Players could not be assigned beyond the first N slots.
Reported by: langbart
Differential Revision: https://code.wildfiregames.com/D3721
This was SVN commit r25091.
Allows modders (and us) to just add an IID to the array and ensure the
`Mirage()`-function to exist in the respective component.
Differential revision: D3713
Comment by: @wraitii
This was SVN commit r25090.
Moves the functions that define the properties/functions to mirage to
their respective components, making it easier for modders to know their
existence and to modify.
Closes: #5985
Differential revision: D3695
Comments by: @wraitii
This was SVN commit r25089.
Disabled technologies & templates are not really gamesetting concerns,
since they are map-specific and de-activating these generally does not
make sense.
Starting technologies is unused and not the correct granularity level
for game setup.
Triggers do a better job of specifying these things on a per-map basis
(in fact, some maps already use triggers for that).
Changes:
- StartingTechnologies was used by the cart sandbox and is simply
removed.
- DisabledTechnologies was used by Polar Sea RM, which already had
triggers -> into triggers.
- DisabledTemplates was used for the Ptol Lighthouse on a few maps ->
since we changed the ability to "a lot of range", it's no longer OP on
these maps and the restriction is simply lifted.
- DisabledTemplates was used on Death Canyon Invasion Force -> into
triggers.
Differential Revision: https://code.wildfiregames.com/D3712
This was SVN commit r25088.
Which were autofixable, with slight modifications.
Not done are the slightly more complex changes.
Refs. #5524
Patch by: @Krinkle
Differential revision: D2279
Comments by: @elexis, @Stan
Reviewed by: @wraitii
This was SVN commit r25087.
Issues from dc18d94030 fixed:
- The AI config page does not work
- Player Color/Civ/Team did not reset when switching out of Scenario,
which locked the setting
- Player color had weird issues with resetting when changing map too.
- Pop Cap could not be changed.
- Explored/Revealed were swapped in the game description (this was
actually fixed at some point in the original diff then reverted).
Reported by: Submariner and langbart
Differential Revision: https://code.wildfiregames.com/D3715
This was SVN commit r25084.
The initial settings for a game, used to create the map in RM & tosetup
the simulation, are named InitAttributes in the C++, but generally
referred to as GameAttributes in the JS GUI. This renames the latter to
the former to avoid confusion, since these settings are immutable once
the map starts, so InitAttributes is more accurate.
Differential Revision: https://code.wildfiregames.com/D3705
This was SVN commit r25083.
Redo 9f27f0eed8. Now! with not broken serialisation :D
Use a map that stores the functions, instead of them being part of the
Mirage component.
Doesn't need to initialise the variables anymore (refs. #5979).
Saves the mirages in a global to allow (de)serialisation.
Only assign values on Init, not on Construction (to allow
deserialisation).
Refs: #5985
Differential revision: D3702
Comments by: @wraitii
This was SVN commit r25079.
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.
HEAL can infinite loop: if the HEAL.APPROACHING:MoveTo call fails, the
unit will fallback to FINDINGNEWTARGET, which looks for new targets to
heal, which can loop around.
In #6106, the cause was that the target was not visible despite the
order being given (presumably a rangemanager/los incompatibility issue).
When MoveTo() fail, orders usually call FinishOrder as that's
irrecoverable.
Further, GATHERING/COLLECTINGTREASURE also did not FinishOrder - there,
we do want to consider new resources if the target is e.g. unreachable,
so add an explicit check for AbleToMove.
Reported by: moiman
Reviewed By: Freagarach
Fixes#6106
Differential Revision: https://code.wildfiregames.com/D3689
This was SVN commit r25075.
The "GARRISONED"-state was quite strange, for entities being garrisoned
can just as well perform other tasks (see e.g. turrets).
Also, the need for keeping a "garrison" order on the stack is removed.
Fixes: #6022
Differential revision: D3656
Refs. #6081
This was SVN commit r25069.
Use a map that stores the functions instead of them being part of the
Mirage component.
Means that a lot doesn't need to be inited now (refs. #5979).
Ticket: #5985
Differential revision: D3694
Comments by: @wraitii
This was SVN commit r25068.