Jump to content


Photo

Team Robot Simulator and Gear Comparison Tool


  • This topic is locked This topic is locked
175 replies to this topic

#161 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 09 March 2010 - 06:07 AM

To answer your question fully would take a little while Gurrshael... but at a high level, it works as follows:

We pre-calculate a bunch of data points at various combinations of stats. Then, we do a linear approximation using the pre-calculated data points and your actual, current stats.

We do a similar technique for set bonuses: pre-calculate data points with the set bonus as various gear levels, then do a linear approximation based on your current stats.

Most trinket procs are averaged out for the purposes of estimating their value.

The technique overall is very simple and produces reasonably good estimates... there are definitely a few inaccuracies here and there though -- we'll continue to refine the estimates as we develop more classes.

#162 Gurrshael

Gurrshael

    Von Kaiser

  • Members
  • 79 posts

Posted 09 March 2010 - 12:27 PM

Thanks for explanation yellowsix.

This certainly works very well for in most cases.

I am interested in the way you handle Armor Penetration and trinkets with ArP proc. Is the proc averaged too? What if I use the trinket while being significantly over soft cap?

You mentioned that most trinket procs are averaged. Can you share which ones aren't?

#163 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1302 posts

Posted 09 March 2010 - 03:09 PM

The technique overall is very simple and produces reasonably good estimates... there are definitely a few inaccuracies here and there though -- we'll continue to refine the estimates as we develop more classes.


Do you maintain a dps-surface database per talent/glyph combination? Or is the surface calculated for each player? Or is it just starting with a single player and varying one stat at a time?

I have considered generating the 10-Dim surfaces required for general linear approximation, but I was daunted by the sheer number of data points (even given a tuned c++ program) not to mention that true interpolation of a 10-Dim surface is rather painful. Obviously, for most class/spec combos the dimensions reduce to 7 or 8.

#164 revulva

revulva

    Piston Honda

  • Members
  • 105 posts

Posted 09 March 2010 - 05:46 PM

I don't know all the details of how yellow implemented the estimates, but, I think that we are varying one stat at a time.

As you pointed out, the amount of data points that would be necessary for 100% accurate estimates is huge. This would slow the site to a crawl. We are using a simplified, empirical method that reduces our total number of data points for each class to a minimum. This allows us to dynamically change the estimates each time you change a piece of gear.

But, this is also why you will find a small percentage of items that do not appear in the correct order.

#165 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 09 March 2010 - 07:08 PM

Gurrshael, now that I think about it... it's possible that the value of certain trinket procs are not being reduced properly when a player is near certain caps for stats. Its value really needs to be reduced prior to averaging it out. I'll take a look at that.

When I said that some trinkets aren't averaged, I was referring mainly to trinkets that do direct attacks like . For those, we estimate about how often/how hard they hit to come up with a DPS value.


dedmonwakeen, one way that we reduce the number of data points is by only calculating estimates using one "standard" set of talents per spec. Classes like feral, moonkin, elemental, enhancement are easy: there is only one spec that really makes sense. For death knights, we have a separate set of data for blood 2H, frost 2H, frost DW, unholy 2H, and unholy DW.

Talents that have very simple effects, like "+3% spell hit" or "+5% crit" will be factored into the DPS estimates, but that's about it right now: for the most part it assumes a standard spec.

Most players will only have minor variations from the "standard" talent specs... and a lot of times these variations won't significantly affect the relative value of gear, so we considered it an acceptable trade-off between speed and accuracy.

#166 Eilanara

Eilanara

    Glass Joe

  • Members
  • 1 posts

Posted 10 March 2010 - 07:30 AM

Are you working on the other classes...an wil the heal be included?

#167 Guest_aceofsween_*

Guest_aceofsween_*
  • Guests

Posted 10 March 2010 - 05:00 PM

How does the Simulator treat Nibelung? It looks at the moment that it simply applies a DoT, which isn't altogether a bad way of doing things, but how does it handle multiple Val'kyr procs? Also, does it use the original 1% proc rate or the new 2% proc rate?

The reason I ask is that I never seem to see in the combat log results that it procs more than twice. In most situations though, I'm casting well over 200 spells, closer to 250 really, which would imply an average of 4 or 5 procs.

#168 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 10 March 2010 - 06:50 PM

I think nibelung is still using the old 1% proc rate... I'll update it to 2%.

I model nibelung as a "rolling" DoT to deal with multiple val'kyr. That's of course not exactly what happens, but the total damage dealt should be correct. It's a minor hack to work around the fact that the simulator doesn't like having 2 DoTs going at the same time with the same name/ID.


We are working to add every class to Team Robot: mages and warlocks are in development and should be available soon.

Eventually we'd like to add support for tanking and healing, but we have no timeline for that. All of the DPS classes will come first.

#169 ithatan

ithatan

    Glass Joe

  • Members
  • 1 posts

Posted 11 March 2010 - 04:28 PM

I tried this briefly, it looks pretty cool and I love how easy it is to use. Three suggestions:

1) Save the buff settings. The app seems to be able to save configurations of everything else, it's weird that it doesn't do this. I keep having to select my ArP food and lack of Bleed damage %.

2) A "maximum power" condition. I think it's still the case that you still want to use Ferocious Bite at minimal energy.

3) Add a time remaining to the "has one or more stacks" of a buff condition. I only want to FB if both Rip and SR are >= 9 seconds, for example.

#170 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 11 March 2010 - 07:21 PM

Saving buff settings is definitely on my to-do list.

You can get a "maximum power" condition with the NOT operator:

NOT (HAVE AT LEAST 40 POWER)

That would be true any time you have less than 40 power.


You can do time remaining on an dot or aura in a similar manner:

NOT (TARGET MISSING [RIP BLEED] OR LESS THAN 9 SEC REMAINS)

This is true whenever the target has the rip bleed and more than 9 seconds remain.


We definitely want to make the rotation editor more intuitive eventually, but with a little cleverness, you can make it do most of the things you need for now.

#171 conghaile

conghaile

    Glass Joe

  • Members
  • 8 posts

Posted 11 March 2010 - 10:38 PM

Had a question on possible conditional options.

I wanted to test a case where moonfire would be applied unless moonfire is already up, solar eclipse has more than 7 seconds left, or lunar eclipse has less than 3 seconds left, thus I looked to do a conditional table that looks sort of like this:

Only execute Moonfire if:

NOT Target has Moonfire
AND

Lunar Eclipse aura is on (yourself) and less than 12 seconds have passed.
OR
NOT have >= 1 stacks Lunar Eclipse.

AND
NOT have >= 1 stacks Solar Eclipse.

OR
Solar Eclipse aura is on (yourself) and more than 8 seconds have passed.


It doesn't appear measuring time left on auras you already have is an option, and using the cooldown timing conditional is clunky as balance since one eclipse aura gained can proc both cooldowns if both eclipses are cooled down. Is there any way to implement my case using current conditionals that I missed?

#172 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 11 March 2010 - 11:07 PM

Note 1: for the "aura" conditions, the text will say "TARGET", even though auras typically refer to buffs on yourself. Don't worry about that, if you do an "aura" condition and choose Solar Eclipse, it will work just fine. Note also that the "aura" conditions work for buffs on yourself OR debuffs on your target. Thus the slight funkiness in wording. (The latest version that I have not posted changes this language to say "PLAYER", which I think will make more sense in most cases.)

If I'm reading your condition correctly, in english, you want:

Cast moonfire if:
- the moonfire DoT is not already up
- solar eclipse isn't up or if it is, it has less than 7 seconds left
- lunar eclipse isn't up or if it is, it has more than 3 seconds left


Your full condition would become:

ONLY EXECUTE MOONFIRE IF:

NOT (TARGET HAS [MOONFIRE DOT])
AND 
PLAYER MISSING [ECLIPSE SOLAR] OR LESS THAN 7 SEC REMAINS)
AND
(
  NOT (PLAYER MISSING [ECLIPSE LUNAR] OR LESS THAN 3 SEC REMAINS)
  OR
  NOT (HAVE >= 1 STACKS OF [ECLIPSE LUNAR])
)


#173 Hamlet

Hamlet

    Mike Tyson

  • • Guide Author
  • 11579 posts

Posted 11 March 2010 - 11:09 PM

Had a question on possible conditional options.

I wanted to test a case where moonfire would be applied unless moonfire is already up, solar eclipse has more than 7 seconds left, or lunar eclipse has less than 3 seconds left, thus I looked to do a conditional table that looks sort of like this:

[/INDENT]

It doesn't appear measuring time left on auras you already have is an option, and using the cooldown timing conditional is clunky as balance since one eclipse aura gained can proc both cooldowns if both eclipses are cooled down. Is there any way to implement my case using current conditionals that I missed?


See what I was doing here:
http://elitistjerks....p4/#post1535059
I was looking at something different, but the same idea should work.

There's a bit of confusion between "player" and "target" in the condition description in the rotation editor, but the "target aura" one works for Eclipse.

#174 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 25 March 2010 - 10:37 PM

3.3.3 changes have been posted! A full list of changes is at:

WoW Simulator Change Log

There was only one bug fix for moonkin from the 3.3.3 beta to the current live version: glyph of focus was giving the old 20% multiplier to the AoE splash part of starfall instead of the new 10%.

#175 gannonjf

gannonjf

    Piston Honda

  • Members
  • 125 posts

Posted 26 March 2010 - 11:36 AM

Looks like the Phaly trinkets haven't been updated within the tool to reflect the minor buff Blizzard gave them in 3.3.3. I'm curious to see how that will change the rankings for trinkets, if at all.

#176 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 26 March 2010 - 07:47 PM

edit:

The tooltip is showing the old tooltip for , but the code is actually using the new spell power values. When the armory is back up, the new tooltip should show up at some point... the old one is still cached on the server, but the cache should expire in a little while.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users