Round counter trick macro?

A buddy of mine showed me a great trick to create a round clock in your turn order panel, by assigning a NPC token with an initiative of +0.1 each round. So now that I've started to experiment with macro creation, I wonder if there is a way to create a macro to do this. All it would do is take a to men's current initiative in the turn order, add 0.1 and update the turn order. Is that possible? Tom

API script could do it but not a macro.

That might just work. I'll have to give it a shot. Something like /roll .01 &{tracker:+}, wouldn't you think?

Working here too, though it works better if I use the "/roll 0.01 &{tracker:+}" action. Otherwise, I sometimes get some really weird fractions. Now the only one thing keeps this from being perfect. Is there a command that will "auto select" a particular token? For instance, lets say I assign a token on the screen with the name "Round Clock." Is there a command I can add to this macro that, when I execute it, it will immediate select "Round Clock" and perform the action for it? There is a lot of stuff about select-ed tokens in the wiki, but most of it looks as though I have to have manually selected the token before executing the macro.

Ok, testing this a bit more. Seems the weird fractions come up pretty consistently actually. Enough so one of the devs should check this out. Everything works fine on 0.01-0.05. On 0.06, I get "0.060000000000000005" Then 0.07-0.09, everything works fine again. Then, on 0.10, I get "0.09999999999999999", followed by "0.10999999999999999", "0.11999999999999998", "0.12999999999999998", etc. On 0.15, it works fine again, then loopy again from that point on. Pretty sure this is a bug. Not one that would affect anyone who isn't using decimals, though. Can anyone confirm this? I'm using Safari as my browser.

Tom said: Ok, testing this a bit more. Seems the weird fractions come up pretty consistently actually. Enough so one of the devs should check this out. Everything works fine on 0.01-0.05. On 0.06, I get "0.060000000000000005" Then 0.07-0.09, everything works fine again. Then, on 0.10, I get "0.09999999999999999", followed by "0.10999999999999999", "0.11999999999999998", "0.12999999999999998", etc. On 0.15, it works fine again, then loopy again from that point on. Pretty sure this is a bug. Not one that would affect anyone who isn't using decimals, though. Can anyone confirm this? I'm using Safari as my browser. That's floating-point rounding errors. 0.01 cannot be accurately represented with binary floating-point numbers (nor can 0.1), and computers are always working with binary numbers, no matter what you try to tell them to do. The closest floating-point binary number to 0.01 translates to the decimal number 0.009999999776482582092285156250. Is there any particular reason why you're trying to represent a turn counter with fractions rather than counting numbers (1, 2, 3, etc.)?

Yes, Kristin is exactly right. The round counter is meant to always be at the end of the turn order. Its not a perfect solution, but it'll work in a pinch until a real option becomes available. That the problem lies in the underlying script doesn't surprise me. Now using negative numbers as a work around. THAT is an interesting solution. Does it work?

Tried it and it works like a charm! Thanks Kristin!

I would just like to say +1 (or -1 as the case seems to be?) on this thread. Very useful trick.