Hey,

Ran into a problem when using <pause> tags with fully centered alignment (Anchor: Middle and Alignment: Center).

If you create a long string and put a <pause> in the middle, the bounds of the mesh will initially be based on the first half of the string, not the full string, and the text is centered accordingly. After calling Continue(), the bounds seem to expand to fit the full text, and the text jumps to its new location after being centered. I think this is expressed by the purple box in Scene view.

Presumably, the intended behavior is to account for the full, final size of the text box when determining the centered position, right? This way, the <pause> tags are invisible to the player, and the text simply continues after calling Continue(), instead of visibly moving upward to make space for the newly added text.

Btw, I considered working around this with a custom event, but I couldn't find any other way to pause a mesh from reading out aside from using <pause>.

Oh! Good point here, the way the <pause> tag works is that it just stops all text rendering up to a point, then upon Continue() is rebuilds everything until either the next pause tag or the end. So on center-aligned text, that would cause a misalignment... So as it reads out, it's center-aligned at its current point in time, but not relative to the final mesh... 

I think if I were to implement this, I'd have to change a lot about how the pause tags work, pagination, and alignment... I think it might be possible, but I don't see an easy path to it at this moment. I'm going to have to think about it for a while... (Maybe I could have it like... still cut off the text, but only after parsing for line size, and it could insert any linebreak characters at the right position, still...?)

If your pause is just something automatic, rather than controlled by the player, you could try the delay tag? <d=numberHere>

You could also try this... instead of a pause, do this:

First half of string! <drawOrder=allAtOnce><c=clear><e=somethingToDisableAudio>Second half of string!

and then when the player hits the continue button, print this...

<e=somethingToDisableAudio><t=-10000>First half of string! <e=somethingToEnableAudio><t=0>Second half of string!

So... the dialogue would advance like normal, but the text would be disguised like it was just one box.

Thanks for the suggestion. Yeah, it's a player-controlled situation (waiting for input).

I can see how that would work, but... it's quite a bit of a hack to add/remove those tags and rebuild the mesh, especially with multiple other tags in the way, and multiple pauses.

That said, it seems to work well enough if I just add a <d=99999>, and then remove it when the player presses a button (using an event to detect when we've reached this pause, of course).

What's the max value for a delay? This seems like it would work for my purposes - even if the text auto-advanced after a minute or so, it wouldn't be game-breaking; the pause is only there for drama anyway.

One option is to make all those tags I mentioned into one of the voice tags, so instead of typing a long tag, it could be... <v=fakepause>, <v=fakepausecontinue>, <v=fakepauseresume> or something like that.

There shouldn't be a limit on delays! If you make a preset delay in the save data editor, you can save room typing a long number, too.

But there's an even better, kinda hidden option if you're okay with just pausing the text forever... try using <t=Infinity>! That'll use the timing tag (which tells text after that point to start reading after X seconds), but give the following text an infinite value for it's designated read time, so it'll just never read. It works since that tag just uses string-to-float conversion, so make sure "Infinity" is exactly like that, with an uppercase "I"!

Really sorry about this though, it's such a strange edge-case...

Actually, thanks! That's a good suggestion with <t=Infinity> — seems to do the same thing that I was trying to do with the <d=999>, except it's actually infinite and not just effectively infinite. I just tested it, and it's working for me.

Hey, does this still work in 1.13.2? I'm getting the following error when the game tries to read a line with a <t=Infinity>:

Converting invalid MinMaxAABB
UnityEngine.Mesh:SetTriangles (System.Collections.Generic.List`1<int>,int)
SuperTextMesh:SetMesh (single,bool) (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:5424)
SuperTextMesh:SetMesh (single) (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:5362)
SuperTextMesh/<ReadOutText>d__283:MoveNext () (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:2074)
UnityEngine.MonoBehaviour:StartCoroutine (System.Collections.IEnumerator)
SuperTextMesh:Read (single) (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:1858)
SuperTextMesh:Rebuild (single,bool,bool) (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:1723)
SuperTextMesh:SpecialRebuild () (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:1417)
SuperTextMesh:Update () (at Assets/Plugins/Clavian/SuperTextMesh/Scripts/SuperTextMesh.cs:1780)

I won't be able to update to a new version of STM at this point, so I'll have to just use <d=99999> for now. But, let me know if this is a known bug and/or if it's something that can be fixed without changing the whole rebuild process (I worry that the latter would introduce unexpected bugs).

Hm, I think at some point I made the string conversion for floats use a different method that uses InvariantLanguage so it would 100% be consistent across systems, so I wonder if that broke it... <d=99999> should work for now though, and I'll give this a look when I'm back from vacation!

Hey! Sure, that works.

Yeah, I switched it back to <d=99999> and it was working correctly, so I'll probably just leave it as-is instead of risking other bugs by changing things. So I guess this is more of a heads up that the string conversion for Infinity doesn't seem to be working.