Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Jul 23, 2014 · View creator page →

Creator of

Recent community posts

Just an update, we handled this though email, and the issue was Unity's startup lag. (Pressing play in-editor will skip the first few seconds of a game) The dialogue was set up to advance automatically & quickly under Start(), so it looked like it was skipping to the end.

Can you email me a sample project? Since I'm unable to reproduce the bug, I think I'll need that to fix it.

Hmm... if there's a split between how it works in-editor vs in-build, then it might have something to do with the Update()/OnValidate() cycle?

I tried running your code myself, and the strangest thing is, it works perfectly fine for me in-editor? What version of Unity are you using, and are you using the latest version of STM?

(1 edit)

What is the current draw animation attached to your mesh? It's possible that reading is being set to false early because the animation takes time to complete even if the reading loop is done... I think. It's also possible that this code is being called before STM has begun reading, which would also cause "reading: to be false.

 Either way, personally I'd use STM's on complete event for this instead! That way you don't need to check the state of the mesh every frame.

(1 edit)


I just wrote up a helper script that should do what you need, attach this to a child of your STM object, and it should update the size of its rect to match STM's textBounds variables:

using UnityEngine;
using System.Collections;
public class STMMatchRect : MonoBehaviour {
    private RectTransform tr; //this object's own transform
    public SuperTextMesh stm; //stm used for reference
    public Vector2 size;
    public Vector2 offset;
    //set up events!
    public void OnEnable()
        stm.OnPrintEvent += Match;
        tr = GetComponent<RectTransform>();
    public void OnDisable()
        stm.OnPrintEvent -= Match;
    //make this object's rect match STM's current text rect.
    public void Match()
        //box size, plus offset
        size.x = stm.bottomRightTextBounds.x - stm.topLeftTextBounds.x;
        size.y = -stm.bottomRightTextBounds.y + stm.topLeftTextBounds.y;
        offset.x = stm.rawTopLeftBounds.x + stm.rawBottomRightBounds.x * 2f;
        offset.y = -size.y - stm.rawTopLeftBounds.y;
        tr.sizeDelta = size;
        tr.anchoredPosition = offset;
        tr.pivot =;

Also, as it stands, this will actually set the size incorrectly, as STM calculates its bounds after calling events. I went ahead and fixed that alongside a long-standing bounding box sizing issue, so this will work with the next update! (The helper script will be included, too)

Please send me an email with your invoice no. and I'll send the update immediately! I'll be submitting it to the asset store/itch in just a moment. If v1.8.12 is up, then that's what I just submitted.

(1 edit)


Was just thinking about this yesterday, I'm pretty sure the sample dialogue box code in the stage example scene shows how to do this!

I'm pretty sure it works with auto-pausing, so it should work with the <pause> tag too? If I'm mistaken, I'll write up something!


Just letting you know we're working on this, here's how current progress looks. (The blurring currently isn't clamped to the UV data)

Hmm... if you set stm.areWeAnimating to false, that might do it! That's the boolean that tells STM to keep animating under Update() if a wave has animation. I should probably rename that variable...


That's a really good idea, actually! I'm still in the process of having a better outline/dropshadow shader created by a friend of mine, so I'll forward this to em! Right now, the dropshadows are just the main text pass, but with a different colour applied...

The way I'd get this working is to, as you said, add a blur slider, directly in the shader. STM uses fragment shaders, and there's plenty of ways to do gaussian blur in a fragment shader, so... I guess it's a matter of trying to make the two play nice. I've already messaged my friend, so we'll take a look into this on the weekend!


You can try...

stm.Rebuild(), //make sure read automatically is off


What is this 3rd party tool by the way?

Remember read position is for enabling/disabling meshes. You can change the delay mid-string with <readDelay=0.1> I believe? Or insert a manual delay with <d=0.1>. Will this achieve the effect you're after?

For the length, stm.latestNumber will give you the index you need!

Another option for stopping text is to use Append() when you need to add more text to a string. Will this work for your needs?


If you want to stop reading at certain points, you can use the <pause> tag, and then call Continue() to keep reading from there. You can also use the timing tag <t=5.0> to make the following letters start reading from a specific time.

If you mean length as in time, you should be able to use...[stm.latestNumber].readTime. That should give you the time the latest character was printed out at.

I hope this works for you! Let me know if I misinterpreted what you meant!


Automatic text wrapping characters are actually something I've been meaning to revisit for a while, so they can be completely customizable.

Right now, stm is programmed just to autowrap at spaces, hyphens, and tabs, but its just a few lines of code that controls this, so the additional characters can be added that way until I redo that system to be easier to edit.

The lines that wpuld need to be added to are lines 1806, 2889, and 2938. Those just have if statements that look for the specific characters. (This really does need to be redone)

The slighty trickier part is around line 2392. There, variables are created to check the positions of linebreak-ready characters, and then on line 2392, all those variables are compared and a linebreak gets inserted at the largest one.

If ypu need additional help, email me through my website with your invoice no. after purchasing, and I'll send you a modified version of STM with these changes. Once again, I hope to make this system more dynamic in the future.

Got it, I changed the code to work for 2017.1.4.

And it doesn't throw errors in 5.3.4, it simply doesn't work like how the current code wouldn't work in 2018. Good idea leaving both options in, I'll give that a go, then I wouldn't have to worry about the unity version.

(2 edits)

Okay yeah trying this out further, this works fine in newer version of Unity, but in 5.3.4 this method doesn't work. If I could pinpoint the exact version of Unity where this breaks, I could use platform-dependent compilation to fix this, but right now that's not really good.

From that bug report, I guess I can assume it's 2018.1? I'll try implementing this, and see if it ends up cropping up in different versions. This wouldn't be the first "by design" bug to hit STM

Oh my god, I never realized this method would work. I figured those toggles were just material inspector shorthands, I didn't think changing the value via code would actually change the keywords! Thank you so much, I'll get this implemented ASAP.

Huh, I never see SDFs turn out that wiggly... then again, the SDF font I mainly test with (itim) doesn't have many straight edges, so the default settings I suggest might not be optimal for all fonts. Is it possible to use an SDF font generated by TMP with STM? I've never actually bothered to see if the systems are compatible, but now that TMP is included with Unity, that's an option to consider. 

The SDF generator I suggest, from what I gather, should be the same code base as what TMP uses anyway? You might have to try upping the font quality even further, or making the inside/outside be larger or smaller (I can't think of which one would produce a sharper image)

I *do* see a small amount of that same "wobbliness" on the TMP text, so it's gotta just be the SDF generation, that's what I'm thinking anyway?

That's my best guess for now! Please give these ideas a shot!

Okay, I think this one has me completely stumped. At the moment, I have no idea why this editor code in "STMCustomInspectorTools.cs" isn't working in newer versions of Unity. The workaround of toggling SDF mode & pixel snap works fine in a material's own inspector, so that might have to be used for just a bit. I'll add this to the official bug list, and hopefully figure out a solution soon.


I'm not too sure what you mean by smallcaps... do you mean text Lɪᴋᴇ ᴛʜɪs?

If you want to just have small capital letters, you can use the tag <s=0.5> to have certain text be smaller than others. (The <size=5> will set the text's exact size, not relative size like <s=0.5> does) Besides that, you'd have to make your own pre-parsing script to generate these special smallcaps characters from the normal ASCII data. This method can be done with a standard text mesh too, so it actually falls outside of my jurisdiction, but if you need help getting started, check out the other preparsing examples included with STM to see how to do custom text modifiers!

Alright, I've narrowed it down to being a bug with my inspector. If you go into your material's inspector (the material being used by your STM object), you can toggle SDF mode and pixel snap just fine from there! SO that's the quickfix, I'll see what I can do about getting the inspector to play nice.

(1 edit)

Just replying here to let you know I'm tackling this in the main thread, not sure if you'll get notifications for that

Okay, was able to reproduce the SDF mode toggle thing in 2018.2! (I develop in 5.3.4) I'll see if I can solve this r/n


The underline code is handled a custom event - please check out the underline/strikethrough example scene to see how that works! (It's done this way so underlines can be drawn in any way without needing to be rigidly built-in. This method would let someone make a zigzag underline with little modification, for instance)

Basically, a custom event like <e2=underline>This text is underlined!</e2> is used to draw an underline under your text. The code I included lets you change colour per-mesh, so you should already be able to change the colour this way! Check out the components atached to the STM object in that scene, and that should explain it well!


Yes, there are some hidden values in STM that should give you these values, but you can do some tricks with string.Split, too!

"stm.lineBreaks.Count" should give the amount of lines. "stm.hyphenedText.Split('\n').Length" should also return the same value.

"stm.hyphenedText.Split(' ').Length" should give the amount of words, by counting the amount of spaces in the final text shown.

Words in a line is a bit trickier, but you can use the info from the lineBreaks list (this list contains the indexes of line breaks in hyphenedText) to do this.

This is some really rough untested code, but something like this will give the amount of words in the first line of text:

string line1string = stm.hyphenedText.Split('\n')[0]; //get all text before first linebreak
int line1wordCount = line1string.Split(' ').Length;

I hope this helps!

I think <pause> would be your best bet! You can call Continue() in your code to have STM continue reading past this point.

Also, your request about fading in/out text is totally valid. I added the "All At Once" read order option for this case, but it seems a bit hacky in practice. A friend asked me recently if you can control STM's colour with unity's animator, and I'd like to make it work that way, sometime. (Right now, Rebuild() would need to be called every frame the color is set) This wouldn't work with gradients anyway though, I'd have to add additive/multiplicative gradients, another feature I was debating on for a bit. (Would require a re-write of STM's colour system)

If you haven't figured it out, you can use the Unread() function to make text use a draw animation in reverse, too! Under "functionality" in STM's inspector, you can customize which animation is used.


Yeah, the outline shader takes on the texture of the text at the moment, it's honestly a feature I haven't used myself so I might change it to what you want, or make it a toggle-able option for the uber shaders. If you go into "STMoutline.cginc" and change the lines

col.rgb = mask.rgb * i.color.rgb; 
col.a = text.a * mask.a * i.color.a;


col.rgb = i.color.rgb; 
col.a = text.a * i.color.a;

That should do it, I think! You might have to right click STMoutline.cginc within unity and select "ReImport" to see the change take effect.


That's awesome, thank you so much for finding this... Unity UI has so many specifics to it, I probably wouldn't have found this myself. I'll make is so that always gets called when Rebuild() gets called. It seems to solve it!

Thank you!

Hey! I'm halfway through solving the problem.

When autoWrap is defined, instead of setting the UI Autowrap value to be "(float)tr.rect.width" I'm setting it to be "preferredWidth" (a value set by Unity UI) and it seems to make the text appear on one line as expected.

That said, text still has an offset applied to it until it's updated. (Even turning on reading and setting the mesh to read all at once didn't fix this) but strangely enough, the text bounds are *half* correct. The blue box that's supposed to be the bounds are set incorrectly, but the yellow box defining the text mesh's actual size is accurate to where the text *should* be.

I've got to head out right now, but hopefully I can use that info to track this down asap!


Make sure on your material settings that the Unity UI default shader has its mask mode set to "Outside". I accidentally shipped a build where that value was set to "Inside" which doesn't render text.

Try not importing the legacy shaders - those all used surface functions, and all the new shaders use fragment functions. These will be excluded from the next 1.x patch.

Finally, try right-clicking on the .cginc files in the "Shaders" folder, and click "Reimport".

Please let me know if any of these work! That last one is strange, but Unity doesn't automatically recompile .cginc files when they change, and I just realized that they new .cginc files wouldn't line up with the new shaders after an update. Hopefully that's the one that fixes this?

Ok awesome, I'm able to repro it. I'll see what I can do!

Would it be possible to get a screenshot of the scene view? I'm curious how STM's bounding boxes are set up with Unity UI. I'm currently still unable to reproduce this, would it be possible to set me a sample project that recreates the bug?

Does it make a difference when you put that function under Start() instead of Awake()?

Just an update as this was solved through email. The above solution I had ended up working.


The text isn't rendering because I accidentally set the mask mode to be "Inside" by default. Set it to "outside" and it should render fine! I'll change this in the next patch, sorry about that.

That's odd that the SDF mode box can't be checked... as long as it's visible there, I can't think of what wouldn't make it toggle-able. I'm able to toggle it in the exact same shader, maybe try it after solving the above issue? It should make some additional settings appear in the inspector immediately. Let me know if that leads to anything?

Finally,  the legacy SDF shader wasn't meant for Unity UI text, only normal text. Using any legacy normal text shaders on unity UI results in it rending all-black.



These are all files I updated in the very latest update to fix a big where text wouldn't cast a shadow, and to add more masking options to UI text.

Please do a back up before updating just in case, but have you tried setting Unity's asset serialization mode to "Force Text"? Or have you tried deleting the original files before importing the new ones? If the GUIs are different, it might just be that you have to re-apply the shaders in STM's inspector. (Changing any value will tell the mesh to Rebuild, which might be why it's not showing?

Also, if you moved STM's files to a different folder, this might also cause the issue as Unity will always place new files in the original folder, so that would create a double instead of replacing the original.

There's a bunch of things that could be causing this, but these are the first solutions I can think of off the top of my head! Please let me know what works for you.


Are any events after <pause> being called? Audio clips and events are called during the same part of code, so this will help me narrow down the issue. Would it be possible for you to email me a sample project?


Looking through my code now, I can't believe I made it so Continue() relies on the autoRead variable, so I've changed that. Doesn't really make any sense in practice... So now within the "Continue()" function, I've changed the line of code reading "Rebuild(totalReadTime, autoRead);" to "Rebuild(totalReadTime, true);".

That said, you should be able to use "Read(stm.currentReadTime)" so you don't have to cache the time using an event! (currentReadTime gets set to where the mesh last left off when Continue() is called)

There was a bug related to <e> tags being right next to <pause> tags that got fixed in v1.8.2, maybe it could be related to that?

Besides that, I can't seem to be able to reproduce the bug. Hopefully this is enough to get it fixed? If this doesn't work, I'll take a closer look!

Patch should be up now (v1.8.5) as long as nothing goes wrong!