| 00:09.01 | *** join/#wowuidev Simca (~Simca@c-73-55-2-30.hsd1.fl.comcast.net) |
| 01:14.20 | *** join/#wowuidev Elmoe_ (~Elmoe@24.18.143.238) |
| 02:14.49 | *** join/#wowuidev pompy (~Mike@2601:87:4101:92f0:cca1:4f0f:404f:172d) |
| 02:42.34 | *** part/#wowuidev Seerah (~umsin@c-73-2-180-136.hsd1.ms.comcast.net) |
| 04:13.23 | *** join/#wowuidev Ketho (~Ketho@2a02:a44e:ac87:1:b4cc:3810:cdfc:49f1) |
| 04:30.01 | Ketho | ehehe I like that acronym |
| 05:06.32 | *** join/#wowuidev A-KO (sa@2605:a601:a70a:9400:dd6d:de94:1f71:1c8e) |
| 05:19.16 | *** join/#wowuidev Gethe (~Gethe@98.156.187.225) |
| 05:42.31 | *** join/#wowuidev Shadnix_ (foobar@p4FF9FAB5.dip0.t-ipconnect.de) |
| 05:50.17 | *** join/#wowuidev Andols (~yaaic@m83-185-88-192.cust.tele2.se) |
| 07:16.11 | *** join/#wowuidev Funkeh`` (Funkeh`@WoWUIDev/WoWAce/Ace3/BigWigs/funkeh) |
| 07:29.09 | *** join/#wowuidev Stanzilla_ (~Stanzilla@WoWUIDev/WowAce/Stanzilla) |
| 08:31.45 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 08:51.29 | *** join/#wowuidev Ssateneth (ident@unaffiliated/ssateneth) |
| 10:40.57 | *** join/#wowuidev Andols2 (~yaaic@m83-185-88-192.cust.tele2.se) |
| 10:55.48 | *** join/#wowuidev Breen (~Breen@80.175.117.105) |
| 12:51.51 | *** join/#wowuidev schnoggo (~lonkoenig@c-73-37-220-196.hsd1.mn.comcast.net) |
| 13:19.34 | *** join/#wowuidev schnoggo (~lonkoenig@c-66-41-63-96.hsd1.mn.comcast.net) |
| 14:11.04 | *** join/#wowuidev Tercioo (~Tercioo@181.214.48.23) |
| 16:05.35 | *** join/#wowuidev TSquare (~tomthomps@198.74.35.2) |
| 16:05.35 | *** mode/#wowuidev [+o TSquare] by ChanServ |
| 16:42.00 | *** join/#wowuidev Funkeh` (Funkeh`@WoWUIDev/WoWAce/Ace3/BigWigs/funkeh) |
| 17:34.36 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 17:42.18 | *** join/#wowuidev harl (harl@unaffiliated/harl) |
| 18:17.32 | *** join/#wowuidev ls- (~ls-@ppp-58-11-96-8.revip2.asianet.co.th) |
| 18:22.24 | ls- | @TSquare, sup o7, UNIT_MAXHEALTH doesn't fire at all, again, this bug was re-added w/ 8.1.5, UNIT_HEALTH doesn't fire for vehicles, and fires VERY inconsistently for nameplates |
| 18:24.00 | Funkeh` | yeah we just stick to _FREQUENT as it's avoided countless issues over the years |
| 18:28.15 | ls- | yup, but for some reason health events have been having a lot of issues since 8.0, one bug gets fixed, another one pops up, few patches/hotfixes later previously fixed bug reappears again |
| 18:31.40 | TSquare | ls-: thanks I'll pass it on to our QA |
| 18:35.02 | ls- | they might not notice it because you use _FREQUENT on nameplates and other problematic frames >_> I know it because I once was told that QA didn't notice the issue because frames behaved normally :D |
| 18:43.59 | TSquare | ok, thanks for the heads up. My main QA contact writes addons, so I'll mention that. |
| 19:18.24 | TukuiDevs | <Azilroka> You can make the PlayerFrame break also by turning off the 'predictedHealth' because UnitFrameHealthBar_OnEvent function unregisters UNIT_HEALTH to favor an OnUpdate workaround. |
| 19:56.26 | Stanzilla_ | TSquare: which ones does he write? :> |
| 20:13.23 | TSquare | Stanzilla_: nothing public that I know of :P |
| 20:14.12 | TSquare | ls-: we are seeing UNIT_MAXHEALTH firing in 8.1.5. Do you have a small repro case you can send us? |
| 20:20.25 | ls- | eh? https://hastebin.com/yufakajisa.lua, right now on ptr, mount up, fly up, dismount, and wait. UNIT_MAXHEALTH will never fire https://i.imgur.com/fqkxSbl.png |
| 20:20.31 | ls- | lemme double check it on live |
| 20:21.34 | ls- | the only addon that's enabled is the one that runs that code |
| 20:24.05 | TukuiDevs | <Azilroka> Same on live. |
| 20:27.07 | ls- | yeah, didn't fire either |
| 20:27.09 | TSquare | is your max health changing? I'm not sure it should fire if it's not |
| 20:27.37 | ls- | it usually fires when your health reaches 100% |
| 20:27.48 | TSquare | we tested with a Gladiator Emblem that changes your max health |
| 20:28.03 | TSquare | to be honest, I would have called that a bug |
| 20:28.21 | TSquare | ie: it fires when the max health didn't change |
| 20:28.52 | TSquare | gotta run, I'll check in later |
| 20:29.19 | ls- | but that's how it always was, if you don't use _FREQUENT, w/o _MAXHEALTH your health will get stuck at whatever value it was before reaching 100% |
| 20:29.26 | ls- | that's how health always worked |
| 20:29.58 | ls- | it does fire when you max health changes |
| 20:30.02 | ls- | but that's about it |
| 20:30.08 | ls- | your* |
| 20:32.19 | ls- | it used to fire when your health reached 100%, I guess after all these years someone decided that it's a bug, and "fixed" it :V |
| 20:34.34 | ls- | if that in fact is considered a bug now, at least make UNIT_HEALTH fire when health hits 100% |
| 20:38.29 | Simca | UNIT_HEALTH doesn't fire when health hits 100%? that's weird |
| 20:39.57 | ThiefMaster | did they fix fh last boss only? |
| 20:40.18 | ls- | it doesn't |
| 20:40.20 | ls- | https://cdn.discordapp.com/attachments/219148732380348426/560926051010740227/unknown.png |
| 20:40.27 | ls- | that's how the last tick looks |
| 20:40.37 | ls- | you just get stuck at that value if you don't use _FREQUENT |
| 20:42.24 | ls- | if _MAXHEALTH fires only when max health changes, fine, but at least make _HEALTH work properly, pls T_T |
| 20:42.44 | ls- | UNIT_HEALTH needs a lot of love T_T |
| 20:57.05 | TSquare | yea, UNIT_HEALTH not firing when health changes is not correct either. |
| 20:57.12 | TSquare | Is the 100% case the only one? |
| 20:58.08 | ls- | yeah, if you're talking about _MAXHEALTH |
| 20:58.30 | ls- | but _HEALTH there's really many issues w/ _HEALTH T_T |
| 21:01.53 | TukuiDevs | <Azilroka> @TSquare, Yes, 100% seems to be the only case for UNIT_HEALTH. It used to not return 0 or 1 for Dead / Ghost |
| 21:02.26 | TukuiDevs | <Azilroka> The latter seems to be fixed. |
| 21:04.05 | ls- | as for UNIT_HEALTH, if you attack a unit w/o targeting, e.g., drop an aoe, drop blizzard on a bunch of units, only _FREQUENT will be firing, and only after you target a unit, _HEALTH will start firing for that unit |
| 21:04.13 | ls- | tracking via /etrace |
| 21:05.26 | nebula | so if you attack without targeting, what unit are you excepting it fire events for? |
| 21:05.47 | ls- | I'm talking about UNIT_HEALTH not firing for nameplates |
| 21:06.48 | nebula | that makes more sense :p |
| 21:07.04 | ls- | https://i.imgur.com/jPj5coB.gif |
| 21:07.35 | ls- | here we should see 5 _HEALTH and 5 _FREQUENTS, but only 1 _HEALTH appears |
| 21:08.01 | ls- | and the one that appears is the one I targeted |
| 21:15.04 | ls- | one of the best places to repro the issue is in the warspear, there's a bunch of stacked target dummies, so you can drop aoes there w/o being attacked and whatnot |
| 21:30.26 | TSquare | is this only for nameplates? |
| 21:31.11 | TSquare | is it only other npcs? |
| 21:31.19 | TSquare | we see it working for the player |
| 21:31.39 | ls- | other npcs |
| 21:31.52 | ls- | I mean, you can't drop an aoe on yourself and dmg yourself |
| 21:32.10 | ls- | UNIT_HEALTH also doesn't fire for vehicles |
| 21:32.25 | ls- | when you jump into a vehicle, _HEALTH won't fire |
| 21:33.00 | ls- | all nameplate units in that gif are target dummies, 2 tanks + 3 dps, personal one was disabled |
| 21:34.16 | znf | hey, it's almost april 1st |
| 21:34.24 | znf | will diablo immortal launch? |
| 21:36.17 | TukuiDevs | <Azilroka> d2:hd |
| 21:42.04 | ls- | @TSquare, yeah, double checked it jic, _HEALTH fires for the player's nameplate's unit w/o any issues, so it applies to other nameplates both friendly and hostile, if you stand next to healers' dummies, that constantly regen/lose some hp, only _FREQUENT fires |
| 21:42.43 | ls- | but as soon as you target them, even stop targeting them, _HEALTH will keep firing properly |
| 21:42.57 | ls- | together w/ _FREQUENT |
| 21:43.27 | ls- | even after you stop targeting them* |
| 21:43.29 | ls- | ugh... |
| 21:53.04 | Funkeh` | ls-: that sounds like the issue we had back in... 5.x? with boss frames. Unless you target the boss, it wouldn't fire for that unit |
| 21:53.20 | Funkeh` | That's when we said fuck it and swapped everything to frequent |
| 21:53.29 | Funkeh` | It has consistenly been a good decision :D |
| 21:53.36 | ls- | rip |
| 21:58.21 | Elmoe | Funkeh`: yes I can second this, in VuhDo I only listen update boss unit health on UNIT_HEALTH_FREQUENT, UNIT_HEALTH never seemed to work properly |
| 21:58.55 | Elmoe | I don't do anything with nameplate units though so no experience there |
| 21:59.22 | ls- | @TSquare looks like this issues is more widespread than I thought :D |
| 21:59.38 | ls- | vehicles, nameplates, and bosses |
| 21:59.40 | ls- | oof... |
| 22:00.01 | ls- | at this point I wonder if it fires for raid frames correctly :V |
| 22:00.06 | ls- | units* |
| 22:00.19 | Funkeh` | I would also second what was said earlier. maxhealth change doesn't sound like a bug, but not firing a health update at full health sounds like the bug to me |
| 22:00.31 | Elmoe | in VuhDo I started listening and updating on both a while back just to be safe, its inefficient but seems to ensure timely and accurate health updates |
| 22:00.33 | Elmoe | re: raid unitsa |
| 22:00.49 | Funkeh` | although it is weird that they renamed UNIT_POWER to UNIT_POWER_UPDATE but didn't rename UNIT_MAXHEALTH to UNIT_MAXHEALTH_UPDATE |
| 22:01.16 | *** join/#wowuidev Ketho (~Ketho@2a02:a44e:ac87:1:b156:aad:40db:1df0) |
| 22:01.22 | ls- | you meant UNIT_HEALTH > UNIT_HEALTH_UPDATE, right? |
| 22:01.48 | Funkeh` | no |
| 22:02.00 | Funkeh` | did they rename that also? |
| 22:02.10 | nebula | weirdo |
| 22:03.04 | ls- | no, they didn't |
| 22:03.23 | Funkeh` | that's waht I thought, I always saw it as a strange decision |
| 22:03.27 | ls- | but given that UNIT_POWER was renamed, I'd expect UNIT_HEALTH to be renamed accordingly as well |
| 22:03.31 | Tercioo | i'm using UNIT_HEALTH_FREQUENT and UNIT_MAXHEALTH, it works just fine for me |
| 22:03.50 | Funkeh` | frequent isn't the problem being discussed |
| 22:05.03 | Tercioo | that's the reason why i say that works for me in case somebody wants a temp workaround :) |
| 22:05.06 | Elmoe | but to Tercioo's point, if UNIT_HEALTH is being problematic for nameplate units can't you just use UNIT_HEALTH_FREQUENT instead? |
| 22:05.18 | Elmoe | I believe Tercioo means he simply does that for Plater |
| 22:05.21 | Elmoe | as a workaround |
| 22:06.19 | ls- | sure, but it doesn't mean that existing issues w/ events adn/or the event system shouldn't be brought up |
| 22:06.29 | TukuiDevs | <Azilroka> UNIT_HEALTH should be firing at 100% regardless.. |
| 22:06.39 | ls- | using OnUpdate is a nice workaround as well :V |
| 22:06.41 | Elmoe | yeah I mean boss units seem to have been broken for years shrug |
| 22:06.46 | Funkeh` | yes, agreed it should fire at 100% |
| 22:06.48 | *** join/#wowuidev Andols (~yaaic@78-70-44-4-no170.tbcn.telia.com) |
| 22:07.00 | Elmoe | I'm sure its already in some backlog somewhere hah |
| 22:08.39 | TheDanW | renaming it to UNIT_POWER_UPDATE was to resolve a name collision |
| 22:09.02 | TheDanW | would have preferred to keep it |
| 22:09.12 | ls- | ah, one mystery was solved :D |
| 22:14.16 | Tercioo | <Elmoe> that's correct, UNIT_HEALTH was never reliable in my experience |
| 22:15.16 | Tercioo | but also can't register UNIT_HEALTH and UNIT_HEALTH_FREQUENT on the same frame, some weird bug make the amount of events triplicate |
| 22:15.22 | ls- | let's just remove the current UNIT_HEALTH, and rename _FREQUENT to _HEALTH :V |
| 22:18.36 | Elmoe | Tercioo: hmm interesting, this I did not know and I currently do this |
| 22:18.51 | Elmoe | Tercioo: any clue if this is a recent regression? |
| 22:25.40 | Tercioo | I dunno, saw this early this year |
| 22:28.50 | Elmoe | thanks for the tip |
| 22:34.59 | Chipzz | https://github.com/tomrus88/BlizzardInterfaceCode/blob/master/Interface/AddOns/Blizzard_ArtifactUI/Blizzard_ArtifactPerks.lua#L560 has :Play with 2 paramaters, but the only official documentation I could find on :Play() (Blu post from long ago) doesn't document these 2 parameters. The 2nd seems to be soms kind of offset, but not sure what units it's supposed to be, and the 1st is entirely unclear to me |
| 22:35.06 | Chipzz | anyone has any insight? |
