This site works best with JavaScript enabled. Please enable JavaScript to get the best experience from this site.
Hello!
I've noticed that sadly Decursive does not detect bleeds, which evoker can dispell with Cauterizing Flame. During my progression on Forgotten Experiments Mythic in Aberrus, I have to rely on my guildmates to tell me who has a debuff or checking Blizz frames on the left. Clicking on the addon squares DOES work and removes the bleed (although it claims there is nothing to cure), but it doesn't display it at all.
Example:
(you can see on raid frames that multiple people have Rending charge bleed debuff on them, but Decursive doesn't detect these as dispellable)
The same happens with any bleed in the m+ dungeons actually. It only detects curses (since CF can remove disease, curse, poison and bleed).
Would appreciate the update!
I haven't checked recently but from my knowledge the only way to detect bleed debuffs is to maintain a comprehensive list of them as it doesn't have its own type like magic, curses etc...
@author: heres an approach I came up with for bleed support. File diff at https://github.com/teelolws/decursive/commit/3789b3c1db8edcc2b9619adc5c878ebaab5f6257
I based the approach on this weakaura https://wago.io/WjLiBM_It
Since there is no "Bleed" debuff category, instead it scans the tooltip description of the debuff for "bleed". Sure its not perfect but its better than nothing. From there, that WA adds a custom list of spell IDs that don't have "bleed" in their description but still count as bleeds.
@author I have another suggestion that might be a quick workaround to help mainly in usecases like the one above: to have an option where to add a list of spellIDs to consider bleeding effects. In this way it's up to the user what to configure and to keep that list up to date with what they need. Otherwise with the approach suggested by Teelo you should make sure to translate the word "bleed" or the tooltip parsing would fail for languages other than English.
Thank you both for your suggestions. and thanks Teelo for your implementation details. The problem with the bleed scanning as pointed out by Xadras is that it's localization dependent (we could also add an option where it would be the user's responsibility to translate bleed).
I had another idea recently but I'm not sure if it's possible: Decursive is already scanning the combat logs for various reasons so maybe it could detect bleed effects through that mean but I haven't actually tested if this is at all possible (is there a way to identify bleed effects just using the combat log).
I would also need several things:
- An NPC who is easily accessible outside of any instances who reliably cast a bleeding effect. (Like Stalvan Mistmantle in Classic who can cast a curse what ever your level is)
- Examples of combat logs where bleeding effect occur (/combatlog command)
This approach would be very reliable (if possible) and transparent to the users.
@author...i'm not sure about an NPC who is applying bleeding effects, but for combat logs you can easily check any raid logs in warcraft logs for The Forgotten Experiments (Mythic difficulty)....here the first occurence in warcraft logs for that boss https://www.warcraftlogs.com/reports/PBnWka6mMDKLqty4#fight=43 hope this helps
Solution for the localisation issue: use the global string ENCOUNTER_JOURNAL_SECTION_FLAG13
Call tolower() on both the search string and search key.
I've started to work on this today, the combat log is unfortunately a dead end.
So I'll use a mix of Teelo's work and Xadras' suggestion.
@Teelo: I wanted to pull from your repo so that Github would give you credit for your work but you did not do a proper fork... I'll credit you in the changelog. If you can fix this today I might have still time to pull your changes.
On it.
Thanks, I've pulled your changes and made a few modifications, I did things a little differently to grab the spell descriptions in the end, avoiding the tooltip.
I've added a new control panel under the curing options where detected spells are added, you can add your own also.
Instead of scanning for 'Bleed' I decided to scan for Physical instead because it seems half of the spells that you preconfigured did not contain Bleed in their descriptions but always had 'Physical' (except one 'Splitering shards' which is only dealing arcane damage, is this considered a Bleed spell nonetheless?).
Please everyone, test and report any problem here.
Yeah that Splintering Shards is dispellable with Cauterizing Flame, even though it doesn't say Bleed or Physical. Theres no consistency. But string matching both "Bleed" and "Physical" should catch almost all of them.
Does the Spell description always match the Debuff description?
I also noticed a small mistake with your changelog push.
The changelog was committed too fast, it should be OK now.
Matching for 'Physical' seems to catch all the bleed effects of your list. We'll see for now, if that's not enough I'll make the identifier input in the option panel multiline so that several keywords can be added.
The spell description seems to always contain parts of the debuff description so it should be OK.
I've just pushed a new alpha with many little fixes.
@archarodim I just tested the latest alpha with an hunter friend and a few things happened:
I hope these debug info will be useful to you (my client is in Italian...just in case but as far as i understood from the committed code it shouldn't be an issue as it's using a therm from the journal and therefore already localized)
Thanks for your test and the report. This should be fixed in the latest alpha, please try again and tell me the results.
The latest alpha is also matching for 'Bleed', Teelo found several spells that did not have Physical but did have 'Bleed'.
@archarodim more feedback for you...it's working fine repeating the previous experiment with my hunter friend...one note though...it was tracking bleed even if i didn't have it selected in the curing options and i was still able to dispell it through decursive. Wondering if that curing option should be enabled by default when detecting a spell that could cure bleed.
Side note...i noticed that the mouse bindings might need to have a 7th priority dropdown considering the potential 7 dispell types that could happen...but probably it's very unlikely to happen...maybe just for completeness
Great! Thanks for the feedback. I've considered activating tracking only when a spell is available but I decided to leave it on at all time for now to see what happens. I'm curious to know how many such debuffs are detected. If you can report after some time on the size of the list that would be great.
About the priorities, it would mean that a player could have 7 different abilities to clean debuffs, I'm not sure this would happen since a curing ability usually takes care of several types of debuffs.
yes that makes sense...just thought you added 6 because there were 6 different types of cure options. Anyway i have a question: does it discover bleed effect even when i don't have a spell to cure bleeding? just wondering as i don't always have that spell talented and i'm wondering if it's updating the discovery list anyway
Sorry I thought that it was what you were asking me in you previous message (so yes it does discover bleed effects even when there is no spell configured to cure bleeds). But then I did not understand your message, what did you mean by: "it was tracking bleed even if i didn't have it selected in the curing options" ?
I meant i did not have the bleed checkbox checked under cure options, but it was sending the alert to cure it anyway
hmm this is not normal, did you uncheck the box while still in combat?
Nope...i never checked it actually...it's still unchecked...didn't touch at all that one
could you post a screenshot of your cure option panel as it is now?
Sure...here they are...
With the spell to cure bleed:
without the spell to cure bleed:
also just noticed that Disease and Curse are priority 13 and 12...but till before installing latest version they were 3 and 2 instead
Thanks for the screenshot. There were several problems:
1 - the fact that bleed was unchecked (by default all abilities should be enabled)
2 - the fact that bleed effects were still reported despite the type being unchecked. Actually it was true for any type. This was a new bug introduced since the last release.
These problems are fixed in the latest alpha. But note that in your case and for all people who used the previous alpha, Bleed will stay unchecked, so you'll have to check it manually (your current unchecked status was saved in your profile...).
The numbers in blue are when the spells have gone missing, this is a new behavior since the last tagged release. Decursive will remember your priorities if you loose a spell as long as you don't change the priorities manually after loosing the spell (so if the spell comes back your former priorities also come back). The number should stay green as long as you don't change those settings. If you change them the new priorities become permanent and the missing spells' priority gets a +10 to their former priority.
Glad that i could help finding those bugs...may i ask if you can help me resetting the priority so that it would be selected as if i never touched it? I tried checking in the saved variables file...but can't get what i would reset and how.
also FYI i just tried the raid boss and it didn't track the bleed...i'm trying to add it manually now
To reset the priority settings to their defaults you can type the 3 following commands in your chat:
/run LibStub("AceAddon-3.0"):GetAddon("Decursive").db.class.CureOrder = {}/run LibStub("AceAddon-3.0"):GetAddon("Decursive").db.class["CureOrder-"..(GetSpecialization or GetActiveTalentGroup)()] = nil
/reload
Once you've added the bleed debuff manually, can you share the spell id you added here?
Thanks for that. The spell id i added is 406365...but while looking for it i found many others that are pointing to the same ability...like 406358...actually 406358 is the first ability i found on wowhead and then i got to the other number clicking on the description text.
I also noticed that the string used for Phisical is actually between parenthesis which in the tooltip are not there. And i believe it's not catching it not only for the parenthesis, but also because it's singular (in italian when the tooltip is saying "x amount of phisical damage"...the word phisical is plural...and this is falling under the problems about localization that would be a nightmare)
in that case, you can add the plural of physical in Italian to the keywords input box or keep the radical of the word.
I do not understand what you mean about the parenthesis though. Do you mean that the words you see in the keyword box are between parenthesis?
yes correct...i see something like "(Phisical)"
ok can you type the following command in your chat and tell me what you see:
/dump _G.STRING_SCHOOL_PHYSICAL
Also do you see a question mark near the debuff name of the existing debuff? If the keywords are detected in the description, they are highlighted in green.
/dump _G.STRING_SCHOOL_PHYSICAL prints out [1]="(Fisico)"
About the red/green question mark...i'm pretty sure it stayed red all the time
The parenthesis should not be a problem, (they'll be automatically removed in the next alpha nonetheless).
Now, in your case since in Italian plurals change the last letter, you could try to replace "(Fisico)" with "[Ff]isic[oi]" so it will match both fisico and fisici. (edit: this could not work with 2.7.9.3-19 you need to update to 2.7.9.3-23)
Note that there is a little bug with the question marks the first time you open the option panel just after login when the spell descriptions are not yet available that can make all the spells getting the question mark.
The question mark should disappear if one of the configured keywords is found in the description and the matching terms should be highlighted in the right panel where the spell descriptions are displayed.
great thanks...just a question you mentioned to make [Ff]...does it mean you don't compare all in lower case? is the search case sensitive? my understanding was it wasn't
Yes this was due to a limitation of 2.7.9.3-23 where making the pattern case insensitive would corrupt user added character classes so it just ignored patterns containing [] pairs.
This is fixed in 2.7.9.3-25 so now you can just use Fisic[oi] (internally it will transform the pattern into [fF][iI][sS][iI][cC][oOiI])
Great...i'll check next time i'm at that boss...i'll remove the added spell id and see if with that pattern is catching them or not....one more question...is it a full regex i can add or just the []? like can i use My(abc|def) to match either Myabc or Mydef?
no Lua regex are very limited unfortunately: https://www.lua.org/pil/20.2.html
@author just checked the fight removing the spell i manually added last time and it worked fine...it added that spell back in the discovery list
great thanks for the feedback!
Has anyone got any feedback since the release? Are things working as expected?
To post a comment, please login or register a new account.