itch.io

If you're creating text data objects through the text data editor, they will be recognized immediately by STM, but if you make them through unity's project window, you'll have to go into the text data editor (click the [T] in the top-right of any STM inspector window), and scroll to the bottom and click "Refresh Database". Please let me know if this solves your issue!

Right, Super Text Mesh has a custom material viewer for editing material properties right in the editor (The code for this is within STMCustomInspectorTools.cs) but that's not needed to edit the material properties, you can edit it as if it's a normal material! (By clicking on the created material in the project window, and editing the properties in Unity's inspector)

I'll take my own try at it and email you that, but it sounds like you've basically got it! For the record, I wasn't going to edit the inspector code to get this working, myself... If I'm happy enough with the implementation, I may add it as a standard feature to the Ultra shader, but I'll have to test for performance efficiency

Oh, I see what you mean now! When you said gradient, I thought you meant in the way that the rainbow text STM has by default shows a gradient over space, not a gradient over time. *That* should for sure be possible to mod into a custom STM shader without needing to mask anything. I should have asked to see a sample sooner, that is indeed a cool use-case for a gradient outline!

Are you familiar with modifying shader code? What I'm thinking is basically... Set it up so the _OutlineColor variable is either a gradient or two values representing the colours you want (e.g. _OutlineColor1 _OutlineColor2), and then you use _Time.y and some math (Or _SinTime.w! Or a custom pingpong function...) to lerp between these values within either the vert or frag functions of the shader, where the shader normally just grabs _OutlineColor. I could code this for you if you send over your invoice number via email, but I think it could be a good learning experience to try it yourself!

It's common in graphics design, but pretty rare for dialogue text in games! Have you seen the effect in another game? That might give me an idea on how it was implemented.

What is the effect going to be used for if you don't mind me asking? If it's something like short UI elements or decorative text, it'd be way more efficient to just render what you need in an art program and drag that into Unity... I can chase efficiency all I want, but I can't beat a .png when it comes down to it! (With raster-based text rendering, anyway!)

The only way I can think of doing it *now* (and didn't care too much about efficiency) is...

Set the outline colour to something to use for a chroma key (lets say green), and then have it so that text is on a layer that's only captured by a camera obeying that chroma key and replacing it with whatever you need.

Hello!

The outlines just support a single colour. It might be possible to modify the shader to add gradient support, but I'll say that it's a bit of a tall order with how outlines work in general! Really sorry about that. 

-Kai

Hello! I got your email and answered you there.

For anyone else on the forum finding this, I believe the solution is to press the [T] in the top-right of any Super Text Mesh component to open the text data editor, then to press the "Refresh Database" button at the bottom. This is an extra step needed when making Data objects outside of the text data editor.

Hey, going through my checklist, did I ever fix this? It looks like STM calls Rebuild with OnRectTransformDimensionsChange() instead of Update() and a manual check now, so is the event still being fired constantly? I could probably add another check to make sure STM *actually* needs to update at this point...?

emailed you the script!

Ok, i think I got it... this is how it looks with "break text" off, now.

Still playing with this, now I've got this result:

Break text off:

and break text on:

This seems to be a more desirable result for Japanese, but the first result should be respecting the bounding box size, and it's not. So I'm looking into why that's the case

Hey!

Just checking, is this a more desirable result?

I found that some logic was misbehaving involving the "insert hyphens" variable, where STM was giving different (and way too far) breakpoints when hyphen insertion was disabled. This is some of the oldest code in STM and is pretty english-oriented, so it was only a matter of time until some cases like this popped up. 

I also temporarily removed the japanese comma and period as being linebreak-friendly positions for the above result, as STM would overly favour them as linebreak positions. I'd still like it to be a "friendly" position, but only when it's near the edge of the text box. Going to keep working on that, but if this looks good, I can hack it into your version of SuperTextMesh.cs for you!

I'm still working on this, there's still a few text elements that can go over the box limits...

I'll give the code a look on a workday! Chances are, if it's something in *this* part of the code, we should be able to retrofit the solution into your project. I want to fix this asap...

Oh! I see, it's probably just a rect fitting issue! Attach the component "Content Size Fitter" to the STM object, and set the vertical size to "preferred" and things *should* work as you want if i'm understanding correctly... That will resize the rect around STM to match its internal text bounds.

Hm, the shaders in Super Text Mesh *should* be updated to work with both sprite and UI Masks, but not Rect Masks, just yet. (Unity's documentation on rect masks was severely lacking) Were the dialogue boxes you were looking at using rect masks? If so, I'll ask to replace them with regular masks for the time being!

That's probably just it, then! Not a bad idea!

Huh, that's quite strange... Super Text Mesh should intentionally not use a namespace... even though it's technically a bad practice, I wanted it to be able to be imported into any script without needing to import it.

If I had to guess, I think the assembly definition in your scripts folder just didn't know about SuperTextMesh... Assembly definitions are a bit of an advanced feature in Unity, relatively speaking... Did a tutorial have you put that there, or was it there by default? I may be behind on a few Unity versions, so please let me know if that's a new default feature in Unity I need to account for in my assets...

Additionally, I'm just assuming that it's pseudo-code, but try defining the declaration like this:

public SuperTextMesh superTextMesh;

That way, you'll immediately be able to know if the type is recognized, and you can drag the component into that field in the Unity inspector, instead of using GetComponent(); (You said you were new to Unity, so I feel this is worth mentioning! It took me a while to realize you could do this at first)

I'm back home now!

Send me an email with the address on my website, and I can send you the updated shader to replace

Hey!

Please try the new "Ultra" shader, it's designed to fix this issue.

That would be within Assets > Clavian > SuperTextMesh> Shaders > STMultra.shader by default, I believe. I'm just doing this by memory so I may be wrong...

By the way, this is assuming you're using the ultra shader to begin with... the same error may actually be on the universal shader too, so the shadow passes there can be removed as well. Those are within the "Universal" subfolder within the Shaders folder. Really sorry I can't just send a build at the moment, so I hope this helps!

Hey! 

I think this may be a bug that I've fixed but haven't published the patch for. I fixed it just before I went on a trip so I wasn't able to push it just yet...

I'm assuming this is the Ultra shader being used with Unity UI... if that's the case, please go into the file for the Ultra shader and delete the shadow pass entirely. It's the final pass on the shader, and the extra "ZWrite" call should be deleted, too. Sorry I'm not just sending the updated script, but I can't until I'm back next week.

Otherwise, try tweaking the parameters on the sketchify script? I'll be able to give this a closer look soon!

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!

It's ok! It's strange, I've actually gotten a few errors where the solution was an update improperly applying... I've even run into it myself when re-importing despite seeing new files and making sure they were checked (in fact, I'm pretty sure that thanks to this, some code in another asset of mine hasn't gotten published so I'm planning a complete manual code comparison...) so... I'm not too sure why Unity's doing that, maybe something could be wrong with my metadata...?

Either way, glad it works!

Hi! Thanks for using STM, it means a ton!

I'm on vacation right now, but I'll give this a quick look...

Is the character '。' exactly? In STM, there's a long array of "linebreakUnfriendlyCharacters" which controls what characters can never appear at the start of a line, and this character is in it... Can you make sure there's no space/zero-width space before the '。'?

Also, is the variable "breakText" disabled in the STM inspector? Does disabling "insertHyphens" when using Japanese text make a diff at all?

Off the top of my head, those are two things I can think of to look at first! If neither of those work, I'll have to figure out what it could be... In that case, could you paste that exact string of text you're sending to STM here?

Oh I think I was misinterpreting the issue... do you mean that when a tag like <<set $var to value>> has a period in it, parsing fails? Or is a string with "." in it being considered the end of a section of text, requiring player input afterwards?

The default parser shouldn't be breaking up passages by periods at all, only with linebreaks (and special strings interpreted as linebreaks, as seen here:)

So... make sure that "." isn't in that array! But if that's not the issue, I'll have to take a deeper dive into what may be causing this...

Hey!

Hm, so is your project set up so that periods cause a full stop, waiting for user input? I recently added a feature to prevent this with ellipsis to Super Text Mesh, so I'll share...

Basically, is it possible to: instead of parsing for a period, to instead look for a period that does *not* have a period immediately after it?

...That's if I'm assuming the situation correctly! Please let me know if I'm misunderstanding... Like are you using the default parser? Or something custom?

1. Yep, the default one is always named "default". So the tag for that one can be <j> instead of <j=default> as a shorthand. When re-importing, uncheck "default" to keep your updates to it.

2. Ok oops, that one folder is actually different from the rest, since it just contains the default materials STM uses when a new object is created, not anything related to the tags iirc. What I meant to say was: when *re* importing, leave the resources folder unchecked, so the data in there doesn't override your changes that were made. You can also specifically uncheck different subfolders.

3. Getting a fix is all that matters! Glad you have something that works!

Hey! Got a few ideas here:

1. Are your custom animation files built on the default ones? Unity keeps track of what files are what with metadata files, so even if you change the included waves, when you update, it'll think that the update's wave is the one you want. If this is the case, you can create a duplicate (ctrl+D) to copy the wave but get new metadata. As long as there isn't a name overlap, that should do it.

2. When importing, uncheck the "Resources" folder.

3. You can create a new directory elsewhere with the name "Resources/STMWaves" and place data in there. All that matters is that it needs to be a folder named "Resources" and then the correct subfolder name for the data type.

At the bottom of the text data inspector, there's a button to gather all data, so you may have to press that to manually gather data that hasn't been created through the inspector. It's also possible that the main settings file is being reset on import, and this button just needs to be pressed, too?

Could I see a screenshot of the inspector for the STM components? Basically, there's a couple settings in STM that are there for legacy purposes, so it's possible for STM to follow a layout wrong or differently if not configured right.

For the contentsizefitters, make sure they're set to "preferred size"... even though the verticallayoutgroup has a notice that pops up, iirc, it seems to be the right way to do this kind of thing if I'm understanding correctly...?

Hello!

Ok, I really regret naming that property "quality" but that value refers to font point size. If you set it too high, the font will naturally be way too sharp and use Unity aliasing to resolve itself when displayed that small, so it can look like that.

So i suggest lowering the "quality" value and seeing how that works for you. If you're using STM on Unity UI, there's an option to automatically set this value where it tries to get the best value for you, but generally... if your "size" is 40 and this is on a canvas with no scaling, set the "quality" to 40 to have a font size that matches the canvas.

For a true SDF, you'll need to follow the steps in the documentation to generate an SDF font, but usually the steps I just listed are good enought o have great looking text.

I'll check in closer detail later, but it may just be that your test project lost reference to the waves - go into the text data editor (the screen that pops up when you click the [T] in the top-right of any STM object) and click the button near the bottom. Let me know if that works!

Hello!

The way this is meant to be implemented is with inline tags!

<readDelay=x> will change the read delay value mid-string, so this is probably what would be most helpful. Use </readDelay> to return the delay back to a default value.

<d=x> will insert a single multiplier to the read delay (eg. if your delay is 0.1, typing <d=7> will produce a 1-time delay of 0.7) You can also define preset delays in the text data editor (the [T] icon in the top-right of any STM component) so if you're using the same delay over and over again, you can define it there so you don't have to edit your entire game script to make a programming value change.

The tags let you do a lot of mid-string programming, so I hope they're useful in this situation!

Hm, if you're seeing that when looking at the inspector for STM, something is very wrong... can you try a full re-import? Try doing a backup of your project (if you have custom Text Data files, these can be added back by putting them in the right folders and using the "Refresh Database" button I mentioned later, which should hopefully comeback once this is done...), then completely delete the SuperTextMesh folder, then re-import the asset. With any luck, settings you have on individual text objects should carry over properly. So please do this backup just in case a step gets missed or it doesn't go well, we can just try again.

I try to make the upgrade process smooth from version-to-version (in the docs, I'll list any major changes underneath the changelog), but when going past multiple versions, it's possible for things to break if the right steps aren't taken... Based on this evidence, I think some file got misplaced or not updated properly between imports?

The one in the scripts folder is the script for that file, while the one in the Resources folder is a scriptableobject. Because you updated from an old project, it might be possible that the old file either got duplicated or the metadata got assigned to the wrong object... The file used to be formatted differently in older versions of STM, so it's possible for something like that to happen... Does the error persist if you go into the text data editor (click the [T] in the top-right of any STM inspector), scroll down, and click "Refresh Database"?

When you search your entire project folder for "SuperTextMeshData", is the ScriptableObject and the .cs file the only two files that show up? If there's more than that, see if there's a copy of the ScriptableObject somewhere, that would cause this problem, too

1) For the Resources folder, just make sure that the "Resources" folder withing the "Super Text Mesh" folder is where it should be - it's important that *all* of the folders within keep the same names. (The folders are named things like STMDelays, STMGradients) They can be moved to a different folder named "Resources" but for organizational reasons, it's much easier to keep them where they are. The error you received is specifically for the file "SuperTextMeshData" being moved from this folder, so please make sure it stays in a folder named "Resources".

If you receive this message upon first importing STM, it's normal.

2) This error is being called because "data" is null... "data" is a the variable that points towards the above "SuperTextMeshData" file, so I believe these errors are one and the same.

So... please make sure the "SuperTextMeshData" file is in a folder named "Resources"! I believe that will solve the issue.

Okay so I gave this an honest try and I've got to say it's a huge headache... I had every aspect implemented and got confirmation that this code was being called: https://docs.unity3d.com/ScriptReference/CanvasRenderer.EnableRectClipping.html

...But it didn't seem to change anything at all about the text being rendered. Unity has 0 docs on how to implement IClippable, and even going into the source code, I'm having trouble telling exactly what's missing. So I'm going to suggest to just use regular masks for the time being, as much as I want this to work. Sorry...

Hello,

Hm, I'll look into this but I did recently add basic mask compatibility to all the shaders that come with STM, so basic masking should at least work.

Looks like for RectMask2D support I just need to implement the IClippable interface (https://docs.unity3d.com/2018.3/Documentation/ScriptReference/UI.IClippable.html) in addition to IMaskable on Super Text Mesh in order to make it work... I think it should be possible judging by the documentation, but I won't be able to look into this until at least Monday.

Okay yeah that is weird... It should want to break at that period there... I'm still not able to look just yet, so my temporary hacky answer is... make a pre-parsing script that inserts a zero-width space before a 「 and after  」? Really sorry again, I've got a lot to take care of at the moment but I want to give this a close look soon

If you want to try and make a change yourself, inside of SuperTextMesh.cs there's a large array named "linebreakFriendlyCharacters" and another for unfriendly characters... I think. It might be that I forgot 「 or put it on the wrong list?

Hello,

Honestly, I don't think I can look at it this week... Big life changes just happened, so I need to take the week off for the first time in a long time. 

For the time being, is it possible to leave a bit of extra room on the right side of the text box? I really do want to revisit this, I just remember it being a very tricky issue, so I really don't want to give a time promise...

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?