This one is pretty specific, and the only character I have found that it applies to is the standard exclamation point. The autodelay will not be applied, given the code below. If I set the period with the same code, it will work. If I change the ruleset to  STMAutoDelayData.Ruleset.FollowedByDifferentCharacter, it will work.

The code below will yield the bug:

'''

var autoDelay = ScriptableObject.CreateInstance<STMAutoDelayData>();
autoDelay.character = '!';
autoDelay.ruleset = STMAutoDelayData.Ruleset.FollowedBySpace;
autoDelay.count = 5;
dialogText.data.autoDelays[autoDelay.character.ToString()] = autoDelay;

'''

I'm still experimenting with what works best with my system and writing style, so it's not a huge problem or anything, but I thought it would make sense to just toss a bug report up for it.

EDIT: I am actively debugging this, will post results shortly.

This string will cause the bug to appear:

"This is a test EN! This is a testEN. This is a testEN? This is a testEN, This is a test; This is a testJP！ This is a testJP。 This is a testJP？This is a testJP、 blah"

I did this testing with the default autoDelay settings left in place, and tested with Japanese punctuation marks as well as English ones. I am wondering whether there is something that is interpreting/consuming the exclamation mark in SuperTextMesh logic before a given character can be assigned the auto-delay in the preprocessing step.

And again, this only appears when the ruleset it set to STMAutoDelayData.Ruleset.FollowedBySpace.

The thread kinda split, so replying here!

Oh wow I somehow never caught that, but yeah that makes a lot of sense... I'm going to see what I can do in regards to this and the other bug soon! I'd really like to fix these and push the new update out, but I need juuust a bit more time

Sounds good! And again, thank you for being so responsive on the boards!

ok, should be fixed!

Woo!