discretize / discretize-gear-optimizer Goto Github PK

Right now, if you select viper/sinister/grieving, the optimizer always starts on full viper and ends on full grieving.

If settings.affixes[i] were instead settings.affixes[slot][i], one could rearrange the affix order on a per-slot basis. So settings.affixes[helm] could be [viper, sinister, grieving], but settings.affixes[chest] could be [grieving sinister, viper]. Every combination would still get iterated through, but the order would be different. This could speed up getting to the interesting combinations of a 3 (or 4+) stat optimization, e.g. so you can cancel earlier when you realize one of the affixes/infusions you have selected is never used.

This may be a performance gain, if getting a higher worstScore earlier reduces shuffling. Especially useful if multithreading the optimizer.

Care must be taken to not break ring/acc/shoulder/glove/boot deduplication.

Add a checkbox which adds the modifiers for exposed to the calculation (+30% pwr, +100% condi)

I propose to open source the gear optimizer once the react recode is done.

MITM or GPLv2/3 ? I'm personally in favour of GPLv3. Other opinions?

• Figure out the license
• get everyones approval for the change of the license
• Clean up the project (#108 , rework the readme

ideally I would like to put all the generic stuff together and the current jquery-version-specific stuff together

• Cache gear stats that were not relevant (see: https://discord.com/channels/301270513093967872/842629146857177098/858132195701293101)
• Cache a bunch of _testCharacter calls and run them in a web worker
• Preprocess flat modifiers into settings.baseAttributes during setup; replace preConversionAttributes unnecessary object clone with referencing baseattributes, preprocess additive mods into multiplicative ones, stop storing multipliers as arrays of length 1
• cache the results of post-conversion [condition damage, expertise] => condition portion of damage, as I don't see any way for that not to have the same result

post: Condition Damage should just be add: Condition Damage

mostly firebrand I think

https://wiki.guildwars2.com/wiki/Versed_in_Stone

see https://discord.com/channels/301270513093967872/842629146857177098/859280126906073128

seems kinda convenient

Use a reasonable value for base healing power

see: https://discord.com/channels/301270513093967872/842629146857177098/856706982387253308

pretty sure

https://github.com/discretize/discretize-old/blob/84efc84747ec45978ce9e4866c70c1a6d6fe91d2/src/js/gear-optimizer.js#L1197-L1206

see: https://discord.com/channels/301270513093967872/842629146857177098/857727330334801971

move yaml files into the data folder of dT-guides repo. This way anybody can update the raw values on a patch.

Is it enough to change the path in the gulpfile for yaml?

Have to check CI and the deployment procedure that nothing breaks

and reaper shroud, etc

I don't understand why #86 would cause this

Probably when the "big recode" happens...

ha I never finished this

• addModifiers has a ton of unnecessary checks
• I store a bunch of things in 1-length arrays and "iterate" them, leftover from when they didn't used to be deduplicated
• flat modifiers and additive modifiers can all be calculated beforehand
• $.each[] calls are iterating over way too much
• can probably just remove most of the "does this exist" checks and preset most things

useful for comparing to gw2skills/ingame gear

add gearStats to character; make settings._modifiersFromGear

for example, a multiplicative -33% damage effect like protection does not multiply effective health by 1.33, it multiplies it by 1/(1-0.33) = 1.492

see: https://discord.com/channels/301270513093967872/842629146857177098/850740073066004500

popup has custom logic so this can be calculated differently than when the optimizer is doing the actual math and can say e.g. 100% (103.5%)

could also implement max number of primary infusions, making calculator assume you;re using Math.min(maxPrimary + maxSecondary, 18) total infusions

mostly for the calculator output values and not crashing on various combinations of inputs (0 valid results, only one affix selected, etc)

https://github.com/ManuelHaag/discretize-old/blob/92bfa21af3bd91b6a1485a89677fad51a257c16c/src/js/gear-optimizer.js#L1408-L1421

These are the only places individual durations are capped to 100%, so if these ifs are false, one can exceed 100% on i.e. burning.

https://github.com/ManuelHaag/discretize-old/blob/92bfa21af3bd91b6a1485a89677fad51a257c16c/src/js/gear-optimizer.js#L1297-L1303

https://github.com/ManuelHaag/discretize-old/blob/92bfa21af3bd91b6a1485a89677fad51a257c16c/src/js/gear-optimizer.js#L1312-L1318

UI idea: 14 little text boxes; you can type in the 4-character codes; debounced code will highlight them green if valid affix

implementation idea: in _advanceCalculation, before recycle/clone, if forcedstats[nextSlot], gear[nextSlot] = forcedstats[nextSlot], continue;

will need to split up or rewrite duplicate skipping

relevant patch notes: https://wiki.guildwars2.com/wiki/Game_updates/2021-05-11 / https://en-forum.guildwars2.com/topic/95447-game-update-notes-may-11-2021/

Link: https://github.com/ManuelHaag/gw2-ui

Currently, the performance of gw2-ui is in a terrible state; this should get fixed before we integrate gw2-ui into the optimizer. Check out the project, go to the refactor-build branch, run the develop server and navigate to the performance page in the browser. All of the gw2icons load extremely slow, one at a time.

I've tried to setup a basic implementation of gw2-ui for the optimzer locally, however, I did run into problems. It is possible that also this issue (ManuelHaag/gw2-ui#5) will need to get fixed before we can proceed.

After that, we may integrate it into this project. Minimum setup: ManuelHaag/gw2-ui#5 (comment)
Integration done, see react-recode branch. Bugs remain in gw2-ui.