Hey - just found a very obscure bug while trying to sync two STMs.

Try creating a STM with a read delay of 0.1 and with the following text:

This is a <w>test

I'm getting a totalReadTime of 1.4 for this line. (The specific number might vary based on auto-delays).

Now try again with this:

This is a <w>test</w>

I'm getting a totalReadTime of 1.5 for this one, even though the rendered text hasn't changed.

Huh, I think this has to be due to an old workaround I did where STM inserts a zero-width space at the end of closing tags to make sure event tags at the end of strings get called... In *that* instance, the extra read time I *think* makes sense since the event is called at the start of that "invisible" character... but maybe I should remove it since the event could be counted as being called at the end of the string, anyway...?

So... not sure if I should leave this, or make it so the self-inserted zero-width spaces don't count as totalReadTime... I *think* in the situation of events at the end of a string, the latter may cause events to be ignored when restoring a string?

Hmm, interesting. I can see why you might want to count the event as a character, since it's technically something else that has to execute after the string is completed. The </w> itself probably shouldn't count as a character, but as you said, it was a workaround anyway.

Actually, another workaround would probably be to just omit the </w>, because it's unnecessary if the string is ending there anyway. I'll do that manually on my end (this situation only occurs once); not sure if this would be doable within STM itself. But yeah, event execution can be finnicky, and that does sound like it would be a hard change to make without testing some things first.