Acapela's Portal - Bug Comments (wowinterface.com)

Not able to target - yeah, this was...

acapela — Thu, 29 Oct 2009 01:41:55 +0000

yeah, this was definitely a bug, and hopefully is now fixed. thanks to you, and everyone else, who reported this. (Interface: Aloft (Beta) | Bug: Not able to target)

Not able to target - It looks like that this...

And — Thu, 22 Oct 2009 09:19:25 +0000

It looks like that this bug has been ackonowledged, as reported into the Comments section and it looks to be fixed in Aloft-2.8.11a-1435. Thank you! (Interface: Aloft (Beta) | Bug: Not able to target)

Packing Height changes clickable area - should have added: what...

acapela — Sat, 26 Sep 2009 00:06:58 +0000

should have added: what i am calling the "invisible" frame is an actual UI object, which Aloft can identify, and which has a height/width that Aloft can change. the nameplate health bar, the cast bar, and the various other parts of nameplates that Aloft creates or controls, are all "children" of this "invisible" frame. the height/width of this "invisible" frame is what Aloft uses to control "packing" height/width, and is what Blizzard uses to control tiling or packing of nameplates on the screen. what i am calling the "magic area" is exactly that: "magic", not an actual UI object that Aloft can locate and change. it seems to exist only in Blizzard's "imagination" (or in their mouse sensitivity control algorithm, or whatever :)). (Interface: Aloft (Beta) | Bug: Packing Height changes clickable area)

Packing Height changes clickable area - yeah, the invisible area...

acapela — Sat, 26 Sep 2009 00:01:38 +0000

yeah, the invisible area seems to be outside addon control. i can go experiment with this again, to make sure. as described in earlier posts, there is an underlying "invisible" frame on each nameplate that is used for this tiling. the size/placement of this "invisible" frame doesn't seem to have any influence on mouse sensitivity. it appears that each nameplate has some sort of ADDITIONAL "magic area" (i.e. in addition to this "invisible" frame), which is not an explicit component of the nameplate itself, but that needs to overlap (or otherwise relates to the placement of) the nameplate health bar (i.e. specifically the health bar) in order to the nameplate to respond to the mouse. if you move the health bar too far out of this "magic area", whether by explicitly sizing/placing the health bar, or changing the "packing" height/width of the nameplate (such that the health bar ends up moving in order to stay in "alignment" with the "invisible" frame), the nameplate quits responding to the mouse. i suspect (but of course cannot prove) that Blizzard is doing some sort of simple screen placement arithmetic, to compare location of the health bar where it actually appears on the screen to the location of where it "should" appear on the screen (perhaps relative to the placement of the character model on the screen), and disabling the nameplate if it is too far "out of place". (Interface: Aloft (Beta) | Bug: Packing Height changes clickable area)

typo in Aloft\AloftHealthBar\AloftHealthBarLocale.lua - thanks for spotting...

acapela — Fri, 25 Sep 2009 23:40:55 +0000

thanks for spotting this. i will go dig into it. (Interface: Aloft (Beta) | Bug: typo in Aloft\AloftHealthBar\AloftHealthBarLocale.lua)

AloftHealthBar.lua error with 'GetTotemExceptionColor' - yeah, i believe this is...

acapela — Wed, 16 Sep 2009 23:31:12 +0000

yeah, i believe this is now fixed (in Aloft-2.8.8 and later). the GetTotemExceptionColor() method was implemented in the AloftVisibility module (which users can disable), but also invoked by Aloft's health bar coloring functionality (which is always on). as a consequence, the method may not always be there. so, i added a check in the health bar area to see if the function is available before using it. (Interface: Aloft (Beta) | Bug: AloftHealthBar.lua error with 'GetTotemExceptionColor')

AloftHealthBar.lua error with 'GetTotemExceptionColor' - Aloft-2.8.7.1255 Came...

Dridzt — Mon, 31 Aug 2009 22:26:52 +0000

Aloft-2.8.7.1255 Came here to report same issue. Following error was spammed ad infinitum while fighting the Faction Champions (3rd encounter in Trial of the Crusader raid) when the Shaman Boss started dropping totems. Aloft-2.8.7.1255-enUS\AloftHealthBar\AloftHealthBar.lua:338: attempt to call method 'GetTotemExceptionColor' (a nil value) Aloft-2.8.7.1255-enUS\AloftUnitidData\AloftUnitidData.lua:155: in function `UpdateData' Aloft-2.8.7.1255-enUS\Aloft\Aloft.lua:131: in function `UpdateAloftData' Aloft-2.8.7.1255-enUS\Aloft\Aloft.lua:792: in function `OnNameplateShow' Aloft-2.8.7.1255-enUS\Aloft\Aloft.lua:1033: in function `SetupNameplate' Aloft-2.8.7.1255-enUS\Aloft\Aloft.lua:391: in function `ProcessChildFrames' Aloft-2.8.7.1255-enUS\Aloft\Aloft.lua:402: in function (Interface: Aloft (Beta) | Bug: AloftHealthBar.lua error with 'GetTotemExceptionColor')

Combat Text Mistakes Physical for Holy Damage - wanted to follow...

acapela — Sat, 22 Aug 2009 15:04:19 +0000

wanted to follow up. did some work on this subsystem, and presumably a lot of these issues have been dealt with (i am seeing school colors now in my own use). if you get a chance to confirm, let me know if things are working for you. (Interface: Aloft (Beta) | Bug: Combat Text Mistakes Physical for Holy Damage)

Packing Height changes clickable area - Forgot to add in...

jtbalogh — Fri, 21 Aug 2009 23:46:30 +0000

Forgot to add in previous post that my packing height is 8, width is zero. Was okay like that for the past year, but patches might be affecting its reliability now. (Interface: Aloft (Beta) | Bug: Packing Height changes clickable area)

Packing Height changes clickable area - Ya, FAQ mentioned it. I...

jtbalogh — Fri, 21 Aug 2009 23:44:26 +0000

Ya, FAQ mentioned it. I noticed something worse after the latest patches. The invisible area is not only vertically small, but now also horizontally. For testing, I can barely click on a critter on the ground especially when moving. Clicking most places on the name plate is not helping. Do you think that inivisible area is out of our control too ? Thanks (Interface: Aloft (Beta) | Bug: Packing Height changes clickable area)

Combat Text Mistakes Physical for Holy Damage - this whole subsystem...

acapela — Sun, 24 May 2009 23:31:46 +0000

this whole subsystem needs review. i will add this to the list of things i investigate. (Interface: Aloft (Beta) | Bug: Combat Text Mistakes Physical for Holy Damage)

Packing Height changes clickable area - sorry for the delay...

acapela — Sun, 24 May 2009 23:30:40 +0000

sorry for the delay responding to this. yes, packing height/width affect mouse sensitivity. this seems to be an artifact of something Blizzard has done, under the covers, unique to nameplates. i would need to go look, but i believe this is mentioned in the Aloft FAQ. packing height/width actually control how closely nameplates are "tiled" or "packed" when there are a lot of them visible. Blizzard moves nameplates around to make certain they all appear on the screen (at the expense of not placing them next to the corresponding unit). these packing dimensions control how much empty screen area Blizzard leaves in between nameplates when they are tiled together onto the screen. there is an underlying "invisible" frame on each nameplate that is used for this tiling. the visible parts of the nameplate are centered within this. as far as i can tell, if the size of this "invisible" frame changes, such that the center of it moves out of some magic area that Blizzard considers "appropriate", the nameplate stops being sensitive to the mouse. i have not found any sort of workaround yet. (Interface: Aloft (Beta) | Bug: Packing Height changes clickable area)

AloftStackedPoints restricted to certain classes - alright, i can expand...

acapela — Thu, 27 Nov 2008 18:23:21 +0000

alright, i can expand this to all classes. i have been in groups where people (not of normal pet-owning/summoning/controlling classes) using hotbar mods suddenly need to control another unit, and they have disabled their pet bars. so i understand the basic phenomenon. however, if the origin unitid becomes something other than "player" in these circumstances, i will need to know that. these days, the Blizzard "GetComboPoints()" function requires an origin unitid (and Aloft is essentially hardcoding "player"). this should not affect lacerate/sunder, these parse debuffs off of "target" via the Blizzard "UnitDebuff()" function, which flags in various ways if a debuff is not owned by the querying player. i mention this about unitid "player" because LibRoster just recently added "vehicle" to the list of unitids it handles. i am second-guessing myself here, not having a way to test things like "vehicle" (which i assume could relate to this situation in which the player mounts on some other entity, and together they become something no longer the "player") under controlled circumstances in a raid context. i don't know if "vehicle" and "player" are interchangeable in any way, or what. so, even after i have opened this class restriction up, please observe the results and let me know whether you are seeing combo points the way you would expect to in this encounter. if not, i will have to figure out a way to detect when the player has been transformed into some sort of joint entity, and switch over to using unitid "vehicle" (or whatever) instead. as for the other side of this relationship, the target unitid: Aloft always assumes "target" because the only nameplate Aloft can definitively identify under all circumstances is the nameplate of the player's current target (based on nameplate alpha, among all those currently visible). switching targets with latent points stacked (combo/lacerate/sunder) will pick up the current point value just fine, and display it, but display on several nameplates at once is not going to be reliable. i am guessing "target" remains valid regardless of what happens to the "player"... if a user has something targeted, the unitid "target" will be valid. (Interface: Aloft (Beta) | Bug: AloftStackedPoints restricted to certain classes)

Visibility problem - Death Knight not counted as in "group" - this turned out to be a...

acapela — Mon, 17 Nov 2008 02:43:31 +0000

this turned out to be a group unitid propagation issue. took a little work to sort out the data lifecycle issues that were causing it, but things now seem to be working (in the sense that this option generally has the desired effect). only one artifact remains, and it may be intractable, at least at my level of WoW/LUA development expertise: when Aloft disables a particular nameplate, it hides it and quits tracking it. when you invite someone into your group while their nameplate *should* be visible (would be visible if you enabled "all" friendly players), you have to go out of range (such that Blizzard recycles the graphics objects) and then return into range to get the nameplate to appear. i have some ideas i want to try, to work around this, but i am going to release with this artifact still active. as for the rest of it: fiddling the option while affected nameplates are in range, having a visible char leave the group while the option is active, and etc... all of that now works. the nameplate is not permanently "lost" never to be seen again. (Interface: Aloft (Beta) | Bug: Visibility problem - Death Knight not counted as in "group")

I can't stop friendly pets from being visible - i cannot reproduce...

acapela — Mon, 17 Nov 2008 00:20:13 +0000

i cannot reproduce this... but i have done quite a bit of work on your Death Knight problem (which was a similar problem, as it turns out... a problem with propagating unitids properly when joining/leaving groups), and Phanx's nameplate color problem, and i may have already cleaned up whatever defect was causing this. with a hunter in group, i am able to get rid of the hunters pet (from the hunter's perspective), get rid of the hunters pet (from everyone else's perspective), and with the hunter not in group i can do the same... all depending on which pet/NPC option i fiddle under "Aloft>Visibility". (Interface: Aloft (Beta) | Bug: I can't stop friendly pets from being visible)

Visibility problem - Death Knight not counted as in "group" - i was able to reproduce...

acapela — Sun, 16 Nov 2008 18:13:54 +0000

i was able to reproduce this. setting Aloft "Visibility" options appropriately and then reloading the UI did not reproduce this, but fiddling Aloft "Visibility" options on the fly (which should work but does not) did reproduce this. working on a fix. (Interface: Aloft (Beta) | Bug: Visibility problem - Death Knight not counted as in "group")

Nameplate Health Text shows 0% before unit is dead - yeah, for...

acapela — Wed, 12 Nov 2008 01:57:08 +0000

yeah, for "", this could well be the case. i could see how for a boss with a huge amount of health, reaching "0%" could happen well before the boss is anywhere actually on the point of death (could have quite a few HPs left). Aloft actually doesn't use UnitHealth() / UnitHealthMax(). one reason is that Aloft doesn't always have a unitid to use to drive those functions (i.e. in a multi-target/AOE situation), and another reason is that (now, in 3.0.2+) the the Blizzard StatusBar object that comprises the health bar in the underlying/default Blizzard nameplate "correct" health values in it, and Aloft just uses those (posted via the "OnValueChanged" event handler and gathered via StatusBar:GetMinMaxValues(), which is all a lot easier and more efficient that a health estimation addon). but Aloft does calculate fractional health itself, from these values... so i will go make certain that ceil() is used properly in that calculation, just as you suggest. (Interface: Aloft (Beta) | Bug: Nameplate Health Text shows 0% before unit is dead)

Not a bug but can you tweak pretty please =) - Thx a lot! Really...

tomytomy — Tue, 11 Nov 2008 05:09:50 +0000

Thx a lot! Really appreciate it =) (Interface: Aloft (Beta) | Bug: Not a bug but can you tweak pretty please =))

ALOFT_SHOW_ALL_NAMEPLATES binding does not work - Yup, fixed indeed. :)

Gnarfoz — Sun, 09 Nov 2008 02:22:59 +0000

Yup, fixed indeed. :) (Interface: Aloft (Beta) | Bug: ALOFT_SHOW_ALL_NAMEPLATES binding does not work)

ALOFT_SHOW_ALL_NAMEPLATES binding does not work - i believe i just fixed...

acapela — Sun, 09 Nov 2008 01:07:10 +0000

i believe i just fixed this one (noticed it in my testing). just now released (Aloft 2.4.3-261). thanks for the report! (Interface: Aloft (Beta) | Bug: ALOFT_SHOW_ALL_NAMEPLATES binding does not work)