You are not logged in.

Applications: [GameMaster: OPEN] | [Volunteer Testers: OPEN]


This forum will be permanently shut down on Friday 13.07.2018
Please copy or save all important information from old forum before they will be deactivated
We have moved to new board. https://forum.runesofmagic.gameforge.com/Come join us.

121

Tuesday, June 3rd 2014, 6:58pm

Again throwing out some numbers, all measured for my latency, pc and speed fingers:
  1. The time from a CC is casted until cooldown timer starts in client ~0.25s
  2. The cooldown time for CC is therefore 1.25s which FD obeys, ie loosing quite some dps
  3. The least amount of time between CC and next attack like Slash/Tactical is 0.15s
  4. Cutting the CC cooldown short to 1s client time, ie from we press CC button until next, works,
    ie there is NO reason why FD should wait until the GetSkillCooldown returns 0


So, for me it seems I can spam CC + other skill each 1.15s, this gives aprox 1.7 skills/s max speed. Experimenting
with different cooldown models for FD I can reach this, I just havent found an elegang way of implementing yet.

Basically we need to track cooldowns per skill, I've added this to the skills table.
But, I would like to have a dynamic latency thing going to measure the cooldown update delay, ie from skill
is triggered until colldown starts on client, this is the amount of time we should subtract from cooldown counter.

.frafall

Peryl

Intermediate

  • "Peryl" started this thread

Posts: 313

Location: Elsewhere

  • Send private message

122

Wednesday, June 4th 2014, 1:01am

Before delving into the automatic latentcy detection, lets review what we know about the order the game takes for using a skill.

The order appears to be

Source code

1
2
3
4
5
6
Time 0           Client clicks CC skilll, client sends fact to server
Time + 0.125     Server receives client's request to use skill, server agrress and sends back answer to client
Time + 0.25      Client receives answer from server, starts internal cooldown timer.
Time + 1.0       [**]  Time cooldown expected to end from time of skill use. Server appears to accept if skill used at this time
Time + 1.125     [**]  Time cooldown could be exected to finish on the server and allow another skill
Time + 1.25      Cooldown complete on client side


If the above is in fact correct (would need to perform tests to see exactly when the earliest re-cast of skill can happen keeping track of timestamps) then it should be possible to do this in a fairly straightforward way (well OK, there is some jiggering around that needs to be done but...)

First, have an table that, when a skill is actually used, you add the skill to this table and a timestamp. Use the skill's name as the table entry index for easy lookup later.
Something like this:

Source code

1
skilltrackingtable[ skillname ] = { timestamp = GetTime(), delay = nil }


The next time that skill is to be used, well it is easier to explain in pseudocode

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
if GetSkillCooldown is 0 then
  if skill in tracking table but time delay not deternmined then
    /* we can only get to this point if the skill was triggered, but GSC hasn't started so we are still in the Time 0 to Time + 0.25 */
    return skill is on cooldown
  endif
  /* skill isn't on cooldown, so ensure it isn't in the tracking table either */
  skilltrackingtable[ skillname ] = nil
  return skill not on cooldown
else
  if skill in tracking table but time delay not determined then
    /* we need to determine the time delay at this point */
    /* the following might be somewhat incorrect if GSC is not at the full amount. */
    /* It may be better to have a seperate frame that just goes through the table and computes the delays */
    skilltrackingtable[ skillname ].delay = GetTime() - skilltrackingtable[ skillname ].timestamp
    return skill is on cooldown
  elseif skill in tracking table and delay determined then
    if GetSkillCooldown() - skilltrackingtable[ skillname ].delay <= 0 then
     /* skill is not on cooldown, so remove it from tracking table */
     skilltrackingtable[ skillname ] = nil
     return skill not on cooldown
   else
     /* gettting to here means the skill isn't in the tracking table but GSC */
     /* returned a non-zero value so it must be on cooldown */
     return skill is on cooldown
  endif
endif


The only thing that the above might have trouble with is instant cast skills as they don't have a cooldown to begin with. These may need to be check for and not bother adding them to the tracking table.


Hope this is clearer than mud.... :)
2013... The year from hell....

123

Friday, June 6th 2014, 7:03pm

Well best way to cope with presented issue would be to add timer on skill tigger of 0.5s? this way FD would not try to spam CC, while it's on CD and get response from server before timer is finished.

Still don't get it why my FD with outside CC clicking is preforming any batter, as I still have CC in my FD combo. Shouldn't FD still try to use CC while it's on CD? And as I have written before I have managed to use 240skills/120s on my Wd/S, so mathematical maximum.

124

Saturday, June 7th 2014, 8:27am

Hmm I agree, our reasoning so far still can't explain your case Pietro, I need to try to replicate it to verify.
Doing that test, do you use any kind of pots/buffs?

My current test environment is two lvl50 toons, one s/r and one w/wd, both have a nice cape with loads of
def/sta to survive anything the other can throw at them and I'm using as low lvl weapons as possible.
The s/r ensures enough rage to avoid rage issues. I don't use any buffs or pots.

I have never been close to two skills per second, is there a difference in Wd/S skill rotation wrt W/Wd?
My current thought is that a skill rotation of <CC> + <GCD based skill> every N seconds represents the optimum
rotation, where N should be as low as client permits. My best test case is down to 1.71 skill/sec, ie N=1.16.


Nice analysis Peryl, what I have been testing so far is setting the delay manually (fake cooldown - fcd)
but as far as I've been able to determine this isn't enough as the delay will vary significantly and as I
either set it to high to never miss a skill or it's to low and we drop a skill as it isn't really ready, dps suffers.

There is one additional parameter, there is a small delay after using a skill in which we can't do ANY other
skills (fake global cooldown fgcd), so far for me it seems to be around 0.15s (therefore the N=0.16 above I think).

But, as were down to timing single skills while the server performs far from consistently, a dynamic approach
is probably necessary.

.frafall

My current algorithm is as below, working through your analysis I see I mixed up a little, I assumed my fgcd
covered the cooldown update delay which ofc it doesnt, also I missed a state where user might have done
a skill manually, this explains my issues with my last benchmark :)

This post has been edited 14 times, last edit by "frafall" (Jun 7th 2014, 11:09am)


125

Sunday, June 8th 2014, 3:05am

Well I haven't been using any pots, cuz I am only testing using stopper and scrut, so I would simply have lost GCD (in my measurements), besides generally potions slows down whole script (as any action bar activity - at least for me). As for using Wd/S - simply in long testing there is no way, to maintain rage and Wd/S have scout shot every 1-2s, so I have "rotation skill" all the time. Also not sure, but some in-game skills have animation that can not be stopped and sometimes they do last longer than 1 sec (ex. Double Chop), maybe that's the case here - but haven't observed anything like that on W/Wd myself (well probably wouldn't notice 1,1 sec animation anyway and it will do huge difference).

As for FGCD this is why I've started using DIYCE on WD in the first place, as it seems to help a lot.
Generally when I was manually playing on Wd/S, I always have problem with using anything right after CC. DIYCE have simply eliminate the problem slowing down whole skill sequence (but without mistakes of not clicking skill second time, as after 1-st usage there was FGCD - in short my DPS improved by 30%).
After a while I have tried outside DIYCE CC clicker and it have improved my DPS by about 16% (as far as I remember), moreover denying CC form DIYCE combo was still better than plain DIYCE, but worse than both CC inside and outside of script.
Plain FD is where my DIYCE+outside CC was (something like 95-105 CC/120 sec - so about yours preformence), with outside CC it's another 15-20% better (rest stays same).

The only possible way to achieve my values, if everything said before is right, would be simply quicker server response, but than againg FD alone would do the thing.
The other explanation would be, that CC is not affected by GCD, yet it is seen as both on action bar and by FD, but from my experience CC is really GCD dependent skill, besides than - why putting CC in FD script would have any affect on DPS.

DK is this possible, that simply FD can not click action just after usage and skips CC, but client puts CD information just a while after that. In other words it's on "action CD" for let's say 0,01s FD can not use any skill, but prohibition tiggers only for CC, as it's first skill in script, next skill can be used and moment later client process GCD information denying usage of any skill (FGCD)?


Plain DIYCE was working fine for me untill I have seen YT video with Wd/W doing 2 skills/sec and than I have started testing. First there was outside clicker, than I was intended to write own macro, as simple as possible, but FD was faster and had done job for me.

126

Monday, June 9th 2014, 6:29pm

Something related to order in which skills are processed.

Skills get used before their costs are deducted. In otherwords, let's say you are a warrior. And you have 25 rage. You are spamming fdiyce macro. the following happens (which I observer when watching videos in slow motion with fdiyce hud on).

You use probing attack. Enemy receives Vulnerable debuff. You STILL HAVE 25 rage. Fdiyce tries to cast brash ferocity strike. You pay 20 rage for previous probing attack. Fdiyce tries to use a different skill.

Not sure if this fact will make a difference in coding of things like this auto-detect delay thing you're working on, but thought I'd throw it out there regardless.

127

Wednesday, June 11th 2014, 12:12pm

Ye, I've noticed the same - its the cooldown delay all over again.

It takes about (for me) 0.2s for any update to make it back from server, this includes cooldowns, hits and buff updates.

So, ANY decisions FD makes is based on out-of-date information :mad:

This results is FD is trying skills which fails and lowers overall dps.

We basically can have two approaches, the traditional approach inherited from DIYCE which is spam until it works,
this looses approx 10-20% dps (I guess) wrt manual (good) playing.

The other approach, which we have started for cooldowns, is to compensate for the delays.
Question is, how far is it reasonable to go to compensate?

.frafall

P.S Finally my test environment is available again, I'm currently testing Peryl's algorithm for cooldowns which
looks promising. There are a few minor snags, like cleaning out cooldown table when mob dies and it doesn't
take into account the minimum time allowed between two skills (approx 0.15-0.20s). I'm trying to figure out
if the minimum time actually is the update time, ie that we can't start new skill until we have respons on
previous but haven't found anything conclusive yet.

Seems Peryl's algorithm doesn't handle GCD, ie. if I do a slash then until the cooldowns are updated for the slash
the Tactical Attack is open to be used, ie seems the buffs is updated before the cooldowns. So I have a sequence
like:

Quoted

100.19 - Try Charged Chop
100.31 - Hit Charged Chop
100.36 - HP, Rage, Mana, bleed: 8948, 98, 2571, false
100.36 - Try Slash
100.50 - Hit Slash
100.53 - HP, Rage, Mana, bleed: 8945, 100, 2554, true
100.53 - Set delay=0.25 on 'Charged Chop', in-cooldown=true
100.53 - Try Tactical Attack <= FAILS as GCD is coming but not updated for Slash yet
100.74 - Set delay=0.24 on 'Slash', in-cooldown=true

In this test I actually hold any skills from execution until I received the COMBATMETER_DAMAGE event on previous.

p.p.s Damn I keep going in Lua trap of "not not" to convert to boolean, ever tried to do a
"print(not not 0)" or "print(not not 1)"? Check web for explanation :)

This post has been edited 9 times, last edit by "frafall" (Jun 11th 2014, 9:21pm)


128

Friday, June 13th 2014, 6:41pm

Just a quick update, I'm currently exploring a simple cooldown algorithm which totally ignores the client cooldowns.
I implemented Peryl's algorithm, it worked nicely but after realizing I needed to expand it with global cooldown and
state update from COMBATMETER_DAMAGE event I got stuck in the complexity.

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
-- Current global cooldown constant, modify if changed in-game
local c_GlobalCooldown = 1.0

-- Keep track of GCD 
local GlobalCooldown = 0

function api.GetSkillCooldown(skill)
	local now = fdvars.Now
	
	-- Check for GCD, assuming ALL skills have GCD (might be wrong)
	if now - GlobalCooldown < c_GlobalCooldown + config.AdjustCooldown then
		return true
	end
	GlobalCooldown = 0
	
	-- Check skill cooldown
	if now - skill.timestamp < skill.cooldown + config.AdjustCooldown then
		return true
	end

	-- Check for previous unfinished skill with timeout of .5s
	-- Assuming skill usage is synchronous with server
	-- Might easily be wrong, I've seen up to 4 outstanding skill
	-- inbetween, might explain bursts we see in beginning of fights. 
	if WaitForResponse and now - WaitForResponse.timestamp < 0.5 then
		return true
	end
	WaitForResponse = nil
	
	--
	-- This is tricky, we can be at end of cooldown (FD cuts it short)
	-- or in middle (if some1 did something manually)
	-- For now, ignore it
	--
	
	-- No cooldown
	skill.timestamp = 0
	return false
end

I've run this a number of times, a typical run is shown below. It does a GCD based skill after the CC within 0.2-0.3s
and a new CC after 1.05-1.07s. To be able to handle GCD correctly I added a field in the trySkill called nogcd, ie
it becomes the script writers responsibility to tag skills with no gcd.

Currently there are some snags in this, I typically play with FD doing the DPS while I'm doing event/tactic skills
manually - any manual handling currently screws up the gcd/cooldown handling in FD so I need some way of syncing it.

If any1 care to test this code its available in repository in my v0.52 developement branch revision 88.

.frafall

Source code

1
2
3
4
5
6
7
8
9
function TestCC()
	local BleedTimer = api.CreateFDTimer("Bleed")

	trySkill("Charged Chop",        PlayerMana >= 260, nil, nil, true)	-- NoGCD=true
	trySkill("Slash",               PlayerRage >= 25, BleedTimer(7.5))
	trySkill("Tactical Attack", 	TargetHasBuff(bleeds) and PlayerRage >= 15)
	trySkill("Open Flank",          TargetHasBuff("Vulnerable") and PlayerRage >= 10)
	trySkill("Probing Attack",      TargetHasBuff(bleeds) and PlayerRage >= 20 and not TargetHasBuff("Vulnerable"))
end


Quoted

1377.34 - Charged Chop
1377.51 - Damage: Fairthe, 23, Sneirfoi, Charged Chop, NORMAL

1377.69 - Open Flank, 0.35s
1377.69 - Damage: Fairthe, 8, Sneirfoi, Open Flank, NORMAL
1378.02 - Damage: Fairthe, 10, Sneirfoi, Bleed, NORMAL
1378.53 - Damage: Fairthe, 15, Sneirfoi, ATTACK, NORMAL

1378.70 - Charged Chop, 1.01s
1378.70 - Damage: Fairthe, 23, Sneirfoi, Charged Chop, NORMAL

1378.88 - Tactical Attack,, 0.18s
1378.88 - Damage: Fairthe, 5, Sneirfoi, Tactical Attack, NORMAL

1379.91 - Charged Chop, 1.03s
1379.91 - Damage: Fairthe, 23, Sneirfoi, Charged Chop, NORMAL

1380.09 - Slash, 0.18s
1380.09 - Damage: Fairthe, 10, Sneirfoi, Bleed, NORMAL

1381.10 - Charged Chop, (FAILED), 1.01s, Lost event or 'real' fail?

1381.62 - Probing Attack, 0.52s (RECOVERY)
1381.62 - Damage: Fairthe, 6, Sneirfoi, Probing Attack, NORMAL
1381.96 - Damage: Fairthe, 10, Sneirfoi, Bleed, NORMAL
1382.14 - Damage: Fairthe, 15, Sneirfoi, ATTACK, NORMAL

1382.67 - Charged Chop, 1.05s
1382.67 - Damage: Fairthe, 23, Sneirfoi, Charged Chop, NORMAL

1382.84 - Open Flank, 0.17s
1382.84 - Damage: Fairthe, 8, Sneirfoi, Open Flank, NORMAL

1383.85 - Charged Chop, 1.01s
1383.85 - Damage: Fairthe, 10, Sneirfoi, Bleed, NORMAL

1384.02 - Tactical Attack, 0.17s
1384.02 - Damage: Fairthe, 5, Sneirfoi, Tactical Attack, NORMAL

1385.06 - Charged Chop, 1.04s
1385.23 - Damage: Fairthe, 15, Sneirfoi, ATTACK, NORMAL


ps. Ye the damage is sick.....lvl 50 toons w. lvl 1 weps and skills

This post has been edited 1 times, last edit by "frafall" (Jun 13th 2014, 9:28pm)


129

Saturday, June 14th 2014, 7:18am

I gladly will test it, but not know how to download

130

Saturday, June 14th 2014, 10:53am

Attached is a link to release 88

.frafall

131

Saturday, June 21st 2014, 2:43pm

FuzzyDIYCE v0.52

I tagged v0.52 today, full announcement is available here

.frafall

132

Tuesday, June 24th 2014, 3:28pm

Wd/S

I've started testing on a newly built Wd/S, started out to check skills when I found something:

When using Shot skill which is an instant skill with 1s cooldown according to description I get the following
from tracking its cooldown:

Quoted

1.5375 0
1.5375 0
1.5375 2
1.5375 1.89
1.5375 1.80
...

I.E. The client description claims a cooldown of 1s, the GetSkillCooldown claims a cooldowns of 1.5375s and
the cooldown actually starts at 2s...talking about inconsistency.

Can any1 help me out with which is correct?

.frafall

133

Friday, June 27th 2014, 12:40am

Well shot is weapon speed based skill. I have always thought that it's CD is always rounded up or down so 1,49 would be 1 and 1,5 would be 2. From your testing it is simply not... They had to change it back in CHIII (or even II), when you could get to less than 0,5 weapon speed and spam shot X times/s (where X is probably as many as M/Wd flame). Or as always some "ninja change" in near past (and there is no scout left to notice it). As for action bar time, it's simply same as with 2mins CD when there is 90sec left (always rounded up, so if real CD would be 1.00000001s, the AB CD would start from 2 - if of course your eye could catch this).

Generally for your purpose it would be good to find fastest bow possible always use crystal for speed buff and probably another one from Wd/M. Fastest non-quest bow is 2.0 (quest 1.8), with that you can get to 2.0*0,615*0,95*0,92=1,075, as it is alt (I suppose) you can add 2% from pet if you don't have one (or 5% if you have some gold to throw away), so 1,0925*,98=1,0535 (and that would be fastest passive speed I can think of - of course on top of that there is Wl/M, Strong Stimulant, Siege titles, lute...).

134

Saturday, June 28th 2014, 10:11am

So, if I understand you correctly:
  • The 1.53s CD that GetSkillCooldown returns is based on weapon and is rounded up to 2s (which GSC also reports correctly)
  • Nomatter what I do I can't go below the 1s cooldown which skill Shot has in description


Hmm, it kinda makes sense after you described it, thx :)

Question is then how to get it to work in FD, I currently use the cooldown from GSC (which is 1.53s) but it actually
has a 2s cooldown. So, for Shot, I need to do the rounding.

But, its also affected by the current speed settings, ie my reading the skill cooldown at class swap/login time
isn't correct.

.frafall