PQR - Rotation Bot

[MrBrain1]

i really tried to wrap my brain around this for like 5 minutes but i cant figure out what you mean :/

sorry for the sloppy writing. I encoutered the problem, that if im heading into the loadingscreen, it just doesnt begin loading and aborts the loading screen with the error message "instance not found". when i close Pqr, the loading screen instantly starts filling.

[Weird0]

sorry for the sloppy writing. I encoutered the problem, that if im heading into the loadingscreen, it just doesnt begin loading and aborts the loading screen with the error message "instance not found". when i close Pqr, the loading screen instantly starts filling.

you mean like logging in or changing instances while being ingame ?

either way i never encountered such a problem.

is it only with one specific profile or with all you have ? what version of pqr are you useing?

[CodeMyLife]

sorry for the sloppy writing. I encoutered the problem, that if im heading into the loadingscreen, it just doesnt begin loading and aborts the loading screen with the error message "instance not found". when i close Pqr, the loading screen instantly starts filling.

My old router was doing this.. DNS error somehow.

[Kinky]

I really urge people to report fittytyson if he's being a major douche. It's much easier to be done with the entire problem that way than feeding it.

You being failroad or not is debatable, at least you've picked up a much needed refresh of your English rapporteur and is actually writing somewhat properly now if so. Otherwise, good for you. No one is forcing you to browse or even reply to this thread. Running your moth or being nasty to others isn't really doing you any favours, even if you're doing it in your defense. There is both the ignore and report feature readily available to you if you feel attacked.

@vitalic: That looks almost like my PvP data file. there are a lot of way to check for CCs and other effects through the WoW api itself, though they won't be as thorough as a customized function for that excact purpose. I had something whipped up for that if you want me to post it on the morning, though!

Sent from my HTC One using Tapatalk 4

[vitalic]

right before the "for" loop.

now a few problems I see with your coding style, is that "type" is an LUA word, so I like to shy away from using it as a variable, you could just use "ccType" if you want, or something else, like subtype.

also doing "nil == " is just odd, i mean yes, it should work, but its best to do an "if not" something, for clarity purposes.

Unfortunately you don't seem to understand the nature of the problem, and so all you've done is re-create the current way that the majority of people check for categories of debuffs, which results in a lot of redundant API calls. When consecutive rotation abilities are churning through these big tables of CCs (my example code only shows a fragment of them) it starts to have performance implications, and this is one of the reasons some users with less powerful computers experience frame rate drops.

I'm surprised you missed that point considering you saw the context of the thread that this code spawned out of.

As for your needless nitpicking, the type comment has some validity, but I do not like the "if not" convention in LUA, as to me not implies that you are asserting a value is false, and so I opt to be specific by referring to nil, having nil as the first part of the expression is just a personal convention.

[vitalic]

@vitalic: That looks almost like my PvP data file. there are a lot of way to check for CCs and other effects through the WoW api itself, though they won't be as thorough as a customized function for that excact purpose. I had something whipped up for that if you want me to post it on the morning, though!

Lol really? I got the tables from some really old thread ([PQR] [PvP] Lists) from 2012.

I know there is always more than one way to skin a cat with the WoW API, but my only concern here was efficiency. If we imagine a target who currently has 5 debuffs on them, a traditional function would result in 30+ API calls as it has to use UnitDebuffID() on every member of the table, where as this code would result in...5 API calls, before UnitAura() returns a nil value and we can safely say they are not affected by the type of debuff we are interested in.

[vitalic]

The method I posted is the most efficient way to parse a list in LUA, Ive NEVER had fps issues with it.

The only issues that cause FPS errors in lua coding is the overuse of ipairs, and using the pqr distance excessively.

Lets get one thing clear about my "nitpicking", you told me to come check out your code. "nil == " is backwards logic, its really bad form. Its not nitpicking, its common sense with coding., i was really just trying to help you out.

So much fail. It's nothing to do with "the most efficient way to parse a list", the point is you are parsing a list when you don't need to. If you can avoid doing unnecessary work, especially when that work is being repeated in large quantities, then it makes sense to re-factor, fundamental of computer science.

You contest the fact it could cause "FPS errors", whatever that is, but how many profiles have you published? How many users do they have? Are you judging it on your personal experience?

Even if it doesn't make any practical difference to performance and other factors are the cause of FPS drops, it's still going to shave off a few CPU cycles, which on large scale/complex profiles is never a bad thing.

[vitalic]

yea youre right, im nobody. good luck with your less CPU cycles, master coder.

I don't really care if you wrote the first ever LUA profile and have had ten million downloads, sound logic wins no matter who you are.

Also your PM was kind of hilarious, "I'll do a quick cleanup of your code", oh how kind of you.

[vitalic]

your method is slightly different, and slightly worse on memory usage, I don't know what else to say, but think what you want and recode all your lists that way, its fine, you wont see any improvement.

The tables could be either way, it doesn't matter as much, the point is you are reducing the number of WoW API calls drastically.

[xNotta]

Anyone else trying to use PQR on the PTR getting a huge FPS drop that eventually causes the game to just stop because of the lack of FPS?
I've tried 3 different profiles all that drop FPS till the game stops.
Is there a fix for this?

[MrHeroe]

Thank you all for your kind help. I was doing very well creating my own pvp holy priest profile.

Vitalic pointed out - blocked addons are the result when the client tried to run a protected function from within the game or same global variables.
I have some those erros after a arena game. If i deactivate the blocked addon, another addon is affected, then the original blizzard raidframe... and after all wow.lua blablabla throws an error. But those errors seems not to stop pqr working. The profile works, more or less, i think the errors affecting my performance, though.

what kind of pqr code can cause this "protectec call" errors? Loops? Variables? combat log parsers?

i only use this global variables:
purgeTime
lastTextTime
"PQR_ResetMovementTime" (yeah its pqr related)
DPSKey
FearKey
MDKey
drinkKey
rezzKey
DivineHymnKey
SpectralGuiseKey
PsyfiendKey
AngelicFeatherKey
ChastiseKey
LightWellKey
ShackleKey
waitForCcKey

I use the keys on a logitech mouse with 12 keys. So i can configure the mouse keys to push (e.g) shift+alt. Thats how i use so many keys. The keys not affecting each other since i use "shift + alt and not rightCTRL" for example.

Can you help me please find the problems?

Best regards
Mr.

[aenyth]

Hello all

I have a problem. When i use a pqr profile, I have some lags and the game crashed ( Wow retail problem ).
I use pqr 2.22, but PQInterface add'on is out to date.

Anyone have a solution please ?

ps: excuse my english, i'm french

[Carkas]

ps: excuse my english, i'm french

You're French?

Hmmm.

Ok you're forgiven.

[vitalic]

no, youre not, but like i said, do what you want. Its not going to be more efficient, and by that i mean memory usage, but who am i saying this to, youve coded "The best ever Rogue PvP Profile".

edited:

actually heres what u can do instead of using MAX_TARGET_DEBUFF in your code

function _maxDebuff(unit)
local i=1;
    while UnitDebuff(unit,i) do
        i=i+1;
    end
    return i;
end 

your MAX_TARGET_DEBUFF iterates the code 16, and ill put it in your terms "CPU cycles" nomatter what you do

but this would still be not as effective as just going directly to the index ( for i=1,#list do) and then checking a unitdebuffremains on that list item.

honestly if you think its better, then good for you, im not really trying to start fights here, im just trying to help you. if you think its better, then fix up all your lists that way, and please let me know if it truely is, but its the inefficiencies in PQR's C coding that cause alot of the FPS drops in "complex" profiles as you put it, and not only that but also the use of ipairs which iterates over all elements in an array and when you have alot of item in that array will cause some studder.

further edited for maxDebuffs, that way you wont need to use your select(11, and check about if its harmful or not. now i know youre the best coder and all, but theres just my tips! take it or leave it.

all that being said, even with my code above, the code still is only slightly different, and will prove slightly less memory-efficient. now thats all ill say on the matter. thanks for hearing me out (or not, i dont care).

I don't even know where to begin. Almost everything you said in that post is mindbogglingly wrong. My algorithm doesn't iterate 16 times every time, because it returns false as soon as UnitAura returns nil the first time (I.e. because there are no more auras). I used MAX_TARGET_DEBUFFS simply for convenience, because if a target has more than 16 debuffs in a PvP situation then they are probably going to be dead in about two seconds anyway, but it could easily be changed to 40 if we wanted to cater for the theoretical maximum number of auras. It doesn't have any effect on the computational efficiency of the solution.

Also your maxDebuff function is completely redundant in my solution, and in fact represents even more extraneous API calls, for the reason I just mentioned. You have to be seriously dimwitted not to notice this especially after having had so long to edit your post.

Now, it's true that converting the table to an associative array/hash table does incur an additional memory cost, but in most cases I find that it's reducing CPU execution time that is more critical in optimisation of this kind, which is why you can have an addon that uses only 200 KB of memory, but has more of an impact on your FPS than an addon which uses 5 MB. From the profiling I did, a single dictionary lookup is faster in LUA than looping through an indexed array and comparing against each element within it, and so I'm comfortable with taking that marginal one time increase in memory usage. Optimisation often requires trade-offs and prioritising the attribute you are most interested in (in this case CPU usage).

I think i adequately explained why my solution is more efficient in my earlier reply to Mentally, and I'm yet to see you refute that logic. I trust that any profile writer who knows what they are doing will see the code and use their own discretion to decide whether it's a better way to do it, and so there isn't much point continuing this discussion and de-railing the thread. Cheers.

[vitalic]

I cant mention names but developers of several different hacks for wow and that I am absolutely certain have more coding experience than you (have sales in the tens of thousands of users) agree that method is less memory efficient. Not too sure what else to say about it. Agree to disagree I guess? But logically it uses slightly more memory. But even then younwouldnt see any more or less fps with either of our listing techniques

The first mistake you are making is assuming that memory efficiency is the only type of efficiency that matters.

The second mistake you are making is not realising that the tables could be setup in either way and the solution would still be more efficient.

Perhaps I can illustrate it this way, consider a hypothetical situation where Blizz suddenly adds 50 new types of roots. How much slower does your solution get? Well it now has to trundle through an extra 50 items and run UnitDebuffID against each of them. How much slower does my solution get? No slower. Because it's only looking at the *current* debuffs on the target and checking those against our list. The only situation in which my way of doing it would become less efficient is if the number of debuffs currently on the target exceeds the number of items in the table, which is rarely going to be the case.