Changeset View
Standalone View
binaries/data/mods/public/simulation/components/GuiInterface.js
Context not available. | |||||
let timers = cmpAttack.GetTimers(type); | let timers = cmpAttack.GetTimers(type); | ||||
ret.attack[type].prepareTime = timers.prepare; | ret.attack[type].prepareTime = timers.prepare; | ||||
ret.attack[type].repeatTime = timers.repeat; | ret.attack[type].repeatTime = timers.repeat; | ||||
let bonuses = cmpAttack.GetBonusTemplate(type); | |||||
if (bonuses) | |||||
{ | |||||
ret.attack[type].bonuses = {}; | |||||
for (let bonus in bonuses) | |||||
ret.attack[type].bonuses[bonus] = { | |||||
"classes": bonuses[bonus].Classes, | |||||
"multiplier": bonuses[bonus].Multiplier | |||||
}; | |||||
} | |||||
elexis: missing semicolon
-1 tab
This is the default way, and the right way to do it assuming that… | |||||
Done Inline ActionsGiven that we have cmpAttavck.GetBonusTemplate already, passing it through the GUIInterface is justified, despite the unfortunate performance impact. (The cmpAttack function may change the bonuses, if not now then in the future or for mods) elexis: Given that we have `cmpAttavck.GetBonusTemplate` already, passing it through the GUIInterface… | |||||
Not Done Inline ActionsThis function is a mess performance-wise, way too much object creation which could be cached in the components at least, even if it makes it harder to read the output. But reading the function again, it seems like 85% of the variables change so often that caching wouldn't be possible for many properties. I guess the object creation itself may be avoided however (only setting the properties). That would be probably thousands of JS Objects less per turn or something (200 units * 20 objects less recreated?). I really wonder if it makes sense to modify the counters with techs and auras, aren't they something that the player should remember well? I guess I can't argue against the freedom to modify it, especially the modders freedom so whatever, let's go with it. elexis: This function is a mess performance-wise, way too much object creation which could be cached in… | |||||
if (type != "Ranged") | if (type != "Ranged") | ||||
{ | { | ||||
Context not available. |
missing semicolon
-1 tab
This is the default way, and the right way to do it assuming that auras/techs can change the counters, also the way I explained.
(The GetEntiyState function is a significant performance bottleneck, last addressed in #4322, in particular when selecting as many units as allowed (currently capped at 200)).
But perhaps one could also load the template data from the EntityState in tooltips.js to avoid this copy? Then again not sure which of the two variants will turn out to be the faster / feasible / cleaner mechanism. (So maybe we end up with this GUIInterface diff as is.)