If i craft a 2H it means i will get 2 sparks behind to craft the rest of the BiS item and i dont need the ‘instant boost’ the 2H can provide me.
The BiS result is composed of a 1H from the first boss Mythic (should pretty easy to get, i said that last season and never got it…).
What item could i craft now (lock in BiS) that would bring me the cloest to the BiS result and i found this one : ecc4b9477d9648f0bd492f1bd08c276f
This result is actually higher than the unlock solution from BiS by an amount that i would say it is NOT neglieable
I can take a look – the difference is 0.5% which is a little higher than we’d like to see, but right on the edge of what we consider acceptable from the optimizer.
Now that we have some time between major patches, we have been working on some potential speed improvements to the optimizer. This is ultimately the way to improve on cases like this – simply try more options, particularly around more difficult cases with dependent items like crafted embellishments, set bonuses, etc.
Our estimate for the adrenal surge clasp seems to match the game spell data… 2 rppm (with a 15 sec ICD), 12 sec buff… the primary stat amount and mastery penalty seem to match the game data as well – do the tooltip values on the website match what you are seeing in-game?
So not an exact match but i suspect you have the proper values set but only a tooltip issue potentialy wich is neglieable issue.
It’s more like an uptime issue. I cannot find a log using it from season 3 or season 2 or season 1 someone using this belt in raid to try to look at the proc rate. The theoritical uptime is 12sx2/60s = 40%
But i’m expecting it to not proc from every dammage source and only direct hit. Making to uptime actually less than 5% in raid, maybe more in MM+.
I’ve found another weirder result actually 32a5e485a6ca481f81367105345f8656
In this one i’ve limited the crafted gear to rank 1.
The spell data says it triggers on any damage taken (though I would assume not e.g. ground effects). I can reduce its value further for non-tanks though.
Yeah the mastery penalty doesn’t match in the tooltip… I’ll fix that.
What am I looking for in that second snapshot?
I think the issue in your first case might be that it is not trying every combination of secondary stats on the crafted items – we have to take a guess at it to keep the number of combinations from getting out of control.
Just to give you an idea of how quickly the combinations can explode… you have 16 slots, and say we only consider 4 possibilities in each slot. Finger/Trinket are special as they pull from the same pool of items, so it’s really 14 “slots” where finger has 4 choose 2 and trinket has 4 choose 2 combos, or 6 ways to pick rings and 6 for trinkets. That’s ~600 million combinations of gear. We didn’t even consider gems and enchants. Thus these crafted items can be quite a pain… as each one has 6 stat combos. Replace one of our 4 ring options with 6 versions of a crafted ring, now we have 9 total options for rings, which would bring our total combos to examine up to ~3.6 billion.
Now of course we don’t do a straight brute-force approach like this, so we can sift through way more than 4 options per slot in a short amount of time and still get to optimal or very close to it, but some amount of pruning of the initial search space is still required.
That said, I’ll see if we can tweak the logic that is being used to choose the crafted ring stat combos to try – I suppose a fallback would be to give Best in Slot a setting similar to the upgrade finder where a user could tell us their preferred crafted stat combo.
Ha yes ! I remember something like that in a previous discussion. That’s probably it the why; annoying crafted item.
This second one offer an higher solution (in%) but with lower crafted item level except for one that i’ve locked (707 wrist for exemple is selected).
Yeah, it was even more visible with the previous simulation system. Big Data. Maybe you can create a new compagny with big word like Big Data to get found raised x).
I’m currious if you’ve looked into stuff like ‘Genetic Algorithms’ (i think this one you did 100%) or ‘Particle Swarm Optimization’. Two method that i’ve used to optimised the mechanical conception for a turbine (Particle did not worked well but genetic did). That 1500 continuous parameters to optimized, it takes 10min to optimize using Excel (yeah i wanted python but management wasn’t okay with it).
The last one i’ve ‘known’ about is “Bayesian" optimisation but i have not enough knowledge on this one.
Maybe that could also lead to some automated building combinaison, like instead of doing all, you do some for a spec and if someone (like me) ask for a not tested combinaison, you use the result of the combinaison to modify the rest, like a self build solver (but i guess i’ve already shared this idea).
I would prefer AMR to tell me what stats to use… Actually i usally try all, and there is 2 combinaison close to each other and i add the two in Upgrade Finder. Maybe BiS could do something like that; not test all but predict 2 or 3 combinaison and then test them.
Yeah that’s what we do right now – try to pick two combos that will probably be the best. I might need to review that logic a bit or change it up. Or maybe do a quick first pass without crafted items, then pick which variants to try because the solution will be close to optimal already, so the preferred stats will be easier to infer at that point.
We have tried many optimization algorithms over the years – all of them could be described as a variant of some well-known algorithm or another. I think our first reforge optimizer back in the day could be described as a branch-and-bound algorithm, for example. I’m always up for trying new things though – often new expansions necessitate changing our approach.
One thing we have found is necessary for speed though is to apply as much domain-specific knowledge to the problem as possible, rather than trying to convert the gear problem into some “generic” form and using an off-the-shelf optimization approach. The more specific and specialized you can make your optimization, the faster it will be – at least that has been my experience.
The other thing that has restricted which approaches we can use is that we require the optimization to be deterministic. Many approximation algorithms will give a slightly different result each time they are run (I haven’t written one, but I think genetic algorithms are often non-deterministic… could be wrong on that though).
People really don’t like it when the same input sometimes gives a different output. They don’t like it even when slightly different inputs give slightly different outputs… we are constantly fighting that one. The best example is locking an item that would already have been chosen by the optimizer – in some cases you can get a slightly different output with this small change to the input. We try to make the optimizer as stable as possible, but some variation as a function of the input is inevitable when dealing with approximation algorithms.
Interesting! I knew you were already doing some incredible stuff.
About the deterministic topic, the two cases I’ve worked on genetic and particul were actually very stable in the result. The main reason was the simplicity of the problem I had. In the end only 3 variables were generated randomly. And the rest of the calculation was at worst polynomial.
It is certainly not as complexe as what AMR is doing. So yes non deterministic result for BiS would be annoying.
Well I hope you will find good improvement in the month to come
I was messing around with this a little bit – turns out that I put in some code at the beginning of this expansion to choose the secondary stat combinations on crafted items in Best in Slot using a pretty thorough method. So e.g. in this case it is identifying the crit/vers variant of the crafted ring as the best choice.
I’ll have to dig a little deeper to figure out why it doesn’t want to pick this ring in this case.
Crit-versa is taken due to some mana limitation from something probably crit-haste.
Crit-versa was the go do for mistweaver in all previsous expansion.
Swol did in S1 and S2 some tweaks to follow more Haste as a recomandation (to follow everyone else let’s say) and we can see that AMR is trying to put some haste ring. Maybe it has to do with this kind of override that swol did ?
I hooked up the “healer playstyle” in the spec options in such a way that players can control how much haste the optimizer wants with that to some extent. With the updates in 11.2, the calculations are not very responsive to it anymore… I’ll have to look at why that is. It’s on my list to check out.
All the feedback I have been getting from healers in general is to care less about mana (which allows for higher haste builds). I will have to mess around with the code some more to get it to respond to the playstyle option a bit more.
In general, I found that if you include major cooldowns in the healing calculations, like revival, that pushes any solution you can calculate away from haste. So, that option largely works as a balance between how much you care about big chunks of healing not affected by haste vs your “normal” healing “rotation” (not really a rotation, but I think you know what I mean). Mistweaver is especially tricky because your other big cooldowns, Chi-Ji and Yu’lon, work differently than other specs. Haste doesn’t affect them in the sense that you won’t use them more often with more haste, but, haste can make both of them more effective by casting more spells while they are up.
I feel like mana for monk is an issue and a poor mana tea management could drive away from haste has well. Currently Revival isn’t even a CD anymore… It’s so bad…
But with the current set i fill like the hero talent is very insane. So much CDR that i can press everything.