SpaceTags

Rather than posting in lots of different places I figured I'd make one blog post here and then spam the various boards with links. The background for this post is that I keep feeling that the configuration of various unitframe and hud addons (as well as some other UI components) leave me wanting when it comes to spatial positioning of the elements. I want to be able to hook my UI elements to parts of the screen and/or to one another. If I move one of the parent objects I want the other objects to move with it. If I change my resolution I want everything to update smoothly (not be left offscreen for example). 

When trying to write up some suggestions for mHud and ag_uf I realized that there might be a way to add a library that would provide positioning for multiple addons (and allow them to attach to one another. I therefore present my proposal for SpaceTags.

The premise is that there each object can attach to another object in a number of ways. The top object in the hierarchy is "window", but that should probably be "viewport" instead (assuming the latter automatically adjusts for things like fubar/titanpanel etc). When attaching an object to another, you specify the parent, the connection point and the margins (offsets from the connection point).

UI.main is the reference object and the green (and red) boxes are the positions around it defined by a combination of vertical and horizontal tags plus vertical and horizontal margins. The center tags (hcenter and vcenter) are defaults and do not need to be specified. The default margins are 0.

Thus, to attach UI.child to UI.main we would have the following:

ui.child{ui.main, above, alignright, vmargin=10, hmargin=10}

When the parent object is "window", the corner positions are all (obviously) the same and you have to use negative v and h margins to get the position inside of the window.

Apart from these I also propose two more position tags: 

hmirror, vmirror

These would allow you to mirror the placement of objects around the middle of the window (viewport). While I'm not sure vmirror would ever be used, hmirror is handy for positioning HUD objects as well as some UIs that have player and target unit-frames mirrored.

I'll finish up with an example of using these tags to position the following UI:

HUD left to right: tgthealth, playerhealt, playermana, tgtmana

uf.player{window, top, alignleft, vmargin=-10, hmargin=-10}
uf.pet{uf.player, below, alignright, vmargin=2}
uf.target{uf.player, right, hmargin=30}
uf.tot{uf.target, right, hmargin=30}
uf.partygroup{uf.player, leftalign, below, vmargin=50}
uf.party{self, below, vmargin=10}
uf.partytarget{uf.party, right, hmargin=20}
hud.playerhealth{window, hmargin=-200}
hud.playermana{hud.playerhealth, hmirror}
hud.targethealth{hud.playerhealth, left, hmargin=-30}
hud.targetmana{hud.targethealth, hmirror}

One further component is added in the example above to handle repeating groups of frames such as party and party targets. In the first case (party), the whole block is attached to the player frame and each party member is spaced using the "self" tag. For PartyTargets each target is attached, not to one another, but to the parent party member. Thus if you changed the spacing between party members the party targets would follow. 

Another thing to note is that the hud.targethealth has a hmargin of -30. This is because, presumably, the object for the hud.targethealth would be a rectangle and we need to overlap the objects to get the arcs closer to one another.

I would propose that a system such as this one would be useful for many different UI objects and being able to share them isn't a bad thing. I can see attaching my cooldown timers to the right of my HUD etc. 

One final note, the tags as written above could obviously be manipulated by a UI fairly easily... no need to force users to write the tags themselves. Also, an obvious parent/attachment point is "none" if you want to position the object in some random way.

Comments are welcome!

Beast Master and Weapon Speeds

I wanted to revisit the topic of bow/gun speed for BM hunters. There is plenty of post about how clipping is bad (i.e. you don't want a weapon that is too fast). However, no one has posted about the cost of having a weapon that is slower than optimal.

Why does this matter? Steady Shot (unlike all other shots) is not adjusted for weapon speed either directly or through the damage range of the weapon. Therefore, the longer between your Steadies, the lower the DPS from the SS. To put some numbers on this I've made calculations based on an assumed raw damage from steady for 500 (400 + 25% crits and not counting mortal shot talent). This is a simplification but a good start. I'm also not calculating any cost to autoshots from clipping since that is a different discussion.

For a BM you'll have a 38% (1.15*1.20-1) speed increase from serpent swiftness and quivers. Thus we get the following

Speed BM   Speed   SS DPS   DPS Loss
   2.7      1.96   255.56
   2.8      2.03   246.43    -9.13
   2.9      2.10   237.93    -8.5
   3.0      2.17   230.00    -7.93
   3.1      2.25   222.58    -7.42

Valanos vs. Wrathtide
I know I can weave a 2.8 weapon comfortable (Valanos). As you can see, for me to switch to the Wrathtide Longbow (3.0) I'll loose 8.5+7.93 = 16.43 DPS from fewer steady shots. The Wrathtide gives me 9 extra base dps, 20 extra RAP and a little less crit. Worth it? No way!

Steelhawk vs. Sunfury
4 base DPS, 23 AP, about .5% crit and a bit less hit while giving up 8.5 DPS from speed. Worth it? My raid DPS is about 700 so .5% is 3.5 DPS. Thus the Sunfury gives me roughly 9.5 DPS extra from stats and I loose 8.5 from the slower SS. Thus it's worth it but not with any large margin.

I know (almost) everyone is poopooing the Don Santos bow, but I'm not sure why. With a 7.5% proc rate it gets an average AP bonus (over long fights...after the first proc) of 115 = 8.2 DPS (it has a 46% chance of chain proccing if you are BM). In my view this is the best BM weapon, at least for instances and raiding where you can expect a fight to last more than 10 shots and if your latency is low enough to allow you to use it without clipping autos (and even clipping autos a little bit wont hurt you much).

Speaking of clipping... the cost of clipping is very similar to the calculation for the steadies above... lets say you barely clip a 2.7 and don't clip a 2.8 weapon... the cost for clipping is probably about 4.5 dps (splitting the difference of the 9.13 speed cost to ss). I'd rather have a weapon that barely clips every autoshot than one that leaves me a lot of dead time after each steady.

I've put up a set of pages with comments on my WOW UI at http://lindalas.ebo.googlepages.com/home