# Forum > World of Warcraft > World of Warcraft Bots and Programs > Probably Engine >  Bug Reports / Suggestions!

## Hackinte

This is the official bug report and feature request thread, please follow the post template below.




> *Bug:* PE doesn't work in negrand for horde.
> *Build:* 6.0.3r10
> 
> *Details:*
> PE doesn't allow mounted combat while in negrand on a horde character.





> *Feature:* Allow for unit.area().friendly
> *Details:*
> Let us check for friendly units in an area.


I will reply with quote to bug reports and feature requests with status updates.

----------


## boxo

haha, well, three things that would be super...

Feature: Allow for unit.area().friendly
Details:
Let us check for friendly units in an area.

Feature: lowest.withbuff(x)
Details:
For better healing, a way to cast hots like riptide on the lowest unit that doesn't already have it.

and

Feature: Dispel / Interrupt whitelists
Details:
Create custom tables for things to interrupt, and only interrupt those things.

----------


## zeldaboch

Quote Boxo
And if possible, add some example/eplanation for conditions in the conditions list

----------


## ImogenOC

> Quote Boxo
> And if possible, add some example/eplanation for conditions in the conditions list


Still building that wiki  :Smile:  
Considering setting up an anon tip jar to help us get a server back up for other resources.

----------


## lg40

Would be nice if 

Balance.moon 
Balance.Sun 

We're fixed

----------


## zeldaboch

what about runes condition? In the PE core there are 2 function "runes.depleted" and "runes.count" that are not listed in the condition list.
I have tried to use them both and seems they work good except for death ones.

{"49998",{"player.runes(death).count >= 2"},"target"}, -- Death Strike

this don't work if i have only 2 death runes

----------


## Kellogg

player.behind doesn't seem to work,

----------


## zeldaboch

> player.behind doesn't seem to work,


Also infront and the function about vengeance

----------


## Mackdaddy2887

copy/past from my previous post. 

Build: CURRENT (as of 12/27)





> Also..
> 
> TO whom it may concern:
> 
> modifier.last(insert spell here)
> 
> Doesnt work per se, the (insert spell here) part doesnt work right. for instance:
> using this test code:
> 
> ...

----------


## MrBrain1

> Would be nice if 
> 
> Balance.moon 
> Balance.Sun 
> 
> We're fixed


this  :Smile: 
no good working balance rotation out there.

----------


## Mackdaddy2887

> this 
> no good working balance rotation out there.


until this is fixed, dont you have a buff corresponding to which side of the bar your on? Also, dont you get a 4s or so buff when reaching an end? Make a rotation that uses those buffs as conditions as a work around until the balance conditions are fixed

----------


## MrBrain1

> until this is fixed, dont you have a buff corresponding to which side of the bar your on? Also, dont you get a 4s or so buff when reaching an end? Make a rotation that uses those buffs as conditions as a work around until the balance conditions are fixed


yea you get a buff

Lunar:

Lunar Peak: Lunar Peak - Spell - World of Warcraft

Solar: 

Solar Peak:Solar Peak - Wowhead Search

the buff is used up right after you get it with a moon or sunfire.

after the peak eclipse needs 5 s to automaticly switch to the other side with the talent (standard talen Euphoria)

----------


## Kellogg

> player.behind doesn't seem to work,


*Bug: player.behind doesn't work
Build: 6.0.3r11

Details:
player.behind and .infront don't seem to work.

This is using FH, Not sure if it is a PE or FH problem.*

----------


## Produktionshuset

Bug:

Crash PE totally on Orgron Twins using Nocarriers monk profile - seems to be when the Boss is doing its whirlwind routine.

Interface\AddOns\Probably\system\conditions\core.lua:734: attempt to perform arithmetic on local 'endTime' (a nil value)
Count: 99

Call Stack:
[C]: ?
Interface\AddOns\Probably\system\conditions\core.lua:734: in function `casting.delta'
Interface\AddOns\Probably\system\conditions\core.lua:771: in function <Interface\AddOns\Probably\system\conditions\core.lua:767>
Interface\AddOns\Probably\system\core\dsl.lua:90: in function <Interface\AddOns\Probably\system\core\dsl.lua:20>
(tail call): ?
Interface\AddOns\Probably\system\core\parser.lua:271: in function `table'
Interface\AddOns\Probably\system\timers\rotation.lua:71: in function `cycle'
Interface\AddOns\Probably\system\timers\rotation.lua:130: in function `event'
Interface\AddOns\Probably\system\core\timer.lua:16: in function <Interface\AddOns\Probably\system\core\timer.lua:11>

----------


## ossuaire

> Bug:
> 
> Crash PE totally on Orgron Twins using Nocarriers monk profile - seems to be when the Boss is doing its whirlwind routine.
> 
> Interface\AddOns\Probably\system\conditions\core.lua:734: attempt to perform arithmetic on local 'endTime' (a nil value)
> Count: 99
> 
> Call Stack:
> [C]: ?
> ...


I think it's a problem with the kick fonction, when I disable this fonction the rotation doen't freeze.

----------


## Greymalkin

*Bug:* Typo in checkChanneling of the nested Interrupt code
*Build:* 6.0.3r11

*Details:* 
The recent inconsistent issues with interruptAt and interruptsAt appear to boil down to a typo on line 709 of Probably/system/conditions/core.lua The "name" variable has an extra underscore behind it which is not letting the next line query its value. Since "name" on line 710 is getting a value returned from somewhere (I ended up tracking the "name" variable down to an old add-on bleeding variables to global which is most likely why some PE users had the issue and some didn't if they had old add-ons running) it is cascading incorrect returns, i.e. checkChanneling line 710 to checkCasting line 717 to casting.delta line 732 (where startTime, endTime, notInterruptible are being populated as nil) to casting.delta line 733 evaluating as true to casting.delta line 734 trying to evaluate castLength as (nil - nil) / 1000. This is where all of the reported "attempt to perform arithmetic on local 'endTime' (a nil value)" errors are originating from. 

*Fix:* 
Just remove the trailing underscore from the "name" variable in the checkChanneling function.

----------


## Greymalkin

*Bug:* Generic focus logic for parsing "tank" ?
*Build:* 6.0.3r11

*Details:* 
I'm not sure if this is actually a bug or if I'm just completely missing the reason for logic here. (I suspect this is left over from the quick build of the healing framework from way back whenever, but I could be wrong.) I cannot see the use of "tank" as the unit for any target other than a healable/friendly one. The first step of the ProbablyEngine.raid.tank() function will check for a healable focus and return it as the result if found. However, the code in both the dsl.lua and parser.lua files checks for the existence of a focus and returns it regardless of if the focus is a friend or enemy before the ProbablyEngine.raid.tank() function is called. This becomes an issue if the player is a healer assigned to chain CC an enemy mob (or player) or if the focus becomes mind controlled so that it is no longer able to receive healing or beneficial spells. 

Is a reason why the focus check is explicit in the parsing:
If yes, then add a check for canHeal('focus') to the sections in the dsl.lua and parser.lua files so that they will not return enemy players, mobs, MCs, etc. as the tank.
If no, then remove the focus check from the sections in the dsl.lua and parser.lua files and let the ProbablyEngine.raid.tank() call that follows them handle the tank value return. 
Thanks my take on it anyway. Thanks!

Related code sections:
Probably/system/core/dsl.lua
Lines 144-165
Lines 166-188 (Same concern may also apply here as well.)

Probably/system/core/parser.lua
Lines 250-254

Probably/system/core/raid.lua
Lines 190-220

----------


## Mackdaddy2887

> *Bug:* Generic focus logic for parsing "tank" ?
> *Build:* 6.0.3r11
> 
> *Details:* 
> I'm not sure if this is actually a bug or if I'm just completely missing the reason for logic here. (I suspect this is left over from the quick build of the healing framework from way back whenever, but I could be wrong.) I cannot see the use of "tank" as the unit for any target other than a healable/friendly one. The first step of the ProbablyEngine.raid.tank() function will check for a healable focus and return it as the result if found. However, the code in both the dsl.lua and parser.lua files checks for the existence of a focus and returns it regardless of if the focus is a friend or enemy before the ProbablyEngine.raid.tank() function is called. This becomes an issue if the player is a healer assigned to chain CC an enemy mob (or player) or if the focus becomes mind controlled so that it is no longer able to receive healing or beneficial spells. 
> 
> Is a reason why the focus check is explicit in the parsing:
> If yes, then add a check for canHeal('focus') to the sections in the dsl.lua and parser.lua files so that they will not return enemy players, mobs, MCs, etc. as the tank.
> If no, then remove the focus check from the sections in the dsl.lua and parser.lua files and let the ProbablyEngine.raid.tank() call that follows them handle the tank value return. 
> ...


As someone who predominantly heals and writes routines fit healing, if I want to target the focus, ill make 'focus' my target. If I use tank, I want it NOT use the focus, but do the rest, check for people set to that role, etc etc.

In short, do what he mentioned above and remove focus from the tank value

----------


## Greymalkin

> As someone who predominantly heals and writes routines fit healing, if I want to target the focus, ill make 'focus' my target. If I use tank, I want it NOT use the focus, but do the rest, check for people set to that role, etc etc.
> 
> In short, do what he mentioned above and remove focus from the tank value


Hey Mack,
What I was recommending is to remove the heavy-handed focus checks from the parsing and let the ProbablyEngine.raid.tank() function handle the focus check, rather than removing the focus checks from all points of the tank evaluation completely. The focus check in the ProbablyEngine.raid.tank() function was most likely used as a safe guard against the function returning different tank values (too rapidly or at all) and causing buffing conflicts. In prior expansions some buffs would overwrite the same buffs from other players, i.e. a Shaman's Earth Shield, where if you didn't set focus on the tank you were assigned to the Earth Shield would jump among the available tanks in the raid overwriting other Shamans' Earth Shield on the tanks they were focusing. (I cringe just thinking about all those wasted casts and GCDs on both sides!) I believe this is less of a concern now that Earth Shield and the like are no longer exclusive on a target. However, if a healer is assigned to primarily keep a specific tank up, having that tank set as focus and returned when it is healable is still preferred as far as I can see. If that tank dies or gets out of range, the canHeal('focus') check will fail and the ProbablyEngine.raid.tank() function will continue through the other evaluation methods to find a new viable tank until the focus tank is back in range or revived. As a whole, I personally do not want to see the healable focus check removed from the ProbablyEngine.raid.tank() function. 

Side note: Just a thought, but we could ask the devs with a feature suggestion to add a "tanks" unit that acts similar to "tank" without the focus safe guard. That way if heals / buffs need to specifically be spread around on all the tanks, the lowest health unit of all tanks at the moment would be returned. ...OR maybe make "tanks" a little more robust so we could use conditions like tanks.lowest, !tanks.buff(Riptide), etc., but that is getting more into building a full healing engine which is a story for another day!

----------


## thefrobel

Not sure how close PE's core is to Simulationcraft, but the verbiage looks REALLY close... Also, not sure if you would be able to, but making PE able to copy and paste the 'priority' section of individual spec dps rotations might make making optimal rotation LUAs for PE quite easy...

From Simulationcraft.org's website for a shadowpriest running COP


```
actions.cop_dotweave
# 	count 	action,conditions
c 	7.61 	devouring_plague,if=target.dot.vampiric_touch.ticking&target.dot.shadow_word_pain.ticking&shadow_orb=5&cooldown_react
d 	0.00 	devouring_plague,if=(buff.mental_instinct.remains<gcd&buff.mental_instinct.remains)
e 	7.38 	devouring_plague,if=(target.dot.vampiric_touch.ticking&target.dot.shadow_word_pain.ticking&!buff.shadow_word_insanity.remains&cooldown.mind_blast.remains>0.4*gcd)
f 	0.00 	mind_blast,if=glyph.mind_harvest.enabled&mind_harvest=0&shadow_orb<=2,cycle_targets=1
g 	47.87 	mind_blast,if=shadow_orb<=4&cooldown_react
h 	2.00 	shadowfiend,if=!talent.mindbender.enabled&!buff.shadow_word_insanity.remains
i 	0.00 	mindbender,if=talent.mindbender.enabled&!buff.shadow_word_insanity.remains
j 	0.00 	shadow_word_pain,if=shadow_orb=4&set_bonus.tier17_2pc&!target.dot.shadow_word_pain.ticking&!target.dot.devouring_plague.ticking&cooldown.mind_blast.remains<1.2*gcd&cooldown.mind_blast.remains>0.2*gcd
k 	7.68 	shadow_word_pain,if=shadow_orb=5&!target.dot.devouring_plague.ticking&!target.dot.shadow_word_pain.ticking
l 	7.64 	vampiric_touch,if=shadow_orb=5&!target.dot.devouring_plague.ticking&!target.dot.vampiric_touch.ticking
m 	15.34 	insanity,if=buff.shadow_word_insanity.remains,chain=1,interrupt_if=cooldown.mind_blast.remains<=0.1
n 	0.08 	shadow_word_pain,if=shadow_orb>=2&target.dot.shadow_word_pain.remains>=6&cooldown.mind_blast.remains>0.5*gcd&target.dot.vampiric_touch.remains&buff.bloodlust.up&!set_bonus.tier17_2pc
o 	0.00 	vampiric_touch,if=shadow_orb>=2&target.dot.vampiric_touch.remains>=5&cooldown.mind_blast.remains>0.5*gcd&buff.bloodlust.up&!set_bonus.tier17_2pc
p 	5.42 	halo,if=cooldown.mind_blast.remains>0.5*gcd&talent.halo.enabled&target.distance<=30&target.distance>=17
q 	0.00 	divine_star,if=cooldown.mind_blast.remains>0.5&gcd&talent.divine_star.enabled&(active_enemies>1|target.distance<=24)
r 	0.00 	cascade,if=cooldown.mind_blast.remains>0.5*gcd&talent.cascade.enabled&((active_enemies>1|target.distance>=28)&target.distance<=40&target.distance>=11)
s 	0.00 	shadow_word_pain,if=primary_target=0&(!ticking|remains<=18*0.3),cycle_targets=1,max_cycle_targets=5
t 	0.00 	vampiric_touch,if=primary_target=0&(!ticking|remains<=15*0.3),cycle_targets=1,max_cycle_targets=5
u 	16.93 	mind_spike,if=buff.shadow_word_insanity.remains<=gcd&buff.bloodlust.up&!target.dot.shadow_word_pain.remains&!target.dot.vampiric_touch.remains
v 	1.00 	mind_spike,if=((target.dot.shadow_word_pain.remains&!target.dot.vampiric_touch.remains)|(!target.dot.shadow_word_pain.remains&target.dot.vampiric_touch.remains))&shadow_orb<=2&cooldown.mind_blast.remains>0.5*gcd
w 	0.00 	mind_flay,if=set_bonus.tier17_2pc&target.dot.shadow_word_pain.remains&target.dot.vampiric_touch.remains&cooldown.mind_blast.remains>0.9*gcd,interrupt_if=(cooldown.mind_blast.remains<=0.1|cooldown.shadow_word_death.remains<=0.1)
x 	50.13 	mind_spike
y 	0.00 	shadow_word_death,moving=1
z 	0.00 	halo,if=talent.halo.enabled&target.distance<=30,moving=1
{ 	0.00 	divine_star,if=talent.divine_star.enabled&target.distance<=28,moving=1
| 	0.00 	cascade,if=talent.cascade.enabled&target.distance<=40,moving=1
} 	0.00 	shadow_word_pain,moving=1
```

Just a thought.

----------


## Mackdaddy2887

> Hey Mack,
> What I was recommending is to remove the heavy-handed focus checks from the parsing and let the ProbablyEngine.raid.tank() function handle the focus check, rather than removing the focus checks from all points of the tank evaluation completely. The focus check in the ProbablyEngine.raid.tank() function was most likely used as a safe guard against the function returning different tank values (too rapidly or at all) and causing buffing conflicts. In prior expansions some buffs would overwrite the same buffs from other players, i.e. a Shaman's Earth Shield, where if you didn't set focus on the tank you were assigned to the Earth Shield would jump among the available tanks in the raid overwriting other Shamans' Earth Shield on the tanks they were focusing. (I cringe just thinking about all those wasted casts and GCDs on both sides!) I believe this is less of a concern now that Earth Shield and the like are no longer exclusive on a target. However, if a healer is assigned to primarily keep a specific tank up, having that tank set as focus and returned when it is healable is still preferred as far as I can see. If that tank dies or gets out of range, the canHeal('focus') check will fail and the ProbablyEngine.raid.tank() function will continue through the other evaluation methods to find a new viable tank until the focus tank is back in range or revived. As a whole, I personally do not want to see the healable focus check removed from the ProbablyEngine.raid.tank() function. 
> 
> Side note: Just a thought, but we could ask the devs with a feature suggestion to add a "tanks" unit that acts similar to "tank" without the focus safe guard. That way if heals / buffs need to specifically be spread around on all the tanks, the lowest health unit of all tanks at the moment would be returned. ...OR maybe make "tanks" a little more robust so we could use conditions like tanks.lowest, !tanks.buff(Riptide), etc., but that is getting more into building a full healing engine which is a story for another day!


Yes. But if you were assigned to heal just a certain tank, then set him as focus, and in the profile put: 
{"Earth shield", {"!focus.buff", "focus.exists"}, "focus"},
{"Earth shield", {"!tank.buff", "!focus.exists"}, "tank"},

That way you can cast earth shield on your designated target. OR if you don't have one, it'll assign it to the currently active tank (however the function works). 

The reason I request this is simple, I want to have a tank healing section, as "lowest" doesn't always meet my needs (for example I'd rather let the 5% hp DPS die than the 10% tank, but your focus is the 80% tank). Now what you can tell me is to make a targeting and focus macro to auto focus the currently active tank, but that defeats the purpose of why you wanted the focus apart of the tank function to begin with...

----------


## Greymalkin

> Yes. But if you were assigned to heal just a certain tank, then set him as focus, and in the profile put: 
> {"Earth shield", {"!focus.buff", "focus.exists"}, "focus"},
> {"Earth shield", {"!tank.buff", "!focus.exists"}, "tank"},
> 
> That way you can cast earth shield on your designated target. OR if you don't have one, it'll assign it to the currently active tank (however the function works). 
> 
> The reason I request this is simple, I want to have a tank healing section, as "lowest" doesn't always meet my needs (for example I'd rather let the 5% hp DPS die than the 10% tank, but your focus is the 80% tank). Now what you can tell me is to make a targeting and focus macro to auto focus the currently active tank, but that defeats the purpose of why you wanted the focus apart of the tank function to begin with...


Oh, I see your logic and it appears completely valid. I guess I just like having that healable focus fail safe in there because it always has been, because I like being able to specify the main recipient of my heals, or because I haven't set focus specific lines in the CRs to account for it not using focus. >.> ...or maybe all three? =D

As for a tank healing section, PE could use a bit of work on the healing front as a whole. I would love to see a prioritization of tanks > heals > dps when evaluating "lowest" rather than absolute heath in raid or a method for checking/targeting units/roles with/without specific buffs for spell preparation/synergy (Wow, that was an over use of slashes!), but that goes back to the devs having time to build a full healing engine framework in PE. 

I'm not sure what you mean by "make a targeting and focus macro" for the tanks, but that just sounds dirty ...and not in the fun kind of way!

----------


## Mackdaddy2887

> Oh, I see your logic and it appears completely valid. I guess I just like having that healable focus fail safe in there because it always has been, because I like being able to specify the main recipient of my heals, or because I haven't set focus specific lines in the CRs to account for it not using focus. >.> ...or maybe all three? =D
> 
> As for a tank healing section, PE could use a bit of work on the healing front as a whole. I would love to see a prioritization of tanks > heals > dps when evaluating "lowest" rather than absolute heath in raid or a method for checking/targeting units/roles with/without specific buffs for spell preparation/synergy (Wow, that was an over use of slashes!), but that goes back to the devs having time to build a full healing engine framework in PE. 
> 
> I'm not sure what you mean by "make a targeting and focus macro" for the tanks, but that just sounds dirty ...and not in the fun kind of way!


This may not be exactly right as I'm reciting from the top of my head, but (going to cheat and not use structure):
/target enemy dead noexists, "target.dead" "! Target.exists"},
{"/focs targettarget", "target.enemy"},

Targets enemy if you don't have a target etc, focuses at the targetstargeg if the target is an enemy. (So if you target an ally or npc or something it won't focus it's target, you want to focus the bosses target, basically the currently active tank.
Put these lines at thy very very last of your routine.
---------------

Anyways, if focus is removed, (or lowered in priority) from the tank function, you can have a specific heal section for the tanks with out specifying which.

Which then, if you still want focus specific stuff, just have lines in your CR that specifies focus as thy target, like the example above. You can use both. 
Tank for general tank healing, and focus for your specific focus needs.
---------------------

Also, lowest needs some work. Example:

The only issue with "lowest" is, well example:
Boss: Ko'ragh
Your assigned to raid healing, lets say shaman is assigned to focus the hunter whos soaking in the center

Now lets say the raid size is 10man:
raid1=hunter
raid2-10=everyone else

Now imagine:
Raid1 hp=25%
raid2-10 hps are..50-70% 

your job, blanket the raid with rejuvs/germination, raid heal, as per your assignment.

Except... the lowest is, and will probably stay, the hunter. so the Combat routine casts rejuv/germination on the hunter, then does nothing because the "lowest" i.e. the hunter, already has the HoTs.


To account for this, im my resto profile I set up a raid and party mode. Where is force blankets the raid. (obviously it will focus the lowest HP first and foremost always)


(Check out the druid cr of mine if you have time,

----------


## Greymalkin

*Bug:* unit.name errors when unit doesn't exist
*Build:* 6.0.3r11

*Details:* 
The registered condition "name" tries to return an evaluation on the target arg whether the unit of that target arg exists or nor. This causes PE to stream errors when using conditions like "target.name(sapper)" when nothing is currently targeted. 

*Fix:* 
Possibly use a default false return and wrap the evaluation return with an UnitExists(target) check like some of the other registered conditions have. 



```
if UnitExists(target) then
return UnitName(target):lower():find(expectedName:lower()) ~= nil
end
return false
```

----------


## Hackinte

> haha, well, three things that would be super...
> 
> Feature: Allow for unit.area().friendly
> Details:
> Let us check for friendly units in an area.
> 
> Feature: lowest.withbuff(x)
> Details:
> For better healing, a way to cast hots like riptide on the lowest unit that doesn't already have it.
> ...


*Added unit.area().friendly*

The other two I see the value in but are quite a ways back in the list of things to do.

----------


## Hackinte

> Would be nice if 
> 
> Balance.moon 
> Balance.Sun 
> 
> We're fixed


*Fixed! Added unit.eclipse and fixed unit.solar and unit.lunar*

*unit.eclipse* Will be a value from 0 to 100 in the current eclipse direction.
*unit.lunar* Will return true if the unit is in the lunar phase.
*unit.solar* Will return true if the unit is in the solar phase.

----------


## Hackinte

> player.behind doesn't seem to work,


*Fixed*

10chars

----------


## Hackinte

> copy/past from my previous post. 
> 
> Build: CURRENT (as of 12/27)
> 
> 
> 
> 
> Also..
> 
> ...


*Fixed*

*modifier.last* IS DEPRECATED, YOU WILL GET A WARNING.

*Use lastcast instead!*
*Examples:*


```
{ "Spell", "lastcast(Other Spell)" }
{ "Spell", "!lastcast" }
```

----------


## Hackinte

> Bug:
> 
> Crash PE totally on Orgron Twins using Nocarriers monk profile - seems to be when the Boss is doing its whirlwind routine.
> 
> Interface\AddOns\Probably\system\conditions\core.lua:734: attempt to perform arithmetic on local 'endTime' (a nil value)
> Count: 99
> 
> Call Stack:
> [C]: ?
> ...


*I'm not sure why this happened, but I've added sanity checks to make sure it doesn't.*

----------


## Hackinte

> *Bug:* unit.name errors when unit doesn't exist
> *Build:* 6.0.3r11
> 
> *Details:* 
> The registered condition "name" tries to return an evaluation on the target arg whether the unit of that target arg exists or nor. This causes PE to stream errors when using conditions like "target.name(sapper)" when nothing is currently targeted. 
> 
> *Fix:* 
> Possibly use a default false return and wrap the evaluation return with an UnitExists(target) check like some of the other registered conditions have. 
> 
> ...


*Fixed*

10chars

----------


## Greymalkin

> *Bug:* Typo in checkChanneling of the nested Interrupt code
> *Build:* 6.0.3r11
> 
> *Details:* 
> The recent inconsistent issues with interruptAt and interruptsAt appear to boil down to a typo on line 709 of Probably/system/conditions/core.lua The "name" variable has an extra underscore behind it which is not letting the next line query its value. Since "name" on line 710 is getting a value returned from somewhere (I ended up tracking the "name" variable down to an old add-on bleeding variables to global which is most likely why some PE users had the issue and some didn't if they had old add-ons running) it is cascading incorrect returns, i.e. checkChanneling line 710 to checkCasting line 717 to casting.delta line 732 (where startTime, endTime, notInterruptible are being populated as nil) to casting.delta line 733 evaluating as true to casting.delta line 734 trying to evaluate castLength as (nil - nil) / 1000. This is where all of the reported "attempt to perform arithmetic on local 'endTime' (a nil value)" errors are originating from. 
> 
> *Fix:* 
> Just remove the trailing underscore from the "name" variable in the checkChanneling function.


/bump
Looks like the typo is still in r12. Maybe the new sanity checks for Produktionshuset's endTime error will catch that sneaky bug! =)

----------


## Hackinte

> /bump
> Looks like the typo is still in r12. Maybe the new sanity checks for Produktionshuset's endTime error will catch that sneaky bug! =)


Fixed, uploading new version now.

----------


## Greymalkin

> Fixed, uploading new version now.


Thanks mate!

----------


## Mackdaddy2887

None of these are working. ALways false.




```
"!last"
"!last(SPELL)"
"last(SPELL)"
```

----------


## Mackdaddy2887

> *Added unit.area().friendly*


The unit.area().friendly is very interested. Id like to use it for spinning crane kick. But I dont want to do so unless its needed. Any way to check for health?

for instance:



```
use:  "player.area(10).friendly >= 5"   and then some new function like:  "Player.area(10).healthAVG <= 80"

so it would be:
{"spinning crane kick", {"player.area(10).friendly >= 5" , "Player.area(10).healthAVG <= 80", "player.mana >= 25" }},
```

something similiar could be useful for other Healing targeted area of effect spells.
Like Checking average health of players in a radius around a unit.

For example:
Chain heal cast on "lowest" check area around lowest if the average health of those people are low. (chain heal got a buff with the lvl100 talent, bounces to riptide targets, so this might not be as needed)

Or something like Chi explosion, which heals (if used with enough chi) in a radius around a target.
[/code]

----------


## Mackdaddy2887

BUG REPORT:

Offspring doesnt work with trinkets or items.

My code:


```
{ "#trinket1" },
{ "#trinket2" },
```

it works with EWT. but with offspring it just spams:



Offspring just spams use item. i comment out the trinkets, and it will heal fine, but the DPS stance doesnt work. Also, the stance swapping, (both autoswap and modifier.rshift stance swap wont work.
Also, mouseover.ground doesnt place on the ground, it will only place at mouseover target. in EWT I hold rcontrol, and can place my statue anywhere i want.

here is my code:



```
--A MISTWEAVER rotation by Mack

ProbablyEngine.library.register('coreHealing', {
  needsHealing = function(percent, count)
    return ProbablyEngine.raid.needsHealing(tonumber(percent)) >= count
  end,
  needsDispelled = function(spell)
    for unit,_ in pairs(ProbablyEngine.raid.roster) do
      if UnitDebuff(unit, spell) then
        ProbablyEngine.dsl.parsedTarget = unit
        return true
      end
    end
  end,
})

ProbablyEngine.rotation.register_custom(270, "MacksMW v5", {


--buffs/pause
{ "115921", "!player.buffs.stats" }, --stats

--Stance Management
{"154436",{"!lastcast(115070)","player.stance = 1","toggle.AutoStanceSwap","target.range <= 5", "target.enemy"},},
{"115070",{"!lastcast(154436)","player.stance = 2","toggle.AutoStanceSwap","target.range > 5",  "target.enemy"},},
{"154436",{"player.stance = 1","modifier.rshift"}},
{"115070",{"player.stance = 2","modifier.rshift"}},

--SURVIVAL
{ "!115203", { "player.health <= 35" }, "Player" },--fortifying brew
{ "#5512", "player.health <= 50" },  --healthstone

--CDs
{ "!115310", "modifier.lalt" },  --Revival
{"!115313", "modifier.rcontrol", "mouseover.ground" }, --statue
{ "#trinket1" },
{ "#trinket2" },

{ "!123986", "modifier.lcontrol", "player" },  --chi burst
{ "!124081", {"lowest.health <= 90"}, "lowest" }, --zen shpere
{ "Chi Wave",{"lowest.health <= 100 "}, "lowest" }, --chi wave

--Expel Harm on CD if not channeling
 { "Expel Harm", {"lowest.health <= 100","player.chi < 4"}, "lowest" }, 

--Dispells
-- {"!Detox", {"!lastcast","player.mana > 10","player.spell(Detox).casted < 1", "@coreHealing.needsDispelled('Corrupted Blood')" }, nil },
-- {"!Detox", {"!lastcast","player.mana > 10","player.spell(Detox).casted < 1", "@coreHealing.needsDispelled('Slow')"}, nil },
{"!Detox", {"!lastcast(Detox)","player.mana > 10","@coreHealing.needsDispelled('Corrupted Blood')" }, nil },
{"!Detox", {"!lastcast(Detox)","player.mana > 10","@coreHealing.needsDispelled('Slow')"}, nil },




--TESTINg
--{ "!115175", { "lowest.health <= 100", "!player.moving", "!lastcast", "lowest.buff(115175).duration <= 1"}, "lowest" }, -- Soothing Mist
--{ "124682", {"player.casting(soothing mist)", "lowest.health <= 100", "player.chi >= 3" }, "lowest" }, -- EnM
--{ "116694", { "player.casting","lowest.health <= 100" }, "lowest" }, -- Surging Mist

--!!!!!!!!!!!!!!!    JADE SERPENT STANCE      !!!!!!!!!!!!!!!!!
  {{

 

  --Need mana Emergency
  { "!115294", { "player.mana < 8", "player.buff(115867).count >= 2","!player.spell(Uplift).casting", "!player.moving"},}, -- mana tea

  --Focus emergency
  {"!Life Cocoon", {"focus.health <= 20"}, "focus"},
  { "!115175", { "focus.health <= 20", "!player.moving", "!player.spell(Uplift).casting","!lastcast(115175)", "focus.buff(115175).duration <= 1"}, "focus" }, -- Soothing Mist
  { "116680", "focus.health <= 20" , "player" }, -- TFT
  { "124682", { "player.casting", "focus.health <= 20", "player.chi >= 3" }, "focus" }, -- EnM
  { "116694", { "player.casting", "focus.health <= 20" }, "focus" }, -- Surging Mist

  --Tank emergency Healing
  {"!Life Cocoon", {"tank.health <= 25"}, "tank"},
  { "!115175", { "tank.health <= 15", "!player.moving","!player.spell(Uplift).casting", "!lastcast(115175)",  "tank.buff(115175).duration <= 1"}, "tank" }, -- Soothing Mist
  { "116680", "tank.health <= 15" , "player" }, -- TFT
  { "124682", { "player.casting", "tank.health <= 14", "player.chi >= 3" }, "tank" }, -- EnM
  { "116694", { "player.casting", "tank.health <= 14" }, "tank" }, -- Surging Mist

  --Emergency Healing
  { "!115175", { "lowest.health <= 18", "!player.moving", "!player.spell(Uplift).casting","!lastcast(115175)", "lowest.buff(115175).duration <= 1"}, "lowest" }, -- Soothing Mist
  { "116680", "lowest.health <= 18" , "player" }, -- TFT
  { "124682", { "player.casting", "lowest.health <= 18", "player.chi >= 3" }, "lowest" }, -- EnM
  { "116694", { "player.casting", "lowest.health <= 18" }, "lowest" }, -- Surging Mist

  
 --ReM @3 stacks
  { "!Renewing Mist", { "lowest.buff(119611).duration <= 2","!player.spell(Uplift).casting","player.spell(Renewing Mist).charges = 3" , "player.chi < 4" } , "lowest" }, 
  { "!Renewing Mist", { "tank.buff(119611).duration <= 2","!player.spell(Uplift).casting","player.spell(Renewing Mist).charges = 3" , "player.chi < 4" } ,"tank" }, 
  { "!Renewing Mist", { "focus.buff(119611).duration <= 2","!player.spell(Uplift).casting","player.spell(Renewing Mist).charges = 3" , "player.chi < 4" } ,"focus" }, 
  { "!115151", { "!player.spell(Uplift).casting","player.spell(Renewing Mist).charges = 3" , "player.chi < 4" } , "lowest" }, 

  --MANA
  { "115294", { "!lastcast(115294)","player.mana < 75", "player.buff(115867).count >= 2","!player.moving"},}, -- mana tea



  -------------!!!!  AoE If multitarget is enabled. ReM/Uplift healing  !!!!-------------------
    {{
    { "!Uplift", { "raid.health <= 90","!player.moving", "!player.spell(Uplift).casting", "player.chi >= 2" },"player"}, --Uplift
    { "!116680",{"!player.spell(Uplift).casting"}, "player"},
    { "!Renewing Mist", { "lowest.buff(119611).duration <= 4","!player.spell(Uplift).casting", "player.spell(Renewing Mist).charges > 1" , "player.chi < 4"}, "lowest" }, --ReM 
    { "!Renewing Mist", { "focus.buff(119611).duration <= 4","!player.spell(Uplift).casting", "player.spell(Renewing Mist).charges > 1" , "player.chi < 4"}, "focus" }, --ReM 
    { "!Renewing Mist", { "@coreHealing.needsHealing(80, 5)" ,"!player.spell(Uplift).casting", "player.spell(Renewing Mist).charges > 1" , "player.chi <= 2"}, "lowest" }, --ReM 
    { "!Renewing Mist", { "!player.spell(Uplift).casting","player.chi < 2", "@coreHealing.needsHealing(80, 5)" }, "focus" }, --ReM Need Chi
    { "!Renewing Mist", { "!player.spell(Uplift).casting","player.chi < 2", "@coreHealing.needsHealing(80, 5)" }, "tank" }, --ReM Need Chi
    --Need more Chi for uplift
    { "116694", {"player.mana >=20","@coreHealing.needsHealing(85, 5)","player.casting", "lowest.health <= 90", "player.chi < 2"}, "lowest" }, -- Surging Mist
    { "115175", {"lowest.health <= 100","!lastcast(115175)","!player.spell(Uplift).casting","!player.moving", "lowest.buff(115175).duration <= 1"}, "lowest" }, -- Soothing Mist

    }, "modifier.multitarget"},
    ----------------------!!!! AoE END !!!!---------------------------




  --!!!!!!!!!!!!!!!      SINGLE TARGET  (multitarget disabled)  !!!!!!!!!!!!!
    --Lowest if below 80% (tank included), tank if below 90%, anyone
    {{
    { "!116680", {"lowest.health <= 60"} , "player" }, -- TFT
    { "!115175", {"lowest.health <= 60","!player.moving", "!lastcast(115175)","lowest.buff(115175).duration <= 1"}, "lowest" }, -- Soothing Mist
    { "124682", { "player.casting", "lowest.health <= 60", "player.chi > 2" }, "lowest" }, -- EnM
    { "116694", { "player.casting", "lowest.health <= 60"}, "lowest" }, -- Surging Mist

    { "!115175", {"lowest.health <= 80","!player.moving", "!lastcast(115175)","lowest.buff(115175).duration <= 1"}, "lowest" }, -- Soothing Mist
    { "124682", { "player.casting", "lowest.health <= 80", "player.chi > 2" }, "lowest" }, -- EnM
    { "116694", { "player.casting", "lowest.health <= 80","!lastcast(116694)" }, "lowest" }, -- Surging Mist
    { "!115175", {"tank.health <= 90","!player.moving", "!lastcast(115175)", "tank.buff(115175).duration <= 1"}, "tank" }, -- Soothing Mist
    { "124682", { "player.casting", "tank.health <= 90", "player.chi > 2" }, "tank" }, -- EnM
    { "116694", { "player.casting", "tank.health <= 90", "!lastcast(116694)" }, "tank" }, -- Surging Mist
    
    { "124682", { "player.casting", "lowest.health <= 92", "player.chi > 2" }, "lowest" }, -- EnM dump chi
    {"!115175", { "lowest.health <= 100", "!player.moving", "lowest.buff(115175).duration <= 1"}, "lowest" }, --soothing

    
    }, "!modifier.multitarget"},
    --!!!!!!!!!!!!!!!      END SINGLE TARGET  (multitarget disabled)  !!!!!!!!!!!!!


  }, "player.stance = 1" },
  --!!!!!!!!!!!!!!!        END SERPANT STANCE HEALING        !!!!!!!!!!!!!!!!!!!!!!




--!!!!!!!!!!!!!!!         CRANE STANCE DPS          !!!!!!!!!!!!!!!!!!!!!!
  {{
  { "Surging Mist", {"player.buff(Vital Mists).count = 5"},"lowest" },
  {"Tiger Palm", {"player.buff(Vital Mists.count = 4", "player.chi > 0" }},
  { "Rising Sun Kick", {"target.debuff(130320).duration < 5", "player.chi > 1"} },
  {"Blackout Kick", {"player.buff(127722).duration < 5", "player.chi > 1" }},
  {"Tiger Palm", {"player.buff(125359).duration < 5", "player.chi > 0" }},
  {"Blackout Kick", "player.chi > 1" },
  {"Jab"}, 

  }, "player.stance = 2"},

  --!!!!!!!!!!!!!       END CRANE STANCE        !!!!!!!!!!!


--Targeting & Focus
  { "/targetenemy [noexists]", "!target.exists" },
  { "/focus [@targettarget]", "target.enemy"  },
  { "/target [target=focustarget, harm, nodead]", "target.range > 40" },

--END COMBAT
},{


--out of combat
{ "115921", "!player.buffs.stats" }, --stats
{"!115313",{"modifier.rcontrol"}, "mouseover.ground" }, --statue

},function()


ProbablyEngine.toggle.create('AutoStanceSwap', 'Interface\\Icons\\monk_stance_redcrane', 'Auto Crane','Auto Stance Swap when in melee')


end)
```


Its not my code. Ive tested it over and over with EWT in heroic Highmaul, and works great.

The issue is somewhere with offspring PE code i think.

----------


## Hackinte

> BUG REPORT:
> 
> Offspring doesnt work with trinkets or items.
> 
> My code:
> 
> 
> ```
> { "#trinket1" },
> ...


Thanks, I'll have that fixed in the next release.

----------


## MrTheSoulz

While using Offsping we get errors from "SpellStopCasting()", the fix would be to to nest all of them with: 
if oexecute then oexecute("SpellStopCasting() ") else SpellStopCasting() end

----------


## 123mouser

* Bug:*  Error when using:

"target.area( :Cool: .enemies >= 3" condition

on garrison target dummies (and in instances as well)

*Build*: 6.0.3r12


*Details*:
Message: ...erface\AddOns\probably\system\protected\firehack.lua:63: bad argument #1 to 'band' (number expected, got string)
Count: 450
Stack: [C]: ?
[C]: in function `band'
...erface\AddOns\probably\system\protected\firehack.lua:63: in function `UnitsAroundUnit'

----------


## Hackinte

> While using Offsping we get errors from "SpellStopCasting()", the fix would be to to nest all of them with: 
> if oexecute then oexecute("SpellStopCasting() ") else SpellStopCasting() end


Fixed in the next release, along with a lot of other Offspring fixes.

----------


## thefrobel

Fresh install of latest version of PE.


```
Date: 2015-01-05 23:19:02
ID: 1
Error occured in: AddOn: Probably
Count: 1
Message: Error: AddOn Probably attempted to call a forbidden function (UNKNOWN()) from a tainted execution path.
Debug:
   [C]: ?
   [C]: pcall()
   ...terface\AddOns\Probably\system\protected\generic.lua:12: Generic()
   Probably\system\timers\rotation.lua:203: event()
   Probably\system\core\timer.lua:16:
      Probably\system\core\timer.lua:11
Locals:
None
```

----------


## Mackdaddy2887

Bug: PE doesnt use Swiftmend druid spell
Build: latest as of 01/06/2015

Details:
PE will SOMETIMES cast Swiftmend. Even though it should, sometimes it completely ignores the ability.
SWIFTMEND wowhead


Additional Details:
Literally tried Commenting out everything, and deleting my conditionals.
1. Enter Combat.
2. Manually Cast REJUVE (prerequisite of Swiftmend) on myself and my alt account (standin at half health)
3. PE does nothing
4. Sometimes while moving it MAY cast it.




```
{ "Swiftmend", {}, "lowest" }, 
{ "Swiftment", {}, "focus" },
```

I tried it will conditionals:



```
{ "Swiftmend", {"lowest.buff(Rejuvenation)"}, "lowest" }, 
{ "Swiftment", {"focus.buff(Rejuvenation)"}, "focus" },
```

Ive tried multiple different combinations of conditionals, it just doesnt want to cast half the time. Funny thing is, IF im solo, and Lowest=Player it WILL CAST. EVERYTIME!!
Its not reading the other party members.

Ive even tried specifiing


```
{ "Swiftmend", {"party1.buff(Rejuvenation)"}, "party1" }, 
{ "Swiftment", {"raid1.buff(Rejuvenation)"}, "raid1" },
```

etc etc


Plz Fix. I dont know the Inner working, but I know my profile would be 100% better if PE casted Swiftmend

----------


## zeldaboch

> Bug: PE doesnt use Swiftmend druid spell
> Build: latest as of 01/06/2015
> 
> Details:
> PE will SOMETIMES cast Swiftmend. Even though it should, sometimes it completely ignores the ability.
> SWIFTMEND wowhead
> 
> 
> Additional Details:
> ...



Firts you can try using the spellID instead name -> 18562
Second, remember that LOWEST does not mean that he has the buff/debuff you are checking for. Lowest is the one who have less life. If he hase also a Reju (774) buff, PE will try cast swiftmend, or he will do what come next this condition.
In solo, it is easy because you are sure that you have Reju or Regro casted, but in party? try to check this.

----------


## Mackdaddy2887

> Firts you can try using the spellID instead name -> 18562
> Second, remember that LOWEST does not mean that he has the buff/debuff you are checking for. Lowest is the one who have less life. If he hase also a Reju (774) buff, PE will try cast swiftmend, or he will do what come next this condition.
> In solo, it is easy because you are sure that you have Reju or Regro casted, but in party? try to check this.


Haha... thanks for the response but I'm quite aware of how lowest works. Any and all testing I've done, I've always cast rejuve on everyone/everything.

And as for spell name, yes I tried it both ways, regardless though it still sometimes casts it.

I'm mentioning this buff because not once in PE history has Swiftmend worked correctly. In the past I've used boomkins resto , backburns resto, repaireds resto, among others.

I originally thought it was because of the issue that "lowest" didn't always have rejuve I them, as during raid damage the "lowest" is constantly changing, so I added an copy/paste array for each and every party member. Like so:



```
--!!!!!!!!!!!!!!!!!!!!!!! SWIFTMEND WILL CAST DAMNIT  !!!!!!!!!!!!!!!!!!
{ "Swiftmend", {"lowest.range <= 40", "lowest.buff(774)", "lowest.health <= 90"}, "lowest" }, -- Rejuv.
{ "Swiftmend", {"focus.range <= 40", "focus.buff(774)", "focus.health <= 95"}, "focus" }, -- Rejuv.
{ "Swiftmend", {"tank.buff(774)", "tank.health <= 95"}, "tank" }, -- Rejuv.
{ "Swiftmend", { "raid1.range <= 40","raid1.buff(774)", "raid1.health <= 90"}, "raid1" }, -- Rejuv.
{ "Swiftmend", { "player.buff(774)", "player.health <= 90" }, "player" }, -- Rejuv.
{ "Swiftmend", { "raid2.range <= 40","raid2.buff(774)", "raid2.health <= 90"}, "raid2" }, -- Rejuv.
{ "Swiftmend", { "raid3.range <= 40","raid3.buff(774)", "raid3.health <= 90"}, "raid3" }, -- Rejuv.
{ "Swiftmend", { "raid4.range <= 40","raid4.buff(774)", "raid4.health <= 90"}, "raid4" }, -- Rejuv.
{ "Swiftmend", { "raid5.range <= 40","raid5.buff(774)", "raid5.health <= 90"}, "raid5" }, -- Rejuv.
{ "Swiftmend", { "raid6.range <= 40","raid6.buff(774)", "raid6.health <= 90"}, "raid6" }, -- Rejuv.
{ "Swiftmend", { "raid7.range <= 40","raid7.buff(774)", "raid7.health <= 90"}, "raid7" }, -- Rejuv.
{ "Swiftmend", { "raid8.range <= 40","raid8.buff(774)", "raid8.health <= 90"}, "raid8" }, -- Rejuv.
{ "Swiftmend", { "raid9.range <= 40","raid9.buff(774)", "raid9.health <= 90"}, "raid9" }, -- Rejuv.
{ "Swiftmend", { "raid10.range <= 40","raid10.buff(Rejuvenation)", "raid10.health <= 90"}, "raid10" }, -- Rejuv.
{ "Swiftmend", { "raid11.range <= 40","raid11.buff(Rejuvenation)", "raid11.health <= 90"}, "raid11" }, -- Rejuv.
{ "Swiftmend", { "raid12.range <= 40","raid12.buff(Rejuvenation)", "raid12.health <= 90"}, "raid12" }, -- Rejuv.
{ "Swiftmend", { "raid13.range <= 40","raid13.buff(Rejuvenation)", "raid13.health <= 90"}, "raid13" }, -- Rejuv.
{ "Swiftmend", { "raid14.range <= 40","raid14.buff(Rejuvenation)", "raid14.health <= 90"}, "raid14" }, -- Rejuv.
{ "Swiftmend", { "raid15.range <= 40","raid15.buff(Rejuvenation)", "raid15.health <= 90"}, "raid15" }, -- Rejuv.
{ "Swiftmend", { "raid16.range <= 40","raid16.buff(Rejuvenation)", "raid16.health <= 90"}, "raid16" }, -- Rejuv.
{ "Swiftmend", { "raid17.range <= 40","raid17.buff(Rejuvenation)", "raid17.health <= 90"}, "raid17" }, -- Rejuv.
{ "Swiftmend", { "raid18.range <= 40","raid18.buff(Rejuvenation)", "raid18.health <= 90"}, "raid18" }, -- Rejuv.
{ "Swiftmend", { "raid19.range <= 40","raid19.buff(Rejuvenation)", "raid19.health <= 90"}, "raid19" }, -- Rejuv.
{ "Swiftmend", { "raid20.range <= 40","raid20.buff(Rejuvenation)", "raid20.health <= 90"}, "raid20" }, -- Rejuv.
{ "Swiftmend", { "raid21.range <= 40","raid21.buff(Rejuvenation)", "raid21.health <= 90"}, "raid21" }, -- Rejuv.
--!!!!!!!!!!!!!!!!!!!!!!!        END SWIFTMEND   !!!!!!!!!!!!!!!!!!
```

Which it still only SOMETIMES casts, and yes its towards the top of my rotation in priority....
Also it seems to cast more so while moving than not, but it does sometimes when not moving. It's very inconsistent.

----------


## Mackdaddy2887

I think I might know the error here.

Consider the warrior spell Raging Blow, it doesn't have a cooldown, it is only castable if you have a stack of raging blow.

Now consider this code:



```
{"Raging Blow"},
```

PE doesn't get hung up trying to cast this ability when you don't have the buff, PE knows when an action is usable.

I believe the same is the case with swiftmend. Swiftmend is only usable when targets have Rejuve, but it's not looking at the target, it's looking at the player. swiftmend itself is greyed out when you don't have rejuve on yourself. But if you were to target another target that has the rejuve, swiftmend lights up showing usable. I believe PE won't cast swiftmend unless:
A. You yourself have rejuve, showing PE the action is usable, or
B. Your targeting someone who has rejuve, showing PE the action is usable.

So, in my profile, I must either make it constantly auto target people, or keep rejuve on myself 100% of the time.

I haven't been able to test yet since I'm at school, but it coincides with my previous testing, and logically makes sense. This must be the case.

Can we have a fix for swiftmend? I can put the required conditional that the target have the buff in my profile, to keep it from getting stuck.



EDIT: Confirmed. This is the problem. Will keep Rejuve on self 100% uptime until this is resolved, in order for the routine to cast it correctly

----------


## Snitzel29

Kill Shot and other execute type spells have the same problem you're describing

----------


## Malloot

> I think I might know the error here.
> 
> Consider the warrior spell Raging Blow, it doesn't have a cooldown, it is only castable if you have a stack of raging blow.
> 
> Now consider this code:
> 
> 
> 
> ```
> ...


MTS used to have a solution to this with Spells like SWD, Kill shot etc. He made a unit cache function and checked that for any mobs around to meet for example SWD conditions. The generic unit cache function seems to be out of the addon pack now as i guess there where problems with it. However the raid/party chache system is still in there. 

He then made a function for a specific spell to check that cache and use the ability on any mob around that meets the conditions. 
** Priest - Shadow Word: Death **
DESC: Uses unit cache to verify if any unit around
meets Shadow Word: Death Conditions.

Build By: MTS
---------------------------------------------------]]
SWD = function()
for i=1,#mts.unitCache do
if not mts.immuneEvents(mts.unitCache[i].key) and mts.unitCache[i].health <= 20 and UnitCanAttack("player", mts.unitCache[i].key) then
if mts.Infront(mts.unitCache[i].key) then
ProbablyEngine.dsl.parsedTarget = mts.unitCache[i].key
return true
end
end
end
return false
end,

I am quite sure the same could be done for Swiftmend, check the MTS unit cache file and the fix from about 10 days ago on Github called Better Generic Cache and cleaner dots for more info as i only understand what it does, not how its done

----------


## Snitzel29

I've actually tried this with Kill Shot,it still doesn't work unless you're targeting the mob with <= 35% health (the same thing works no problem for other spells like arcane shot, etc)

the best thing ive come up with is to /target the mob before casting, it's not ideal but it works

----------


## StinkyTwitch

Feature:
Whitelist of UnitID's that will bypass UnitAffectingCombat checks.
Details:
There are a number of Units in WoD that are attackable but are not considered In Combat with the "player". Here is a list of Units I've researched so far.


```
    31144,      -- Training Dummy - Lvl 80
    31146,      -- Raider's Training Dummy - Lvl ??
    32541,      -- Initiate's Training Dummy - Lvl 55 (Scarlet Enclave)
    32542,      -- Disciple's Training Dummy - Lvl 65
    32545,      -- Initiate's Training Dummy - Lvl 55
    32546,      -- Ebon Knight's Training Dummy - Lvl 80
    32666,      -- Training Dummy - Lvl 60
    32667,      -- Training Dummy - Lvl 70
    46647,      -- Training Dummy - Lvl 85
    60197,      -- Scarlet Monastery Dummy
    67127,      -- Training Dummy - Lvl 90
    87761,      -- Dungeoneer's Training Dummy <Damage> HORDE GARRISON
    88288,      -- Dunteoneer's Training Dummy <Tanking> HORDE GARRISON
    88289,      -- Training Dummy <Healing> HORDE GARRISON
    88314,      -- Dungeoneer's Training Dummy <Tanking> ALLIANCE GARRISON
    88316,      -- Training Dummy <Healing> ALLIANCE GARRISON
    89078,      -- Training Dummy (Garrison)
    87318,      -- Dungeoneer's Training Dummy <Damage>
    -- WOD DUNGEONS/RAIDS
    75966,      -- Defiled Spirit (Shadowmoon Burial Grounds)
    76220,      -- Blazing Trickster (Auchindoun Normal)
    76518,      -- Ritual of Bones (Shadowmoon Burial Grounds)
    79511,      -- Blazing Trickster (Auchindoun Heroic)
    81638,      -- Aqueous Globule (The Everbloom)
    153792,     -- Rallying Banner (UBRS Black Iron Grunt)
    77252,      -- Ore Crate (BRF Oregorger)
    79504,      -- Ore Crate (BRF Oregorger)
    86644,      -- Ore Crate (BRF Oregorger)
```

----------


## turtlemans

Bug: DK Ability Cooldowns
Build: 6.0.3r13

Details:
When the runes required for a death knight spell have a longer cooldown than the spell itself, player.spell(x).cooldown returns the rune cooldown, not the spell cooldown. 

This makes it difficult to use blood tap in any DK rotation.

----------


## snowhawk

*Bug*: PE stops working when grasped on Kromog in BRF.
*Build*: 6.0.3r13

*Details*:
The Kromag encounter has a debuff Rune of Grasping Earth that indicates a player is being grasped. This grasp animation triggers the UnitInVehicle check and causes profiles to stop. Quick workaround below.

system\timers\rotation.lua::53


```
and UnitInVehicle("player") == false
```

to



```
and (UnitInVehicle("player") == false or UnitDebuff('player', GetSpellName(157059)))
```

*Feature*: timetoexecute/executein/timetohealth functionality
*Details*:
I'm looking to avoid stopcasting to execute, cast certain spells prior to execute, and to allow easier secondary resource maintainence. The function could smart check execute ranges based on spec or could allow a health% argument to be passed to a function like timetohealth().

----------


## StinkyTwitch

Actually its better to just replace:


```
and UnitInVehicle("player") == false
```

with


```
and UnitHasVehicleUI("player") == false
```

I've already submitted a fix on the gitlab source.

----------


## barandeniz

is there any solution to issue that reseting CR and PE configs when we use github application to sync PE ? i want to use github but its very annoying to set up all confings when we enter to game everytime. ?

----------


## Malloot

Would be really nice if we could get "or" to work some way, preferably with the same | simC uses for easyer translation of SimC code

----------


## StinkyTwitch

A SimC translator is probably not going to happen. I can tell you that "or" has been in the works for a while. The developer working on it just recently got back into the dev channels so we'll see if it makes it to the live branch soon.

----------


## Malloot

> A SimC translator is probably not going to happen. I can tell you that "or" has been in the works for a while. The developer working on it just recently got back into the dev channels so we'll see if it makes it to the live branch soon.


Yeah simC translating is easy enough as is, would be cool to have that "or"

----------

