Runes of Magic US / AU

Would it be possible to access the disk outside the ROM folder? Already with DIYCE, I never liked the fact that my custom scripts where stored somewhere inside "Program Files" which should only contain content that I can re-install. So, suppose that I create C:\Data\ROM\scripts, or even on the D: drive... could you access that?

As far as I know we can only access files within the Runes of Magic installation directory.

.frafall

I'm having trouble getting a set skill to fire. I've seen it activate in very specific situations on recorded video, but it should be activating a lotmore often. for reference here is a bit of the attack function/script ( I added a variable to check race in the vars file b/c some elite skills of w/wd)



I can see on the fdiyce HUD that action slot 20 tries to fire, which is the item set skill brash ferocity strike. However, I have recorded video where within 1 second, it wants to use action 20 first, doesn't cast b/c of GCD, then changes its mind and goes to open flank instead. I have other recorded instances where the skill doesn't try to fire at all, despite all conditions being met, and being higher in priorty then open flank...and yet open flank is what fdiyce wants to cast.

What appears to be occuring is if i spam the macro multiple times a second, fdiyce doesn't appear to be returning the cooldown on the action bar slot -- that is to say, while GCD is in effect fdiyce wants to cast a lower priority skill that is not a tryAction command. However, if i manually use probing attack (a pre-requisite skill to the Item-set skill and/or action slot in question), then use fuzzydiyce macro after GCD ends, it activates as it should. There is some conflict between GCD and the tryAction command.

Which version are you using?

The 'Race' variable, can u show the implementation as this is prereq for using Action 20? Have you tested without the Race prereq?

What value is configured for the CutCD config variable? (check interfaces/FuzzyDIYCE)

.frafall

X-Curse-Packaged-Version: v0.5
in the vars.lua file I have


Initial tests (when reporting issue) were with race variable, with multiple cutCD settings, none of which were zero.

Testing without race variable ended up with the same (appearnig in HUD but not executing), EXCEPT when cutCD was 0. In this case it worked. Tested with race variable and it worked with cutCD 0.

So it will activate, but only with cutcd 0. The issue with this, is that as a /warden class, I want to be able to use as close to 2skills per second as possible (warden skill Charged Chop does not trigger GCD on other skills making this possible). Without the cutCD option, I get fewer skill activations per second, lowering my dps.

EDIT: i just tested with a slightly different implementation of race (returns true/false if humanoid/beast, rather then a string to compare later), and the action slot triggered with cutCD 0.25. The next trial it did not trigger, with same settings. Kind of confused now.

EDIT2: just got it to trigger with cutcd 0.5. now i'm even more confused then before.

The CutCD is a tunable parameter, FD use something like:
It is based on it being possible to kick off a new UseSkill/UseAction slightly before the cooldown is finished due to time delay between client and server. This is not only ping time but also delays in client and processing at server side. The goal is to get skills executed back-to-back with as little delay between them as possible. But, there are no correct answer for what the value should be. Setting it to high will try to trigger skills before they'r ready.

I am trying to figure out a test case to measure this but haven't managed yet..

I play w/wd as main myself and been struggling with same issue, how to get as close to 2 attacks per second.

I think we have two separate issues here:

1. How to optimize w/wd attack speed, preferably with one attack each 0.5s
   
2. How to tune the CutCD for best (consistent) performance
   

For 2) I suspect you have CutCD set to high as you get inconsistent result but there might be other issues at large here...

My only idea so far to measure CutCD is to use a skill and measure the time until the cooldown in the client starts ticking, I noticed in a macro that I can do (pseudocode):
and it will return remaining time 0 on 1st print, i.e. server hasn't properly updated the client yet. That time delay might be possible to measure and should give a nice indication of CutCD - I have still to write the test code and insert into the DummySkills test script.

For 1) my best bet atm is to get the base script for w/wd running correctly and limit my click speed to approx 2 per second but I'm very open to discussions as my whole goal for starting using FD has been to optimize w/wd dps

.frafall

Tested out with something like this in a combat script:

Running this with Charged Chop, spamming the macro "/fdiyce TestCutCD 3 1" I got the following (with some calculations):

Quoted

25.781 CD 1.00/0.00 0.000 Charged Chop, 1s cooldown
25.945 CD 1.00/0.00 0.164 Cooldown not triggered
26.117 CD 1.00/0.90 0.336 Cooldown started 0.1s ago - at 0.236
26.273 CD 1.00/0.80 0,492 Cooldown started 0.2s ago - at 0.292

As far as I see it this I have approx 0.25s as my "use skill and get update back from server" roundtrip time so I would guess my ideal CutCD should not be higher than 0.25s approx.

Any comments, did I think all wrong here?

.frafall

@Peryl

Lol, didn't see your entry before pressing publish. Using those ideas it might actually be possible to have some kind of auto-tuning of the cutcd.

Might also be possible to have some kind of click monitor to have ppl tune their click rate to wanted rate

In regards to 2 skills per second, I have had much better performance with charged chop OUTSIDE of any diyce macro. i.e /cast Charged chop /run fdiyce attack style macro. Although I really haven't tried with fdiyce to compare to my standard diyce performance, this yielded better results. It is just that one ISS that is giving me problems.

In regards to set skills not activating, there was a similar issue I helped solve with diyce 2.0. A warlock ISS wouldn't activate even if the conditions were set to always be true. The work around was to implement an ExecuteMacroLine("/cast skill name") call in the combat routine, rather then using CastSpellByName() or UseAction() or other methods. This worked, while the other methods failed, for some reason --- perhaps my current item set skill problems could be solved with this? As mentioned the skill DOES activate, but not consistently/regularly. If I can figure out how skills are activated in fdiyce and modify it myself, then I will let you know if it works properly.

EDIT: implementing a tryCast option, that performs an ExecuteMacroLine("/cast "..skillname) has solved my error, and the skill activates as it should now. I haven't thought of any way of checking if it doesn't activate (return false) aside from putting the skill in question on an action slot and checking the cooldown on the action.

Well form my experience best way, to put 2 skills in 1 sec is to actually put non GCD skill (like CC) both outside DIYCE/FD and at the top of the DIYCE/FD script.

As for W/Wd or Wd/W, the problem still should be rage regeneration, but I have managed to actually put 240 skills over 2min period on Wd/S using that method and FD, my best (and regular score - +/- 2 skills) on Wd/W was 30 CCs+24 other skills over 30 sec - there was simply not enough rage or skill without CD (still close enough to 2 skills/sec). Using FD only my best would be 25-26 CCs + 24 other skills on Wd/W, so about 10% less DPS. One important thing is that using this method requires to tweak up "outside click", as you can lower no. of others skills form FD by 20-30%, making all thing pointless.
To put some perspective on regular DIYCE v2 + "outside click" with Wd/S, I was at 105-110 CC/120sec +other skills (well on old version it was pointless to use Shot, so no. of other skills was significantly lower).



As for tuning CutCD it will not be tuned perfectly anyway. First of all there is huge chance client/server will process yours skills in slightly different time, so you will have to set CutCD little lower than optimum value, lowering no. of used abilities (maybe not a huge difference or even unnoticeable, but still...) or you will still have to spam your macro. Second it will not make you click much less - still you will have to click FD macro just after using CC or any other non-GCD skill. OK it will be possible to reduce no. of clicks, as with hi CutCD it is almost required to simply spam FD as fast as possible, but you will have to rapidly click it after non GCD skill, and for some classes there is more than just CC. Another problem here (at least for me - and this is my main reason for using FD) is that I can not usually use skill right after CC, there is (as I call it) "minilag", that prevents any action just after another. Same thing happens on M/Wd - this class should be (in theory) casting as many flames during 5 sec burn as many times you can click your keyboard, but I haven't heard of any1 putting more than 30 flames during that time and (again in theory) my client accepts about 30-40 clicks/sec, so 150-200 flames should be possible. So once more spam after non-GCD skill.


Also ISS are a bit of problem, as both old DIYCE and FD is taking some time using anything form action bar. At first look it is unnoticeable, but if you can make "optimal combo", having enough energy to execute every skills during some period of time (longer = better) and look at no. of skills used it is almost certain, that anything from action bar will lag, actually if you will put action bar "thing" at the end of combo it will be still unnoticeable, but putting anything on top (lest say ISS just after CC) makes no. of used abilities lower. That's why on my last Wd/W combo ISS is just before manapot and rage regen skill and after any other skill or buff. Well maybe that's why I can not click skills manually right after using CC ("minilag" issue), so it don't have to be FD problem at all.

So, how to be able to reproduce/document these effects and figure out if its the addons (DIYCE/FuzzyDIYCE) or inherit
in the game? (Or just client playing mindtricks on me?)

One of the major features of FD has been to speed up execution, my personal goal has been to get addon DPS closer to a
well played manual burn which should be possible.

As far as I can summarize we have three vaque symptoms:

1. There seems to be a minilag issue which prohibits skill usage directly after a non-gcd skill both in DIYCE and FD,
   therefore we use macros which first cast CC and then FD
   
2. Using Actions with ISS seems to take longer time than skills
   
3. Unexplainable differences in using ExecuteMacroLine/tryCast and tryAction
   

I would need your help to figure out what is causing these issues and/or how to build test cases and do instrumentation of code to find the details. Ideally a script to exhibit the effect. Personally I've been using one of the weapon skill lvling spots to test attack sequences with HUD to examine details.

The HUD currently displays what FD is trying to execute with timestamps, the mechanism for this could just as well dump to a table which we could print and analyse after a fight if that would be helpfull. Perhaps include some execution times for different parts of code as HUD can print anything.

Any ideas?

.frafall

As for testing I am using VN Crevice or Mendoza something form N Janost Forest.

As for minilag issue it actually occurs without FD/old DI, moreover I think using FD/old is actually bypassing problem, as it seems to be somehow related to action bar, FD in that matter is late using CC after normal GCD on another skill, so maybe ISS problem is same issue with action bar itself no FD script.

Still using FD alone is still not optimal and I have no idea why. Simply my knowledge about lua or whatever is just basic.

I made an instrumented script for W/Wd, just testing out core attack sequence.
This script logs all parameters used in script as well as output from the COMBATMETER_DAMAGE event (which is input for scrutinizer).


This logs all parameters used as well as as damage data from COMBATMETER_DAMAGE (same as scrutinizer uses).

I spammed macro, approx 4 times per second, popped rage buff before starting, no other buffs/pots/pets.
Whole test was done with ample rage/mana, target "Kentiaru Defense Tower".

Findings:

• Some issues in FD, TargetHasBuff with table as argument returned false the whole test, with single argument
  returned a table, not boolean (to be fixed)
  
• Since bleed buff didnt register I only had Probing Attack and Open Flank skills used, will fix for more runs
  
• While spamming the macro I always manage to try a skill again before cooldown has triggered (0.25s window) - this might account for minilag of approx 0.2-0.3s
  
• I triggered a CC approx every 1.3s, min 0.98, max 1.67
  
• I triggered a PA/OF approx every 1.5s, min 1.33, max 2.64
  
• It seems updates of rage/mana takes approx 1s after skill is used, ie we calculate attack sequence on old data
  

So, this is way off optimal. But, this was ONE SHORT test, hard to be conclusive based on a small dataset.

But, the delay between skills triggered is not optimal, also due to update lag in mana/rage and cooldown we do calculations on old data.
Delay might be due to spamming, one every 0.25s might give up to this in delay, ie 1.25s between skills if your out of sync.

Any comments?

.frafall

For all my tests I am spamming my CC skill from action bar every 0,3s and FD macro 0,3s, with delay between them of 0,8sec. Also using any action form action bar tiggers not on pressing key, but on releasing it. Form my experience anything much lower actually lowers preference, but it should vary on different connections (ping) and probably servers, so you could have fallen in this trap.

Also there is some server issues, with skills CDs and GCD. Sometimes it is possible to spam 1 skill up to 6x in 1 sec, but later you will experience 5 sec GCD on everything. So measuring gaps between 2 skills could be not best way to do it.

I have also forgotten to write, that while testing any rage depend class it is good to have S/x (best would be S/r - with smoe lvl due to speed passive from /r) autoshooting test character (both have to be in PK state).

Good points, I made some benchmark toons, lvl50 s/r and w/wd for this

Also building a statistics extension for FD, just started but I get out averages for period of time like:

Quoted

Statistics time 14.59s
Total skills used: 31 (2.12/s)
Charged Chop: 17 (1.16/s)

Should make it easier to compare scripts.

Also experimenting with a click limiter, ie, an artificial global gcd to make sure we have a delay between spamming server, at benchmark abowe I used 0.3s and CutCD 0s. Note this is (for now) what FD tries to execute, I'm also looking into matching this to whats actually being executed by catching the COMBATMETER_DAMAGE event.

.frafall

Update:
New run, first number is how many skills FD tries to use, second is how many actually register with a resulting COMBATMETER_DAMAGE, then its the number/second.


Seems we "loose" some open flanks, I've seen this over multiple runs now.

Difference between the two following is 0.4 vs 0s CutCD:

So, I've done a whole lot of tests to figure out whats going on.

Measuring number of CC per second
This test I've been measuring the number of CC we can spam during a period of 10-15s. Initially I saw a large
difference between spamming CC which kept the CC cooldown running all the time and FD which had visually
delays on actionbar button between each CC cooldown. But after doing a totally clean measurement,
i.e. restart client between each test, the delay disappeared.

Quoted

Click Frequenc CutCD FakeGCD Avg Runs

Test1 250ms 100ms 250ms 1.06 1.09 1.03 1.09 1.05 1.05
Test2 250ms 100ms 250ms 1.09 1.10 1.09 1.10 1.10 1.04
Test3 250ms 100ms 250ms 1.03 1.10 0.97 0.98 1.05 1.04
Test4 250ms 100ms 250ms 1.06 1.08 1.04 1.07 1.07 1.05
Test5 250ms 100ms 250ms 1.05 1.06 1.05 1.06 1.08 1.02

1. CC action directly
   
2. A macro with 'UseSkill(3,1)'
   
3. A macro with '/run Direct()', uses FD but calls combat script directly instead of using the /fdiyce slash command
   
4. A macro with '/run ChargedSpam()', a lua function containing 'UseSkill(3,1)
   
5. A macro with '/fdiyce TestWWD'
   

But I made an observation, during one of the FD runs the CC action suddenly went from 'always' in cooldown
to having a visible delay. Running tests after this happened it came out at 0.5-0.6 CC/s instead of ~1/s.
I have not observed this delay starting in middle of any of the other benchmarks,

A new set of tests was run, first running fdiyce until the delays started, then re-running the full benchmark while
occasionally re-running the CC spam to make sure nothing changed for the baseline.

Quoted

Click Frequency CutCD FakeGCD Per Sec

Test1 250ms 100ms 250ms 1.06 1.08 1.04 1.07 1.03 1.09
Test2 250ms 100ms 250ms 1.07 1.06 1.06 1.05 1.14 1.06
Test3 250ms 100ms 250ms 0.86 0.86 0.81 0.87 0.85 0.89
Test4 250ms 100ms 250ms 1.04 1.02 1.04 1.08 1.05 1.03
Test5 250ms 100ms 250ms 0.88 0.88 0.89 0.91 0.92 0.79

Here we can clearly see the >0.1s introduced.
Finally, I restarted client and reran bot CC and FD tests which showed results consisted with the first table again.

CC characteristics
Using a small combat script I noticed that CC does not trigger GCD (as all prolly know) but, I also noticed that
when a GCD skill was executed the CC button got 'greyed' for the duration of the GCD. To me it seems that CC
does not trigger the GCD but it reacts to the GCD from other skills. This can be an explanation for why spamming
CC directly from a macro before FD is effective as its always executed before any GCD skills.
So I made sure no GCD based skill was in front of CC in combat script which seems to deliver better result
but I need to look at this further.

Measuring the time to execute FD
Using a high resolution timer I measured FD real time consumption of a core W/Wd script to be about 0.1-0.5 ms.

.frafall

DIYCE and FuzzyDIYCE users have used macros with '/cast CC; /FD' to maintain the best possible dps instead
of having all skills managed by the scripts.

My working hypothesis is that due to the delay in updates of cooldowns and global cooldowns we have not
been able to cast multiple skills in fast succession.

Also, since CC is not triggering GCD but seems dependent on GCD it needs to trigger before any GCD skill,
i.e. I have it first in skill rotation.

example:

• 0.00 - We cast CC
  
• 0.10 - We click again but since cooldowns is NOT updated we try to cast CC again
  
• 0.20 - And again we try to cast CC
  
• 0.25 - CC cooldown is initiated from server
  
• 0.30 - We click again and cast Slash, next skill in succession, which triggers GCD
  
• ....
  
• 1.30 - We click again, GCD finished so we cast CC again
  
• 1.40 - And again we try to cast CC
  
• 1.50 - And again we try to cast CC
  
• 1.55 - CC cooldown is initiated from server
  
• 1.60 - And we cast another GCD based skill
  

This example leaves us with a skill cycle time of 1.3s which will vary based on update time from servers.
Note btw, ping time is only a fraction of the cooldown update time.

So, how to rectify?

I've experimented with maintaining a cooldown in FD per skill, this is easily done with low overhead, and resulted in:

• 0.00 - We cast CC
  
• 0.10 - We click again, our fake cd inhibits CC so Slash is triggered
  
• 0.20 - We click again, CC/Slash is inhibited, Probing Attack is triggered but fails at server
  
• ....
  
• 1.10 - We click again, GCD finished so we cast CC again
  
• 1.10 - We click again, our fake cd inhibits CC so next GCD based skill is triggered
  

This leaves us with a skill cycle time of 1.1s, compared with previous example this should improve dps with 10-20%.

NOTICE: this effect will influence all skills rotations that depends on buffs as they all take some time to update client!!
I'm not sure how to make a global solution as we would need to keep track of so much information..

So, testing remains, measurements will follow!

.frafall

Ye, first thing that came to mind was to maintain a timestamp in the Skills table. Testing it out now

.frafall

Update:
To check out how cooldowns behave I wrote a script UpdateLatency.lua and spammed it from macro:


This resulted in:

Quoted

Cooldown for skill 'Charged Chop' started, latency 0.3750
Cooldown for skill 'Charged Chop' finished, total 1.3750
Cooldown for skill 'Charged Chop' started, latency 0.3125
Cooldown for skill 'Charged Chop' finished, total 1.3125
Cooldown for skill 'Charged Chop' started, latency 0.4375
Cooldown for skill 'Charged Chop' finished, total 1.3740
Cooldown for skill 'Charged Chop' started, latency 0.3125
Cooldown for skill 'Charged Chop' finished, total 1.3125

So, seems to me the Charged Chop's cooldown, which is specified to 1s, in perceived as >1.3s (For me with my latency)

Next question is how the server accepts new CC's? 1s after previous or 1.3s? I guess 1s after previous as we can spam
CC faster manually.

P.S scripts i use here is based on BETA code, available at 'svn+ssh://svn@svn.curseforge.net/rom/fdiyce/mainline/branches/v0.52'