modifier.last not working correctly? help plz

[Mackdaddy2887]

NOTE: the below code I was using for testing purposes


{ "!115175", { "lowest.health <= 100", "!player.moving", "!modifier.last(Soothing Mist)" }, "lowest" }, -- Soothing Mist


yet it spams Soothing Mist.


PE AL:





What I want to do:
(again just using this as testing, actual usage will vary)


--Testing
{ "!115175", { "lowest.health <= 100", "!player.moving", "!modifier.last(Soothing Mist)" }, "lowest" }, -- Soothing Mist
{ "124682", { "player.spell(Soothing Mist).casting", "lowest.health <= 100", "player.chi >= 3" }, "lowest" }, -- EnM
{ "116694", { "player.spell(Soothing Mist).casting", "lowest.health <= 100" }, "lowest" }, -- Surging Mist



The LOGiC behind this:

--- ! soothing mist, so itll cancel the previous one (as long as it wasnt the last thing cast)
---It'll enveloping Mist (if channeling) if >3 chi
---It'll surging (if channeling)



The reason I dont do it like this:
- enveliping
-surging
-soothing


Is because I want it to Envelop/Surging the most recent target of Soothing. If arrange like above, itll EM/SM the previous target (because of the mechanics of those abilities)


--- So in essence I want it to:
1. Aquire New soothing target
2. EM that target if applicable, then back to step 1 (otherwise proceed to step 3)
3. Surg that target then proceed back to step 1


Now, what stops this from working correctly, is !modifier.last(soothing mist), and just plain !modifier.last arent working, so it spams soothing even though soothign was inded that last spell casted.






(also, for surging/EM, would I use: "player.spell(Soothing Mist).casting" OR "player.spell(Soothing Mist).channeling")

[Mackdaddy2887]

figure a lot out. Spent hours testing.

see this post in the conditions thread http://www.ownedcore.com/forums/worl...ml#post3230127 (Conditions List)

[zeldaboch]

NOTE: the below code I was using for testing purposes


{ "!115175", { "lowest.health <= 100", "!player.moving", "!modifier.last(Soothing Mist)" }, "lowest" }, -- Soothing Mist


yet it spams Soothing Mist.


PE AL:





What I want to do:
(again just using this as testing, actual usage will vary)


--Testing
{ "!115175", { "lowest.health <= 100", "!player.moving", "!modifier.last(Soothing Mist)" }, "lowest" }, -- Soothing Mist
{ "124682", { "player.spell(Soothing Mist).casting", "lowest.health <= 100", "player.chi >= 3" }, "lowest" }, -- EnM
{ "116694", { "player.spell(Soothing Mist).casting", "lowest.health <= 100" }, "lowest" }, -- Surging Mist



The LOGiC behind this:

--- ! soothing mist, so itll cancel the previous one (as long as it wasnt the last thing cast)
---It'll enveloping Mist (if channeling) if >3 chi
---It'll surging (if channeling)



The reason I dont do it like this:
- enveliping
-surging
-soothing


Is because I want it to Envelop/Surging the most recent target of Soothing. If arrange like above, itll EM/SM the previous target (because of the mechanics of those abilities)


--- So in essence I want it to:
1. Aquire New soothing target
2. EM that target if applicable, then back to step 1 (otherwise proceed to step 3)
3. Surg that target then proceed back to step 1


Now, what stops this from working correctly, is !modifier.last(soothing mist), and just plain !modifier.last arent working, so it spams soothing even though soothign was inded that last spell casted.






(also, for surging/EM, would I use: "player.spell(Soothing Mist).casting" OR "player.spell(Soothing Mist).channeling")

Question: what is the "!" before the spell id?

Are you sure to use player.spell(SM).casting ? Isn't it a channeling? I think you have to use channeling but not not sure how to use the condition.

For example:

player.channeling(spellID)

AND can PE execute another actione while channeling??

[Mackdaddy2887]

Yes that's what the. ! Is for. ! Before the spell will cast IMMEDIATELY upon returning true, I.e. it'll cancel the current cast if it's casting.

I figure out what I sat out to do though, but the issue above still stands. I tried every possible combination, and all your suggestions. So I'm not sure.

But I did get it to work using a work around and get it to do what I wanted. Thanks for you help!!

[zeldaboch]

Can you explain the workaround?

[Mackdaddy2887]

Lots of Explanation points in the rotation to force interruption of Soothing mist.

also, "!modifier.last(soothing mist)" doesnt work, but using just plain "!modifier.last" does work.


"!modifier.last(soothing mist)" logically reads:
Return True if the last cast ability WASNT Soothing Mist, else Return False
Yet even though it was the last cast ability, it still returned true. so Broken?!?!?

Where as: "!modifier.last", which without () references the ability that this is a condtion of, reads the same, and it DOES work.


so what Im thinking is that when using a negative conditional, the function doesnt take into consideration the conditional conditionals. Whether its () associatied with the conditaional, or the extended, like .duration or .count
for example,

"!player.buff(raging blow)" doesnt register raging blow, but whatever ability its a condition of.

Let me expand this example:

{"berserker rage", {"!player.buff(raging blow)", "!player.buff(enrage)" }},

In this example, both the "!player.buff(enrage)" and "!player.buff(raging blow)" are the same!!! because Im thinking the negative conditional only causes the condition to reference the ability, and in this case, the resulting buff from Berserker rage is Enrage, so the negative conditionals reference that, not whats in ().

----JUST A THEORY after some testing. Then again, it could just be all the crazy mechanics of Mistweaver that make it seem that way?!?!


Also, in a similiar example, I do believe, whether or not it my above theory is true, I do believe that the secondary conditional of a negative is ignored.
{"berserker rage", {"!player.buff(raging blow).count >= 2", "!player.buff(enrage)" }},

the "!player.buff(raging blow).count >= 2" logically reads:
Return True if player DOESNT have 2 or more raging blow stacks.

But I believe, if my first theory is wrong, that it only actually reads
Return True if player DOESNT have raging blow stacks.
Or just always true or always false, a broken one. IDK!!!!!

So I think the best way to deal with the issue I was having, is using logic that doesnt use Negative conditionals as much as possible:
"!player.buff(raging blow).count >= 2" is the same as saying "player.buff(raging blow).count < 2" or "player.buff(raging blow).count <= 2"

Or I could just be sleep deprived

[Mackdaddy2887]

Can you explain the workaround?

I rambled on... sorry. As for the answer to your question:

Include "lowest.buff(115175).duration <= 1" as a condition. The channel leaves a HoT on the target so long as your channeling on that target. Effectively, it wont spam it on the same target if its already on said target. So this line:

"!115175", { "lowest.health <= 99", "!player.moving", "lowest.buff(115175).duration <= 1"}, "lowest" },

Will effectively do this:
Always be channeling on whoever is lowest, without spamming that player. IF someone else drops lower, it will stopcasting and recast on whoever is the lowest. This is the LAST line, absolutely last, as it will almost always return true.

to ensure more effective single target healing, and not always reaquiring a new target (example: raid wide constant damage, other healers are healing too, so the 'lowest' is always changing), so you dont want it constantly finding new targets, without doing some additional healing. SOOO, say you just want to sooth unless someone drops below 85%, so do this:

  { "!115175", {"lowest.health <= 85","!player.moving", "!modifier.last","lowest.buff(115175).duration <= 1"}, "lowest" }, -- Soothing Mist
  { "124682", { "player.casting", "lowest.health <=85", "player.chi > 2" }, "lowest" }, -- EnM
  { "116694", { "player.casting", "lowest.health <= 85","!modifier.last" }, "lowest" }, -- surging

   {"!115175", { "lowest.health <= 99", "!player.moving", "lowest.buff(115175).duration <= 1"}, "lowest" } --soothing

What this accomplishes is:

Above 85%, just soothe whoever happens to be lowest,the ! will cancel the current channel and recast on lowest. It wont spam the lowest, because of what I mentioned above.

Once you drop below 85%, you add "!modifier.last", so it wont keep rechoosing a new low target (in case of the example I previously mentioned), but instead, itll cancel the previous channel, aquire the target, and wont cast again until you cast something else. In this case, itll instant cast Enveloping if you have >=3 chi, otherwise, surging. Now that you have given that nice low fellow some extra healing, it will continue to heal him (if below 85% still), or, if a new raidmember becomes the 'lowest' it will go to that person, give them some surging/Enveloping, then on to the next.


Im working on editing my single target section of MW now, here is my logic thus far:

  { "!115175", {"lowest.health <= 60","!player.moving", "!modifier.last","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", "!modifier.last","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","!modifier.last" }, "lowest" }, -- Surging Mist
    { "!115175", {"tank.health <= 90","!player.moving", "!modifier.last", "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", "!modifier.last" }, "tank" }, -- Surging Mist
    
    { "124682", { "player.casting", "lowest.health <= 92", "player.chi > 2" }, "lowest" }, -- EnM dump chi
    {"!115175", { "lowest.health <= 99", "!player.moving", "lowest.buff(115175).duration <= 1"}, "lowest" }, --soothing

[ImogenOC]

I believe this has been fixed in the most recent update.