Previously it was made so that "template data" was a sort of super type
of "entity state" and that the former could always be replaced by the
latter. Using this we can simplify some code passages by removing
GetTemplateData calls and using the entity's state directly instead.
The array was wastefully created and passed to the GUI every single
turn for every single selected unit.
Since the GUI defines the (selectable) stances' names and tooltips, it
already knew them anyway, so they don't even need to be passed from the
simulation to it in the first place.
GetEntityState is a performance-critical function in the GUI when a
large number of units are selected. The goal of this patch is to
increase the efficiency of it without modifying the returned states
visible to rest of the GUI in any way (it renames a few properties of
entities states or moves them around, but the information they contain
and the way to access it remain the complete same)
As explained the comments, certain parts (the template data) of an
entity state are "predictable" and can be reused between entities with
the same template.
What one has to account for, however, is that values of the template
data can be modified. This happens on two different levels:
Firstly, player-wide modifications, which apply to all entities owned
by that player. This includes stuff like bonuses from researched techs,
civs bonuses, team bonuses. And secondly, entity-local modifications,
which apply to individual entities. This includes buffs or debuffs from
status effects or auras (of other entities).
So we can construct a whole entity state by first just computing the
dynamic state (stuff like current hitpoints, which differs from entity
to entity) and then adding the (potentially already cached) template
data to it, which can be reused between entities with the same template
and owning player. And then overwrite the values affected by
entity-local modifications, which are usually just a few and even they
can be cached and reused for entities with the same owning player,
template, and entity-local modifications (identified by the
"modifications ID").
This saves the effort of retrieving/computing a ton of data each turn
and also saves the time it takes the engine to clone the data from the
simulation to the GUI (as the return value of the GUI interface call),
which previously took just as long as retrieving the entity states
themselves.
Since only the dynamic state is read from the components, a number of
small getter methods have become unused; they are kept (for now at
least) since they might be useful again in the future or for mods.
If no player is provided then the function falls back to the viewed
player, which is sometimes not the right one (like for observers), which
resulted in inconsistent/incorrect data being returned. This patch fixes
that.
This patch allows techs to optionally define a property "placeBelow"
specifying a combination of class requirements. The selection panel then
tries to place their research button below the training button whose
unit matches these classes -- if there is only and exactly one.
This is useful for techs only affecting a single type of unit: it e.g.
allows always placing the fishing nets research button below the fishing
boats training button.
To prevent duplicating information in "placeBelow" (e.g. from
"affects"), it can also be set to two magic values: "{AffectedUnit}" and
"{UnlockedUnit}". In practice, many techs use those, but class
combination remain useful for granular control in very specific cases.
Regarding tech pairs, as explained in a comment, their two research
buttons can now be placed in three different arrangements (with
descending preference):
1. Vertically below a single training button.
2. Horizontally below two adjacent training buttons.
3. Horizontally adjacent in the bottom row (below no training buttons).
Vertically in the third and fourth rows (below no training button) --
how it was previously -- is no longer done as it'd conflict with and
doesn't fit the new layout and the clear separation between "generic"
and "specific" techs.
Whenever a research button can't be placed in their preferred location
because it is already occupied, the code simply falls back to the default
position in the bottom row.
This patch also adds a new game option to hide the new small arrows above
the research buttons in order to give more experienced players who already
know the techs well the possibility to reduce visual clutter. By
default, the arrows are shown.
This patch renames the "pair" property of paired technologies to
"partOfPair" for clarity and in the pair parent packs the two techs
(previously "top" and "bottom") into an array called "pair".
This makes the hierarchy more clear in the code and pairs might not be
always placed vertically in the future.
getTotalQueueTime(queue) calculates total remaining
queue time of a production building.
getBuildingsSortedByQueueTime(entities), sorts building selection
by their queued training time and filter invalid entities
Removes the resource availability guard from the Training selection
panel onPress handler to align mouse interaction with hotkey behavior
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
There are currently 19 entity commands in total, but only the first 6
possible (depends on the active selection, e.g. patrolling isn't
possible if no units are selected) ones are ever displayed as buttons
(defined by g_SelectionPanels.Command.getMaxNumberOfItems) However,
when updating (once per turn or whenever the selection changes),
g_SelectionPanels.Command.getItems always called `getInfo` on all of
them, even though all data computed after the first 6 wasn't read or
used anywhere later. So, stopping immediately after the 6th and never
returning an array longer than 6 saves all of the dead time without
affecting the outcome in any way.
It's important to mention, that this issue isn't exclusive to the
'Command' selection panel: the getItems methods of the other panels can
also return an array longer than their getMaxNumbertOfItems value
(that's why they specify it in the first place). However, for the
command panel this happens for many common selections and seemingly to
by far the largest extent. For the other panels it happens much more
rarely, only for especially large and obscure selections, and even then
does not have nearly as big of an impact. So, modifying the other
getItems methods as well (to never return too many items) is probably
not worth it, and the more robust solution is to instead keep the
safeguard system of getMaxNumbertOfItems.
Adds a randomly male and female Civilian unit which replaces the old "Female Citizen" for each civ.
New actors, new portraits, some new body textures, but the same stats as the old Female Citizen.
Updates maps, technologies, skirmish templates, et al. including the Tutorials.
Co-Authored By: Itms
Reviewed By: Vantha
It is possible to modify sizes by setting the properties directly.
(Without having to create a copy of it)
This allows to shorten those passages quite a bit without any functional change.
During the eslint 8 cycle the formatting rules were split out [1],
deprecating the corresponding rules in core.
This replaces all rules that where moved to @stylistic/eslint-plugin [2]
and accounts for the difference in the indenting rule behaviour.
To allow the pre-commit import hack to continue to work with the
stylisitc plugin for a recent nodejs version to be used.
[1] https://eslint.org/blog/2023/10/deprecating-formatting-rules/
[2] https://eslint.style/packages/default
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
- Left-clicking the portrait of a unit will make the camera follow that
unit (before: no action). A tooltip informs the player of this
possibility.
- Left-clicking the portrait of a structure will make the camera focus on
that structure (before: no action). A tooltip informs the player of
this possibility.
- Double-clicking a hero/treasure icon will make the camera follow that
hero/treasure (before: just focus on that hero/treasure).
- Some minor related changes.
Fixes#6879
When calling `Engine.PushGuiPage` a promise is returned. The promise is
settled when the "child" page is closed. That allows to `await` it
inside `async` functions.
Previously the callback was run right inside the call to
`Engine.PopGuiPage`. Now the continuation of the promise is called at
the end of the "tick".
This won't help performance. It will more likely make things worse.
Since gui pages aren't opened or closed that frequently, it doesn't
matter that much.
Refs: 86c151ebaa
For the engine side:
The promise is stored in the `CGUIManager::SGUIPage` (like previously
the callback). When the promise is fulfilled it enqueues a callback in
the `JobQueue` of the `JSContext`.
Original patch by: @wraitii
Comments by: @wraitii, @Stan, @Polakrity, @lyv, @elexis, @vladislavbelov
Differential Revision: https://code.wildfiregames.com/D3807
This was SVN commit r28145.
Done by creating a function for 'objections' and using that for any
unmet requirements.
Patch by: @abian
Differential revision: https://code.wildfiregames.com/D4899
Comments by: @Langbart
Fixes#6694
This was SVN commit r27484.
Allows more flexibility in e.g. the Identity requirements and unifies
the checking of requirements.
One can use the script at https://code.wildfiregames.com/P265 to fix
templates.
Differential revision: https://code.wildfiregames.com/D4514
Comments by: @elexis, @Stan
Fixes#6421
This was SVN commit r27245.
One needs UnitAI to be able to use a formation, so include the spec
therein (to keep information close to where it is used).
Modders can change their templates with the following script:
https://code.wildfiregames.com/P261.
Differential revision: https://code.wildfiregames.com/D4443
Comments by: @Stan
Idea accepted by: @wraitii
Fixes: #6399
This was SVN commit r26235.
The task of the production queue should first and foremost be that; a
queue for production items.
Hence, the specifics of training/researching are delegated to specific
components.
As a side effect, this improves the test coverage and fixes:
- Resource not refunding when hitting the entity limit. Introduced in
b8758c8941.
- Autoqueue changing when unable to spawn. Introduced in 956b3f96db.
Modders can change their templates using
https://code.wildfiregames.com/P256.
Differential revision: https://code.wildfiregames.com/D4333Fixes: #6363
Comments by: @Silier
Refs. #6364
This was SVN commit r26000.
Deselecting a part of a formation didn't deselect the whole formation,
since the logic was done quite weirdly.
This clarifies and fixes that.
Reported by: @Langbart on D4282.
Differential revision: https://code.wildfiregames.com/D4285
Comments by: @Angen, @Langbart
Tested by: @Langbart
This was SVN commit r25948.
The graphical interface will show autoqueued units as 'ghost' units so
the player gets immediate feedback on what's happening.
The autoqueue disengages if it runs out of resources or entity limits:
this reflects that the autoqueue cannot resume on its own.
By changing the spot where the autoqueue pushes items, the autoqueue no
longer 'buffers' one unit in advance, but remains very slightly less
efficient than manual queuing. This also prevents cheats from leading to
a ton of units accidentally being created.
Accepted By: Freagarach
Refs #6213
Differential Revision: https://code.wildfiregames.com/D4144
This was SVN commit r25779.
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.
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.
If there is a building that has a paired tech researchable, where the
two techs have a civ requirement but the parent pair tech doesn't, then
the selection panels will throw errors.
This has happened with add6b0206c,
https://wildfiregames.com/forum/index.php?/topic/24732-de-alpha-24/page/2/
and other incidences.
Now when both paired techs have an unmet civ dependency they are not
shown, when one of them hasn't, it is shown.
Fixes: #5915
Original patch by: @elexis
Changes by: @Freagarach
Differential revision: D2171
Comment by: @Imarok
This was SVN commit r24621.
By specifying the players which are allowed to use(/see) a command
button and adding an enabled/disabled property to the info.
Differential revision: D2343
Comments by: @Angen, @Stan
This was SVN commit r24501.
This allows choosing a "default formation", which is activated
automatically for units given walk orders (and attack-walk etc.).
Conversely, units in formation that are given a gather/build/... order
are taken out of formation and given the order individually.
The default formation can be selected by right-clicking on any formation
icon.
This leverages formations for walking, where they are quite efficient
(in fact, perhaps too efficient), while circumventing issues with
various orders.
Choosing the "null formation" as the default formation de-activates the
behaviour entirely, and plays out exactly like SVN.
This makes it possible to queue a formation-order then a
noformation-order (i.e. walk then repair), though the behaviour isn't
very flexible.
For modders, it should be relatively easy to change the setup for each
order, and/or to force deactivating/activating formations in general.
Tested by: Freagarach, Angen
Refs #3479, #1791.
Makes #3478 mostly invalid.
Differential Revision: https://code.wildfiregames.com/D2764
This was SVN commit r24480.
Before this patch, when entity was upgrading and producing and finished
upgrading before production, production was canceled. That meant player
assumed unit/tech will be ready in certain time but it will not. Also
fixing interference between upgrade and production animations.
Differential Revision: D2652
Reviewed by: bb
Comments by: Stan, Freagarach
Fixes: #5749
Refs: #2706
This was SVN commit r24088.
