I'm testing our Chinese localization, and I'm trying to figure out if the auto-delays are working. I created one for the "，" character and set it to 10 just to test, but it seems like it's still being read like a normal char.

Thinking about it now, maybe this is because there aren't any spaces in Chinese? An example sentence would be something like 星星都离我们很远，冥王星已经算近的了。 As you can see, there are no spaces between the comma character and the letters.

Do you think there can be an option to allow delays to work regardless of spaces? This would be useful for punctuation because you'd typically want to pause after any comma, period, etc., as long as it isn't the last char of the whole string.

Ah, this would be because I haven't added "，" as a character that gets an auto-delay by default... This system has two caveats that I need to reprogram so hopefully I get time to do that soon...

Basically, for autodelays, it's using the standard delay data scriptableobject to determine what characters are getting delays. These delay datas have special names used by the "SpecialKeyToName()" method inside of SuperTextMesh.cs. So... the ones that don't have names there won't work as it stands. 

The second issue is what you pointed out, the autodelay system will only care about what it calls "free" characters, characters with a space afterwards. A friend had some concerns about this system too, so what I want to do is...

1) Make a new, separate type of data for autodelays that instead of relying on the scriptableobject name, has a field for a char, and uses that.

2) This new type can also determine the behaviour. So "." might only come into effect if the next character is a space, while "，" will always cause a delay no matter what.

Different options: Always Delay, Only if followed by space, Only if followed by different character, Only if followed by same character or a space

Hopefully I can have this implemented soon, I think this will solve the issue...?

Makes sense, sounds like that would solve it.

Yeah, I noticed that there was a built-in ScriptableObject called "comma", and I know there's a note somewhere in the documentation about using special names for certain chars. I was actually able to create a ScriptableObject named "，", so I guess it's not an invalid filename? But either way, I think the second issue about the spaces would have prevented it from working regardless.

Hope you can get it fixed, because I think this problem would apply to any language that doesn't have spaces (so at least Chinese and Japanese).

Oh, great point!! The actual comma character you want to use *isn't* one that's blocked by file systems, so the current system will actually work for that step.

...But yeah I need to add a new class for autodelays so they can be given unique rulesets on a per-character basis, anyway... So hopefully I'll be able to add that soon. Really sorry for the delays!

Next updates gonna support this directly!! Got a new type just for auto delays, and they've got rule types that can be set!

Thank you! I'll try it out once the update is live.

Hey, coming back to this — how does the current auto delay system work? I see the note in the changelog for 1.13.0 that mentions auto delays having their own class now, but I think the objects in the STMAutoDelays folder look the same as before, unless I'm misremembering.

Basically, the goal is to modify the delay rules for Chinese characters (like the '，' comma) so that they activate regardless of whether they're surrounded by spaces (because Chinese text wouldn't have spaces regardless).

Hm, maybe reimporting the asset failedsince some of the new files have the same names as old ones? Try clearing the STMAutoDelays folder and try again, the files in there *should* be a new type! There should be a file named "comma_jp" that does the behaviour you want by default if you're seeing it right.

Ohh, I see — yeah, you're correct, I just made a mistake with the import. Thanks! This new system looks great.

What happens if you have two STMAutoDelayDatas pointing to the same char? I've always wondered how best to manage this. If I edit the delay values in the files in the STM folder, they'll get overwritten when I update the asset, so it seems better to duplicate them and keep my own copies — but in that case, should I delete the originals in Resources/STMAutoDelays?

It'll just pick the first data that matches that it finds in the folder. And yeah, I wish Unity had a bit more control over that when updating assets, but I feel like I have to have the defaults I already have included, or they'll just never be used/have to be created over and over.

I think you should be safe to delete the originals and make new ones, and then just be careful when re-importing in the future. If you were to import a double, you'd just have to delete the extra for STM to work as expected - it'll just go through the folder and find the first file that matches the requested data