unikronsoftware, I'd strongly second the need for a currentFrame property in order for the toolset to be as flexible as possible. I'm making a game where a central timer is updating the animations for each AI via spaced-out "ticks", and I want to drive the animations that way. I currently have them paused and am setting the frames directly, so the above timer-derived solution does not seem to work, and I don't want to hardcode the frame names.
In this type of situation, it'd be super helpful and very direct to have a property that we could access to tell us the current frame for the current clip.
Your desire to funnel users into using time is understandable, but it may just be a simpler and more user-friendly solution to provide the flexibility of having the property accessor, while at the same time advising users in the docs on how they'd typically get the best results (via a timer).
Thanks so much for your hard work... overall super happy with 2D Toolkit!