StatRings - Anchor configuration preview
 

I've uploaded a somewhat experimental snapshot of StatRings to

http://www.vigilance-committee.org/w...nloads/random/

StatRings-0.7dev-10900.zip

It's got a few quirks (most notably that label hiding isn't enabled for any of the rings) as I've ripped out and replaced a huge chunk of code, but I've included the first integration of layout editing code.

As I said before this is EXPERIMENTAL, and INCOMPLETE, so you probably want to read the following before using it.

* Layout changes dont save between session (This is a mixed blessing 8-))

* The new layout changing code is distinct from the more finished configuration panel, so try not to have both up at the same time (It wont BREAK but it may not do what you expect it to do).

With that out of the way, here's a quick summary of the 'Scaffold' layout and how you edit it.

The scaffold consists of a number of anchors, that position each ring relative to its parent ring. You can't currently change parents, but you can adjust anchors. The following anchors are useful at the moment:

player - Moves the player ring (And everything else, since they're all attached to it)
pet - Moves all pet rings relative to their owner ring.
target - Moves the target ring relative to the player ring

partyStart and partyEnd - These two logical anchors are the locations of the first and last party members when all 4 are shown, party rings are positioned between them based on party size.

To play with the anchors, there's presently a slash command (quick to implement, it will get GUI-fied soon enough), do one of the following

/srdrag
On its own, it'll cancel any pending anchor drag.

/srdrag player
/srdrag pet
/srdrag partyStart
etc..
With an anchor name, you'll get the drag interface for that anchor.

So, what's the drag interface? There are a few boxes shown on the screen (possibly overlapping). The blue box(es) shows the location of the anchor's parent. This is fixed.

The orange boxes show the location of the anchor you're moving (with some text showing the parameters for the anchor). Each anchor has the following attributes:

angle, length: These determine where the center of the anchor is relative to the parent.
scale: This determines how large the anchor is relative to the parent.
spin: This determines the angle of the anchor.

Dragging the INSIDE of the larger orange box moves the anchor relative to the parent (Adjusts angle and length)

Dragging the more solid BORDER CORNER of the larger orange box adjusts scale and spin simultaneously.

Dragging the BORDER EDGE of the larger orange box with the LEFT mouse button adjusts spin only.

Dragging the BORDER EDGE of the larger orange box with the RIGHT mouse button adjusts scale only.

All parameters will 'snap to' an invisible grid, currently there's no way to turn that off (There will be in the end).

Anyway, play around, when you start to edit an anchor with /srdrag <anchorname> all of the possible rings will show up in preview mode (Invoking /statrings while this is shown will cancel that out, thus my warning above, but that MAY be useful). Running /srdrag on its own will cancel that out and return you to normal ring mode.

Enjoy.

I've done some cleaning up of code, so here's version 0.8dev, and a screenshot of the drag interface.

I've uploaded the latest preview version, again it's got some quirks and is more so that you can all see the progress in the layout editing UI than anything else.

/srdrag or /sros (both do the same thing) toggles the new layout UI. Most of the buttons do nothing, but the "Move" buttons should bring up the editing box.

Try not to mix /srdrag and /statrings, they dont coordinate their previews all that well (It wont break anything tho).

Finally, none of the layout changes save yet, consider that a mixed blessing.

Version 0.11dev!
 

Here's the latest dev version, the scaffold dragging code is pretty solid now (See screenshots), but I haven't got saving working yet, but that's next. As you can see there's rudiementary Combo Point support in as well!

See the readme.txt for commands and key bindings (for edit mode)

Iriel do you have any plans to update statrings?

Yup, I just haven't gotten to it yet (nor a couple of other straggler mods).. Harass me if I haven't posted an update within the next 7 days 8-)

That's great to hear. I absolutely love this mod and always have. I won't bother harassing you anymore. I know you're busy with a lot of mods and I'm sure that I can make do in the mean time. I was just curious if it was at all on your list or if you had abandoned it/found another alternative to use.

Iriel you just made my week.

Where is this?
 

This looks like an awesome add-on but it hasn't been updated (on WoW Interface anyway) in forever. I use the WoW Interface updater so I love things that I can favorite. Any chance this works or will be updated soon?

I asked myself if it would be possible to bring this back to life with oUF as a unit framework in the background.

Hmm...

that would rock if you could...lol i come here and stare at the screens from time to time hoping one day somebody who isn't a noob like me could make it work lmao.:p

I'm on a good way to bring Iriels approach of doing a ring back to life. Wrote a new mod based on the idea of the 4 segments, that is currently under development

http://zorktdmog.zo.funpic.de/ringmo...209_204218.jpg

RingMod
http://www.wowinterface.com/forums/s...d.php?p=148503

I'm pretty sure I can release a first running version in the next couple of days.
Whats most important is that it will provide functions that will allow you to create as many rings as you want plus adding events and event-functions on specific rings aswell.

Hooray, now I'm one step closer to making my UI look exactly like that of Kingdom Hearts!

But seriously, this will be fab. Can't wait.

Actually I came back the the rings lately and wrote myself a small script to test some stuff with processing.js.

http://dm.next-gen.org/files/ring/index.php

Doing pie-charts can be done with a nearly similar approach.

Rings have a problem when only one ring segment is looked at. If the ring extends to more than one segment or only one segment is used and either SA (start alpha) starts at 0 or EA (end alpha) at 90 then there is no problem.

Example...if we want our ring to start at 10 degree and it should be our healthbar. There is no problem as long as the health values is high enough to take place in more that just one segment. Assuming health is taking up 4 ring segments the health has to drop below 25% that only one ring segment is affected.

Now the problem comes with the ring size. The thiner the ring the later the problem will appear.

The problem occurs if this condition is true
The triangles can still be calculates but they will be huge and the size will not fit. Not sure if there is actually a formula that can describe the white space between the two squares and if there is any textures function that allows as to squish a texture in that spot.

Example:
http://dm.next-gen.org/files/ring/in...=4&SA=10&EA=20

Same example with a thicker ring:
http://dm.next-gen.org/files/ring/in...10&SA=10&EA=20

Normally we would fit a slice texture in the remaining triangle spots but that is impossible on certain scenarios especially if the ring starts at an degree that is not 0 or 90.

Actually I foud a way to describe the white space:



Now I have to ask myself if I can stretch a slice texture into those 4 triangles...hmmm

Well if we could use a square texture instead of a slice that works two...but we would need to squeeze two square textures like this:


No clue if that is possible with SetTexCoord.