SPQR - The passive DPS rotation

[soheil55]

yes i have these 2 picture

that one is a aoe mode in trash mobs of the blackfuse boss (soo) ,



and it was a profile from averykey i upload it for u maybe some usefull code be there

paladin

[Nonowmana]

it seems complicated :/
Nonowmana can you assist me to make pet interrupt actually works .. ?

Pet Spells are not (yet supported).

[lockslash]

Pet Spells are not (yet supported).

Maybe you can use with Grimm of Sacrifice (without pet)

[chumii]

Hey, while looking through the pages for a solution, maybe someone can help me quicker...

downloaded from first post, unpack, start, get this http://puu.sh/8kLI6.png

any ideas?

edit: got it, 32bit....

[Koha]

Hey, while looking through the pages for a solution, maybe someone can help me quicker...

downloaded from first post, unpack, start, get this http://puu.sh/8kLI6.png

any ideas?

edit: got it, 32bit....

Windows 8 or 7?

[Nonowmana]

Hey, while looking through the pages for a solution, maybe someone can help me quicker...

downloaded from first post, unpack, start, get this http://puu.sh/8kLI6.png

any ideas?

edit: got it, 32bit....

Not administrator account or 64bit wow.

[wanted77]

Nono, have you managed to confirm my immolate bug/issue on your warlock?

[gen4ik]

To know the correct ID spell copy-paste in wow dialog this:

/run for i=1,200000 do local f=FindSpellBookSlotBySpellID(i,"spell") if f then local n,id=GetSpellBookItemName(f,"spell"),select(2,GetSpellBookItemInfo(f,"spell")) local s=GetSpellInfo(id) s=n==s and " " or "\124cFF4FF763"..s print(id,n,s) end end

Or just install add-on IdTip. It's show in tooltip ID of spell, buff or debuff. =)

[nrgd]

I've been doing some performance test with my profile. Because rotations are based on the CanCast() method, it's important to know how much time takes to execute the combatlogic() routine as it will mark the time the rotation looses before checking again another canCast().

Single rotation: [Average:110 miliseconds, Max:436 miliseconds]
AOE rotation: [Average:124 miliseconds, Max:424 miliseconds]

That means that in the worst case scenario the rotation will cast an spell 430 miliseconds later than it would been able to cast it, and on average only about 115 miliseconds later. The worst case scenario is when we check for a canCast() and returns false, but there were only a few miliseconds left of cd, which hopefully shouldn't happen very often.

Overall the performance is pretty good, and SPQR should allow rotations with really good dps... nice work Nonowmana!

[Kinky]

I've been doing some performance test with my profile. Because rotations are based on the CanCast() method, it's important to know how much time takes to execute the combatlogic() routine as it will mark the time the rotation looses before checking again another canCast().

Single rotation: [Average:110 miliseconds, Max:436 miliseconds]
AOE rotation: [Average:124 miliseconds, Max:424 miliseconds]

That means that in the worst case scenario the rotation will cast an spell 430 miliseconds later than it would been able to cast it, and on average only about 115 miliseconds later. The worst case scenario is when we check for a canCast() and returns false, but there were only a few miliseconds left of cd, which hopefully shouldn't happen very often.

Overall the performance is pretty good, and SPQR should allow rotations with really good dps... nice work Nonowmana!

Still something that needs to be worked out as for all classes, delays between casts is going to drag the performance to the ground. I.e. working with procs, you'll get less casts off within the windows that you have to do so. I don't think there's much of a reason to add a GCD check to the method, queuing the next spell before the current has finished is a benefit of WoW.

[nrgd]

Still something that needs to be worked out as for all classes, delays between casts is going to drag the performance to the ground. I.e. working with procs, you'll get less casts off within the windows that you have to do so. I don't think there's much of a reason to add a GCD check to the method, queuing the next spell before the current has finished is a benefit of WoW.

Well, you either check if you can cast the spell or you spam the spell and check if it has been cast... I don't understand what do you mean by queuing the next spell, if you are in GCD, you can't cast anything till GCD is over.
I don't see how it can be done without checking if you can cast the spell or if the spell has been cast, maybe you could elaborate more on how this could be achived? anyway I don't think the performance is that bad with the current method.

[Kinky]

Well, you either check if you can cast the spell or you spam the spell and check if it has been cast... I don't understand what do you mean by queuing the next spell, if you are in GCD, you can't cast anything till GCD is over.
I don't see how it can be done without checking if you can cast the spell or if the spell has been cast, maybe you could elaborate more on how this could be achived? anyway I don't think the performance is that bad with the current method.

It's not bad but it isn't good, just simple code and not so much the actual performance.

WoW works on a queue system with custom lag tolerance. You can begin queuing the next spell while the current one is being casted; obviously not using this is a flat decrease in performance. With melee this would simply be with the global cooldown, which would act the same.

A normal cast should be like so:
Cast|------------------------NextQueuedCast-----||-------------------------------|

Where as SPQR currently handles it like this:
Cast|-------------------------------|<Pause>NextCast|-------------------------------|

You can test this yourself. Simply manually spam a spell, and there should be absolute fluidity into the next cast, without the noticeable delay between them with SPQR's casting.

[averykey]

Someone can help me ?
Tried to add warlock interrupt in Warlock.cs

First i added the ID

OpticalBlast = 115781,

Then i added this line

if (TARGET.IsCasting)
MySPQR.Internals.ActionBar.CastSpellById((int)Spells.OpticalBlast);

And it's not interrupting the target ...

command demon

[Nonowmana]

It's not bad but it isn't good, just simple code and not so much the actual performance.

WoW works on a queue system with custom lag tolerance. You can begin queuing the next spell while the current one is being casted; obviously not using this is a flat decrease in performance. With melee this would simply be with the global cooldown, which would act the same.

A normal cast should be like so:
Cast|------------------------NextQueuedCast-----||-------------------------------|

Where as SPQR currently handles it like this:
Cast|-------------------------------|<Pause>NextCast|-------------------------------|

You can test this yourself. Simply manually spam a spell, and there should be absolute fluidity into the next cast, without the noticeable delay between them with SPQR's casting.

You can write your own CastingSpellById like this :

 public static void CastSpellById(int spellId)
        {
            if (MySPQR.Internals.ObjectManager.Target.IsValid)  /*return true if the Target is valid(exist) or not dead*/
            {
                if (MySPQR.Internals.ActionBar.CanCast(spellId, false)) /*return true if your char can use the spell (check cooldown) No GCD check*/
                {
                    //MySPQR.Internals.ObjectManager.Target.Face();
                    MySPQR.Internals.ActionBar.GetSlotById(spellId).Execute();  /*if all is ok, this will get the ActionBarSlot for your spell,
                                                                                 and execute the right Keybind to cast it*/
                }
            }
        }

It will spam the key just before the end of effective cooldown

[nrgd]

Didn't know that canCast() didn't check for GCD... My bad