That's your problem. Do it the way Skudo did it.
Skudo's way gives +/-1 second duration, in my experience.
The Last Dance II: The Show Must Go On
The Last Dance II: The Show Must Go On
I'll perform the test again later and doublecheck with timestamps then.
Chocobo Jig, Maxixi Toeshoes +1 only.
1) xx:53:54 - xx:56:37 => 2'43" => ~43" bonus
2) xx:58:45 - xx:01:28 => 2'43" => ~43" bonus
3) xx:02:17 - xx:05:00 => 2'43" => ~43" bonus
Looks pretty solid. It's not the expected 48 value that we're supposed to be getting from a 40% duration bonus tho.
Edit:
Repeated the test with Spectral Jig (base duration of 180 seconds).
Got a bonus of 68 seconds instead of the expected 72 (40% of 180 is 72).
Not 40% but not a static increase either.
Maybe it's because it's xxx/1024 instead of 40/100?
Me and math are not good friends. What does everybody else get from this?
Repeated test with Horos Tights +1 only as well.
Spectral Jig Expected => 81 seconds. Instead I got 77 seconds.
Chocobo Jig Expected => 54 seconds. Instead I get 49-50 seconds.
You guys sure the chatlog timestamp method is really reliable to measure these?
1) xx:53:54 - xx:56:37 => 2'43" => ~43" bonus
2) xx:58:45 - xx:01:28 => 2'43" => ~43" bonus
3) xx:02:17 - xx:05:00 => 2'43" => ~43" bonus
Looks pretty solid. It's not the expected 48 value that we're supposed to be getting from a 40% duration bonus tho.
Edit:
Repeated the test with Spectral Jig (base duration of 180 seconds).
Got a bonus of 68 seconds instead of the expected 72 (40% of 180 is 72).
Not 40% but not a static increase either.
Maybe it's because it's xxx/1024 instead of 40/100?
Me and math are not good friends. What does everybody else get from this?
Repeated test with Horos Tights +1 only as well.
Spectral Jig Expected => 81 seconds. Instead I got 77 seconds.
Chocobo Jig Expected => 54 seconds. Instead I get 49-50 seconds.
You guys sure the chatlog timestamp method is really reliable to measure these?
Horos Tights +1, 10/10 Jigs CP, Chocobo Jig II. Expected: 130 seconds * 1.45 = 188 seconds.
Matches perfectly.
Maxixi Toe Shoes +1, 10/10 Jigs CP, Chocobo Jig II, expected: 130 seconds * 1.40 = 182 seconds.
Matches perfectly.
Conclusion: ***works as displayed for 10/10 Jigs CP. I don't know about under 10/10 and I can't test that, for obvious reasons.
Matches perfectly.
Maxixi Toe Shoes +1, 10/10 Jigs CP, Chocobo Jig II, expected: 130 seconds * 1.40 = 182 seconds.
Matches perfectly.
Conclusion: ***works as displayed for 10/10 Jigs CP. I don't know about under 10/10 and I can't test that, for obvious reasons.
I can't explain the difference in results then, but I used timestamp last time and did at least 3 readings for each test.
What is the source of discrepancy with these results?
And I could add Cambion's results as well, he too used timestamps.
What is the source of discrepancy with these results?
And I could add Cambion's results as well, he too used timestamps.
Looking at his screenshots, the discrepancy is Battlemod.
Re-did my tests with Battlemod on, and got the exact same results expected from Byrths equation: (Base+JP)*Bonus
Etoile Legs+2 & Maxixi Toe Shoes
Chocobo: (120+6)1.5= 189 (3:09)
Spectral: (180+6)1.5= 279 (4:39)
Re-tested with Etoile Legs +2 only:
Chocobo: (120+6)1.35= 170.1 (2:50)
All 3 lined up exactly.
Re-did my tests with Battlemod on, and got the exact same results expected from Byrths equation: (Base+JP)*Bonus
Etoile Legs+2 & Maxixi Toe Shoes
Chocobo: (120+6)1.5= 189 (3:09)
Spectral: (180+6)1.5= 279 (4:39)
Re-tested with Etoile Legs +2 only:
Chocobo: (120+6)1.35= 170.1 (2:50)
All 3 lined up exactly.
Oh yeah, I didn't have Battlemod loaded up either.
Is the method battlemod uses to create timestamps more "precise" than the timestamp addon?
Is the method battlemod uses to create timestamps more "precise" than the timestamp addon?
It doesn't produce timestamps, it just forces the chatlog to update quicker. So you see 'gains the effect of X" immediately when the buff is active, rather than after the entire animation is done, like default.
Yeah, Battlemod near-instantly displays the message associated with any given action packet, while the game waits until the end of the animation to display it.
[+]
This one is for Byrth again, i guess...
I have always been using cancel addon in order to automatically cancel saber dance when i need to cast emergencial cures, but it seems it stoped working out of the blue. Would you mind checking? I even took a look at the buffs list and saber dance remains the same:
if spell.type == 'Waltz' then
if buffactive['saber dance'] then
cast_delay(0.3)
windower.ffxi.cancel_buff(410)
end
I have always been using cancel addon in order to automatically cancel saber dance when i need to cast emergencial cures, but it seems it stoped working out of the blue. Would you mind checking? I even took a look at the buffs list and saber dance remains the same:
if spell.type == 'Waltz' then
if buffactive['saber dance'] then
cast_delay(0.3)
windower.ffxi.cancel_buff(410)
end
Code
function _h.cancelBuffs(spell)
if spell.type == 'Samba' and buffactive['Fan Dance'] then
windower.ffxi.cancel_buff(411)
elseif spell.name == 'Spectral Jig' and buffactive['Sneak'] then
windower.ffxi.cancel_buff(71)
elseif spell.type == 'Waltz' and buffactive['Saber Dance'] then
windower.ffxi.cancel_buff(410)
end
endWorks for me.
This is the default in Mote.Utility which still works for me:
Code
function cancel_conflicting_buffs(spell, action, spellMap, eventArgs)
if cancel_spells_to_check:contains(spell.english) or cancel_types_to_check:contains(spell.type) then
if spell.action_type == 'Ability' then
local abil_recasts = windower.ffxi.get_ability_recasts()
if abil_recasts[spell.recast_id] > 0 then
add_to_chat(123,'Abort: Ability waiting on recast.')
eventArgs.cancel = true
return
end
elseif spell.action_type == 'Magic' then
local spell_recasts = windower.ffxi.get_spell_recasts()
if spell_recasts[spell.recast_id] > 0 then
add_to_chat(123,'Abort: Spell waiting on recast.')
eventArgs.cancel = true
return
end
end
if spell.english == 'Spectral Jig' and buffactive.sneak then
cast_delay(0.2)
send_command('cancel sneak')
elseif spell.english == 'Sneak' and spell.target.type == 'SELF' and buffactive.sneak then
send_command('cancel sneak')
elseif spell.english == ('Stoneskin') then
send_command('@wait 1.0;cancel stoneskin')
elseif spell.english:startswith('Monomi') then
send_command('@wait 1.7;cancel sneak')
elseif spell.english == 'Utsusemi: Ichi' then
send_command('@wait 1.7;cancel copy image,copy image (2)')
elseif (spell.english == 'Trance' or spell.type=='Waltz') and buffactive['saber dance'] then
cast_delay(0.2)
send_command('cancel saber dance')
elseif spell.type=='Samba' and buffactive['fan dance'] then
cast_delay(0.2)
send_command('cancel fan dance')
end
end
endThing is... mine was working until yesterday.
It doesn't cancel at all? Or is it more like it cancels, but it does so "too late"?
Did you accidentally unload cancel, or have it crash?
Try unloading and reloading cancel plugin.
Try unloading and reloading cancel plugin.
Bahamut.Flareon said: »
if spell.type == 'Waltz' then
if buffactive['saber dance'] then
cast_delay(0.3)
windower.ffxi.cancel_buff(410)
end
if buffactive['saber dance'] then
cast_delay(0.3)
windower.ffxi.cancel_buff(410)
end
i see... well... even if that's the case, it changed overnight...
I have also had it suddenly stop working in the past, and I think it was zone dependent to some degree.
I suspect it has something to do with the priority that SE gives buff canceling packets compared to action packets. If they were equal priority and processed sequentially, there would be no need for a delay statement at all. If the cancel command priority is below the action command priority, you would expect the cancel command would have to arrive in the previous UDP packet to be effective (aka a 0.4~0.5 second delay).
As it is, I'm not entirely sure why it works sometimes and not others, but I'm fairly sure it's server-side and it may have something to do with when the server updates your buff list relative to processing the incoming packet. Depending how they code it, it could be sensitive to the server-up time.
I suspect it has something to do with the priority that SE gives buff canceling packets compared to action packets. If they were equal priority and processed sequentially, there would be no need for a delay statement at all. If the cancel command priority is below the action command priority, you would expect the cancel command would have to arrive in the previous UDP packet to be effective (aka a 0.4~0.5 second delay).
As it is, I'm not entirely sure why it works sometimes and not others, but I'm fairly sure it's server-side and it may have something to do with when the server updates your buff list relative to processing the incoming packet. Depending how they code it, it could be sensitive to the server-up time.
[+]
Meaning that maybe it's better changing my code to mote's or skudo's or it doesn't matter?
To be fair, this happened inside Arrapago Renmants II, which may be laggy or idk... i'll test in other areas when i log.
To be fair, this happened inside Arrapago Renmants II, which may be laggy or idk... i'll test in other areas when i log.
Shouldn't matter, as far as I can tell.
Testing done... works outside salvage
Recently my gearswap stopped working for UL spells on BLU while inside Salvage, so it's more than likely a related issue.
Yeah, could be the same issue.
It seems very unlikely that SE is dropping decrypted chunks from a UDP packet, so they must have just changed the way that your buffs are updated in instanced zones server-side.
It seems very unlikely that SE is dropping decrypted chunks from a UDP packet, so they must have just changed the way that your buffs are updated in instanced zones server-side.
Hurray, new version of the DNC spreadsheet! https://goo.gl/tk10gx
(This link will always point to the most recent version, as long as the Google URI shortener and Amazon S3 are alive.)
Changes:
* Updated the formula for TP Gain.
* Changed the spreadsheet to 0-3000 TP. I _think_ I updated all occurrences, but if you run into something awkward, please let me know and I'll try to fix it.
* Added random gear. I can't even remember what I've added, except for Foppish Tunica (+1).
Due to the changes in the TP system and base TP per hit, side-by-side comparisons will not necessarily yield the same results. The current spreadsheet should be closer to "real-life numbers" now.
(This link will always point to the most recent version, as long as the Google URI shortener and Amazon S3 are alive.)
Changes:
* Updated the formula for TP Gain.
* Changed the spreadsheet to 0-3000 TP. I _think_ I updated all occurrences, but if you run into something awkward, please let me know and I'll try to fix it.
* Added random gear. I can't even remember what I've added, except for Foppish Tunica (+1).
Due to the changes in the TP system and base TP per hit, side-by-side comparisons will not necessarily yield the same results. The current spreadsheet should be closer to "real-life numbers" now.
It doesnt work properly, right off the bat switching from kleos to rudra gave me 17k ws which is what i get with SA on thf, setup both sets the same first give me 901dps and second 3335dps.
Fixed in the (just now) updated version. fTP wasn't calculated correctly for the 2nd WS, if fTP scaled with TP.
There is a DNC bug right now that's so good I'm afraid to mention it on a public forum. :(
How do you know it's a bug? Could just be working as intended.
If we are talking about the same thing there is no way you could possibly think this is working as intended.
All FFXI content and images © 2002-2024 SQUARE ENIX CO., LTD. FINAL
FANTASY is a registered trademark of Square Enix Co., Ltd.