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.
This patch is primarily meant as preparation in order to be able to
reuse this logic for GetEntityState calls in the future.
Key changes:
- Clearer API by providing different functions for different purposes.
- Slight performance optimisation by storing parameters in a context
object and pulling the info from there instead of redeclaring a lambda
each time, which it seems Spidermonkey struggled to optimise well.
- Allow computing only partial template data, specified by passing a
list of desired components. (to be used more in the future)
- Make it so the naming and structure of template data and matches 1:1
with the data in entity states. This makes accessing values from them
more consistent and would also allow e.g. adopting data between the two
in the future.
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.
Use tokens for required technologies, allowing `-tech` and easier
replacements.
Fixes requiring `replace=""` when replacing techs.
Also a minor fix in the TemplateParser.js for upgrade requirements.
Refs. 9bb9ff8b16.
Differential revision: https://code.wildfiregames.com/D4912
Comments by: @Stan
This was SVN commit r27505.
Complex requirements were not properly handled by the parsing code.
This makes it a bit more explicit while also handling multiple techs as
requirements.
Reported by: @wowgetoffyourcellphone
Differential revision: https://code.wildfiregames.com/D4833
This was SVN commit r27350.
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.
Patch by @s0600204.
This lets all technologies show up correctly in-game and in the
structure tree again.
accepted by: @marder @Freagarach
Fixes: #6587
Differential Revision: https://code.wildfiregames.com/D4755
This was SVN commit r27042.
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.
The Reference Suite (Structure Tree, Civ Info, Viewer) wasn't taking
into
account civilization- or team-bonus auras when calculating entity stats.
This wasn't really a problem (for Vanilla 0AD) prior to a18d97b047, as
civ-bonus auras don't exist in Vanilla 0AD, and our team-bonus auras
didn't
apply to the owning civ before that change. Now they do, the Suite needs
to
take them into consideration.
Differential Revision: https://code.wildfiregames.com/D4093
This was SVN commit r25751.
As a side effect of 6b7a80b260, this is now trivial to do.
We don't (currently) have any aura-based civ bonuses in Vanilla 0A.D.,
but hopefully modders will find it useful.
This was SVN commit r25690.
(The `civ` key (in the team bonus aura templates) was added in
190d6e7cf5 for the
purpose of identifying which aura belongs to which civ. It's no longer
used.)
Proposed by: @Nescio
Comments by: @Freagarach
Refs: 190d6e7cf5
Differential Revision: https://code.wildfiregames.com/D3864
This was SVN commit r25689.
Allows entities to change their resource amount over time, possibly with
some constraint.
This is a not-so-bare minimum, but can certainly be improved and/or
extended later.
Part of: #1973
Original patch by: @smiley
Redone by: @Stan
Standing on the shoulders of giants: @Freagarach
(Revisions: 59; Inlines: 209)
Differential revision: D1718
Comments by: @Angen, @elexis, @Imarok, @Langbart, @nani, @Nescio,
@smiley, @Stan, @wraitii
This was SVN commit r24963.
When one hovers over gate in structure tree (e.g. gauls), it shows
unmodified hp.
As soon as one opens template viewer, one can see correct values.
Reason is that when getting values of upgrades, civ modifiers are not
applied.
Differential revision: D3427
Reviewed by: @wraitii, @s0600204
This was SVN commit r24730.
Instead of loading information about heroes, special buildings, et al.,
from the
`{civ}.json` files, load the information desired from templates.
Determination of "specialness" works as follows:
* Heroes are detected via the `Hero` class.
* Special Structures are detected via the `SpecialBuilding` or `Wonder`
class.
* Technologies are determined to be "special" when they can be
researched by
the currently selected civ, but are not open to be researched by
every civ.
* Team Bonuses are any applicable aura that reside in the appropriate
folder.
Accepted by: Freagarach
Comments by: Stan
Differential Revision: https://code.wildfiregames.com/D759
This was SVN commit r24492.
- Renames Armour-node to Resistance.
- Support resistance against Capture.
- Puts resistance against effects in separate nodes.
- Some cleaning.
Differential Revision: D2229
Reviewed by: @bb (accepted), @wraitii.
Comments by: @Stan, @Nescio.
This was SVN commit r24001.
The "health" of the palisade wallset was not being displayed correctly
in the
Structure Tree for any civ that didn't have the same resultant civbonus
effect
as the first civ shown when the 'Tree was opened.
The issue was caused by caching the parsed form of an entity template
when it is
first requested, then using that for *every* civ.
This wouldn't matter if every civ had completely different entities from
every
other civ, and no civ had civbonus technologies that affect shared
entities.
However, in "vanilla" 0 A.D., the templates of the palisade wallset, and
those
of the sheep, pig, and goat trainables, are shared between multiple
civs. And
the athen, brit, gaul, mace, and spart civs all have civbonus
technologies that
affect structure health.
(And as for mods, who knows...)
The solution provided here is to cache parsed entities by civ, like we
already
do with technologies.
Issue raised by @Nescio in b2842e8021
This was SVN commit r23913.
