After looking at $pic().delay a bit more this evening, I found some issues.

I used https://imagy.app/animated-image-analyzer/ to analyse my gif, you can try with my gif here https://www.dropbox.com/scl/fi/i1th...rlkey=e240bdtipajt34r7y1w41u62o&dl=0

This code use $pic(file,N).delay with N index being 0-based ($calc(%a -1)), more about that later. In the debug, I'll include the value from the website
//var -s %g C:\Users\Ouims\Downloads\gm1.gif,%a 1,%b $pic(%g).frames | while (%a <= %b) { echo -sg frame %a delay : $pic(%g,$calc(%a -1)).delay | inc %a }

Quote
* Set %g to C:\Users\Ouims\Downloads\gm1.gif
-
* Set %a to 1
-
* Set %b to 149
frame 1 delay : 0 vs 100
frame 2 delay : 0 vs 100
frame 3 delay : 400 vs 400
frame 4 delay : 0 vs 100
frame 5 delay : 400 vs 400
frame 6 delay : 0 vs 100
frame 7 delay : 400 vs 400
frame 8 delay : 0 vs 100
frame 9 delay : 400 vs 400
frame 10 delay : 0 vs 100
frame 11 delay : 400 vs 400
frame 12 delay : 0 vs 100
frame 13 delay : 400 vs 100
...
frame 22 delay : 320 vs 320
frame 23 delay : 0 vs 100
frame 24 delay : 450 vs 450
...
frame 149 delay : 10 vs 10

1) Using N as a 0 based index is the only way to align my result with the website, if I make it 1 based, there's an off by one shift. I'm not sure if this is a bug or if it's intended because you didn't correct me when I stated otherwise, and it's against the fact that identifiers' N value are normally all 1-based index.

2)Whenever the value should be 100, mIRC reports 0, but for any other value tested in this gif, mIRC is correct... EVEN for the last frame 149 with the delay of 10ms instead of 100ms, which mIRC gets correctly.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel