Development of ag_UnitFrames has been shifted to primairly for TBC, the live version is on maintainance mode. If new features are 1.12 compatible, it will be backported asap, but no guarantees are given.
We have a problem with too many threads and too many issues/requests on a lineair page, causing headache and forgotten / not seen posts. To solve this, we've registered a issues tracker on google, so every issue and suggestion get it's own thread, correctly tagged for 1.12 / TBC / PTR, defect of enhancement, etc.
Oh, woot. You just relieved all the stress I was having about the BC release and my unit frames. I was having this nightmare vision of having to use the default unit frames for weeks, which would have made me quite the sad panda. I can deal with having to wait to have my raid frames working (as much as I love the agUF raid frames), but the normal unit frames had me really worried. Thanks so much for doing this. =D
The code that creates and groups raid unit objects needs to be totally rewritten to fit the new raid header model. I'd like to start on that, but unfortunately I don't have a BC key.
thanks for the port. some minor problems are that target of target doesn't seem to work, party pets stay after leaving party/raid, and sometimes target disappears- i suspect the latter is related to the whole problem of frames being changed while in combat.
if i get a refer-friend key i'll be sure to give it to you andreas, i <3 aguf!
The secure template thing is a lot less complicated than most assume. As everything in agUF is created from one template, only one line of xml was changed:
a new OnShowMenu was created, it uses the same logic as the old OnClick: ctrl/alt = config, rightbutton = standard wow dropdown, left click = target is done with attributes.
Other changes are mostly for k,v in table -> for k,v in pairs(table).
--
Raid frames works fine, just tested it again, made a little group and dragged myself around in group 1-8 and agUF behaves like in 1.12. The same goes for party frames.
--
known issues:
- unitframes cannot be changed in combat, so weird stuff can happen. I don't have an idea yet how to fix that.
--
svn: permission to do whatever you want with the code is given, so please upload a branch if you wish. I don't have wowace svn access, as I run my own dev repository :P
I'm not really for the new enduser leeching from dev builds thing, as it encourages release before testing.
Miles, I know the secure frames aren't a big deal for party frames, but there is a lot of work to do for the raid frames. Image if raid member raid34 leaves in a 40 man party, this means that the layout for all the frames needs to be updated, frames moved around and stuff like that, because everyone will get a new raid id in this situation. As unit frames cannot be moved in combat in BC, this isn't possible.
It isn't possible to do in BC unless you use the special secure raid headers which means that the frame creation and grouping code for the raid would have to be written to support this new stuff. But as I said I'd like to start working on that, but unfortunately I do not have a BC key, so I can't begin.
I know that raid frames probably seem to work, but they won't.
Miles, I know the secure frames aren't a big deal for party frames, but there is a lot of work to do for the raid frames. Image if raid member raid34 leaves in a 40 man party, this means that the layout for all the frames needs to be updated, frames moved around and stuff like that, because everyone will get a new raid id in this situation. As unit frames cannot be moved in combat in BC, this isn't possible.
It isn't possible to do in BC unless you use the special secure raid headers which means that the frame creation and grouping code for the raid would have to be written to support this new stuff. But as I said I'd like to start working on that, but unfortunately I do not have a BC key, so I can't begin.
I know that raid frames probably seem to work, but they won't.
Hmm, it's some really black voodoo you've got there.
As far as I can see, Blizzard's targettarget updating algorithm just uses :Show() and :Hide(), but agUF's can't. My current workaround is :SetAlpha(0) and :SetAlpha(1) - I don't see any other way to do it, yet.
It really sucks that you can't just poke Blizzard, saying you have written an addon thousands of users uses, and get a key to update it. I'm already happy that I finally got rid of the default UI, even if it won't work when you change the groups around in combat.
Hmm, it's some really black voodoo you've got there.
As far as I can see, Blizzard's targettarget updating algorithm just uses :Show() and :Hide(), but agUF's can't. My current workaround is :SetAlpha(0) and :SetAlpha(1) - I don't see any other way to do it, yet.
aguf uses an AceEvent timer to pull the ToT information(health/mana/name) as ToT units doesn't send out events. Each time that AceEvent timer fires (every 0.8 second) it updates the aguf ToT frame. It will also check if the frame should be visible or not, and hide/show it accordingly.
Take a look at the methods:
function aUF.classes.aUFunitMetro.prototype:UpdateMetro()
function aUF.classes.aUFunitMetro.prototype:Start()
function aUF.classes.aUFunitMetro.prototype:Stop()
function aUF.classes.aUFunit.prototype:SetVisibility()
function aUF.classes.aUFunit.prototype:UpdateVisibility()
function aUF:PLAYER_TARGET_CHANGED()
function aUF:CheckVisibility()
It really sucks that you can't just poke Blizzard, saying you have written an addon thousands of users uses, and get a key to update it. I'm already happy that I finally got rid of the default UI, even if it won't work when you change the groups around in combat.
Yes, it does suck a bit, especially when you know that people that won stupid competitions on the test servers earlier got one. I guess I should have entered those contests but I didn't have the time.
I know that they have given keys to many developers that hang out on the US forums, and possibly to the developers of very popular addons (ctraid).
Unfortunately for me aguf isn't that widespread yet (haven't been published to major sites) and I can't mark myself on the US forums as I only have an EU account.
I can still hope for a nice user who wishes to have a working unit frame ready in time for BC donates a key to me, but I'm not sure it's going to happen. Everyone wants to check and the new stuff and all, can't blame them!
I'm a bit dazzled by aUF's group sorting atm, but the secure template seems pretty easy to use. You can SetAttribute these stuff on it:
--[[
List of the various configuration attributes
======================================================
nameList = [STRING] -- a comma separated list of player names (not used if 'groupFilter' is set)
groupFilter = [1-8, STRING] -- a raid group number or an uppercase class name
point = [STRING] -- a valid XML anchoring point (Default: "TOP")
xOffset = [NUMBER] -- the x-Offset to use when anchoring the unit buttons (Default: 0)
yOffset = [NUMBER] -- the y-Offset to use when anchoring the unit buttons (Default: 0)
sortMethod = ["INDEX", "NAME"] -- defines how the group is sorted (Default: "INDEX")
sortDir = ["ASC", "DESC"] -- defines the sort order (Default: "ASC")
template = [STRING] -- the XML template to use for the unit buttons
======================================================
--]]
It should save a lot of code, but I'm not sure setting a template is enough to initialize a aUFunit. A 100-lines methode, SecureRaidGroupHeader_Update, will do all the hard work depending on what you set in the attributes.
Target's target is solved by changing aUFunit's UpdateVisibility() to (ugly hack incoming!)
if self.visible == true then
self.frame:Show();
self.frame:SetAlpha(1)
else
self.frame:SetAlpha(0)
end
It also solves the one-shotting stuff in Elwynn Forest = Target frame won't get hidden, you are in combat problem.
You use the Secure unit frame as a template for the ToT frame. Secure frames can't be shown/hidden in combat. You can only change the alpha.
I don't think there is a solution for that one other than using alpha. Actually, what happens if a party member leaves in combat? Will their frame get hidden? I doubt that, hmm.
Not sure what to do about that yet, hard for me to research :)
Also, the secure raid anchors seem easy to use, yes, but a lot of stuff needs to be redesigned because the secure anchors CREATES the unit frames, and does not pool these created frames between each other. This actually changes a lot due to the way aUF is designed. This means that we need to create an unit object after a frame is created by the anchors.
In aguf there is a unit object per unit frame, we can't have it that way anymore. I'm not even sure the secure anchors work yet, or how to execute code AFTER we're sure that all anchors have been updated. I think Cladhaire knows a lot about this stuff, but he isn't able to answer all of this yet.
Also, the secure raid anchors seem easy to use, yes, but a lot of stuff needs to be redesigned because the secure anchors CREATES the unit frames, and does not pool these created frames between each other. This actually changes a lot due to the way aUF is designed. This means that we need to create an unit object after a frame is created by the anchors.
In aguf there is a unit object per unit frame, we can't have it that way anymore. I'm not even sure the secure anchors work yet, or how to execute code AFTER we're sure that all anchors have been updated. I think Cladhaire knows a lot about this stuff, but he isn't able to answer all of this yet.
Yea, I couldn't figure out a way to convert aUF groups without major rewrites - I'll leave that for you since it's a total reengineering ;)
For now, I'll just just not change party / mess with raids when in combat, or /rl after it (half a second, gotta love the load times without huge data collection mods)
Yea, I couldn't figure out a way to convert aUF groups without major rewrites - I'll leave that for you since it's a total reengineering ;)
For now, I'll just just not change party / mess with raids when in combat, or /rl after it (half a second, gotta love the load times without huge data collection mods)
well, couldn't the mod after combat ends run a check on who has left the raid? or keep a table of people that have left? and update the display after leaving combat?
i mean i dont care if during my raid or party someone leaves and the visible portion of the box dissapeares... it would actaully be a bigger reminder to me than "offline"
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Development of ag_UnitFrames has been shifted to primairly for TBC, the live version is on maintainance mode. If new features are 1.12 compatible, it will be backported asap, but no guarantees are given.
Download:
Releases: http://www.wowinterface.com/downloads/info5468-ag_UnitFrames.html
Pre-release:
http://svn.wowace.com/wowace/branches/ag_UnitFrames/TBC/ag_UnitFrames/
http://www.wowace.com/files/index.php?path=ag_UnitFrames/ [TBC] tagged archives.
Issues Tracker:
We have a problem with too many threads and too many issues/requests on a lineair page, causing headache and forgotten / not seen posts. To solve this, we've registered a issues tracker on google, so every issue and suggestion get it's own thread, correctly tagged for 1.12 / TBC / PTR, defect of enhancement, etc.
The tracker is located at http://code.google.com/p/agunitframes/issues/ - please use that instead of the forums to report problems and suggestions.
You'll save 12 buttons, maybe more.
You can also play with Xad, but still in development :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOr euhm, want me to do it :)
-Ammo
Could we just make a TBC forum here on wowace so we can track all beta related issues?
if i get a refer-friend key i'll be sure to give it to you andreas, i <3 aguf!
<Button name="AGUnitTemplate" frameStrata="MEDIUM" movable="true" parent="UIParent" hidden="true" virtual="true" inherits="SecureUnitButtonTemplate">
Further, Reset gained a few lines:
self.frame:SetAttribute("unit", self.unit);
self.frame:SetAttribute("type1", "target");
self.frame:SetAttribute("type2", "menu");
self.frame:SetAttribute("*type2", "menu");
self.frame.showmenu = self.OnShowMenu;
self.frame.parent = self;
a new OnShowMenu was created, it uses the same logic as the old OnClick: ctrl/alt = config, rightbutton = standard wow dropdown, left click = target is done with attributes.
Other changes are mostly for k,v in table -> for k,v in pairs(table).
--
Raid frames works fine, just tested it again, made a little group and dragged myself around in group 1-8 and agUF behaves like in 1.12. The same goes for party frames.
--
known issues:
- unitframes cannot be changed in combat, so weird stuff can happen. I don't have an idea yet how to fix that.
--
svn: permission to do whatever you want with the code is given, so please upload a branch if you wish. I don't have wowace svn access, as I run my own dev repository :P
I'm not really for the new enduser leeching from dev builds thing, as it encourages release before testing.
It isn't possible to do in BC unless you use the special secure raid headers which means that the frame creation and grouping code for the raid would have to be written to support this new stuff. But as I said I'd like to start working on that, but unfortunately I do not have a BC key, so I can't begin.
I know that raid frames probably seem to work, but they won't.
Hmm, it's some really black voodoo you've got there.
As far as I can see, Blizzard's targettarget updating algorithm just uses :Show() and :Hide(), but agUF's can't. My current workaround is :SetAlpha(0) and :SetAlpha(1) - I don't see any other way to do it, yet.
It really sucks that you can't just poke Blizzard, saying you have written an addon thousands of users uses, and get a key to update it. I'm already happy that I finally got rid of the default UI, even if it won't work when you change the groups around in combat.
aguf uses an AceEvent timer to pull the ToT information(health/mana/name) as ToT units doesn't send out events. Each time that AceEvent timer fires (every 0.8 second) it updates the aguf ToT frame. It will also check if the frame should be visible or not, and hide/show it accordingly.
Take a look at the methods:
function aUF.classes.aUFunitMetro.prototype:UpdateMetro()
function aUF.classes.aUFunitMetro.prototype:Start()
function aUF.classes.aUFunitMetro.prototype:Stop()
function aUF.classes.aUFunit.prototype:SetVisibility()
function aUF.classes.aUFunit.prototype:UpdateVisibility()
function aUF:PLAYER_TARGET_CHANGED()
function aUF:CheckVisibility()
Yes, it does suck a bit, especially when you know that people that won stupid competitions on the test servers earlier got one. I guess I should have entered those contests but I didn't have the time.
I know that they have given keys to many developers that hang out on the US forums, and possibly to the developers of very popular addons (ctraid).
Unfortunately for me aguf isn't that widespread yet (haven't been published to major sites) and I can't mark myself on the US forums as I only have an EU account.
I can still hope for a nice user who wishes to have a working unit frame ready in time for BC donates a key to me, but I'm not sure it's going to happen. Everyone wants to check and the new stuff and all, can't blame them!
I'm a bit dazzled by aUF's group sorting atm, but the secure template seems pretty easy to use. You can SetAttribute these stuff on it:
--[[
List of the various configuration attributes
======================================================
nameList = [STRING] -- a comma separated list of player names (not used if 'groupFilter' is set)
groupFilter = [1-8, STRING] -- a raid group number or an uppercase class name
point = [STRING] -- a valid XML anchoring point (Default: "TOP")
xOffset = [NUMBER] -- the x-Offset to use when anchoring the unit buttons (Default: 0)
yOffset = [NUMBER] -- the y-Offset to use when anchoring the unit buttons (Default: 0)
sortMethod = ["INDEX", "NAME"] -- defines how the group is sorted (Default: "INDEX")
sortDir = ["ASC", "DESC"] -- defines the sort order (Default: "ASC")
template = [STRING] -- the XML template to use for the unit buttons
======================================================
--]]
It should save a lot of code, but I'm not sure setting a template is enough to initialize a aUFunit. A 100-lines methode, SecureRaidGroupHeader_Update, will do all the hard work depending on what you set in the attributes.
Target's target is solved by changing aUFunit's UpdateVisibility() to (ugly hack incoming!)
if self.visible == true then
self.frame:Show();
self.frame:SetAlpha(1)
else
self.frame:SetAlpha(0)
end
It also solves the one-shotting stuff in Elwynn Forest = Target frame won't get hidden, you are in combat problem.
You use the Secure unit frame as a template for the ToT frame. Secure frames can't be shown/hidden in combat. You can only change the alpha.
I don't think there is a solution for that one other than using alpha. Actually, what happens if a party member leaves in combat? Will their frame get hidden? I doubt that, hmm.
Not sure what to do about that yet, hard for me to research :)
In aguf there is a unit object per unit frame, we can't have it that way anymore. I'm not even sure the secure anchors work yet, or how to execute code AFTER we're sure that all anchors have been updated. I think Cladhaire knows a lot about this stuff, but he isn't able to answer all of this yet.
Yea, I couldn't figure out a way to convert aUF groups without major rewrites - I'll leave that for you since it's a total reengineering ;)
For now, I'll just just not change party / mess with raids when in combat, or /rl after it (half a second, gotta love the load times without huge data collection mods)
well, couldn't the mod after combat ends run a check on who has left the raid? or keep a table of people that have left? and update the display after leaving combat?
i mean i dont care if during my raid or party someone leaves and the visible portion of the box dissapeares... it would actaully be a bigger reminder to me than "offline"