itch.io

Ok, I'll be able to give it a look, soon! I've been really busy with the holidays coming up, but I just want to let you know this is on my to-do list!

Thank you so much for sharing! I need to update the package properly but this will be great to have publicly for the time being. I'm glad it works!

Hello,

The Adventure Creator plugin was developed by a friend of mine if I'm remembering correctly, so I'm also unfamiliar with it! (And it hasn't been updated in a long time... I think!)

But going by that code, that should be correct for setting a baseline colour for a SuperTextMesh object... Are you able to edit the script attached to the "STM SubtitlesUI" prefab that you mentioned and add that code to it? Look for wherever that code is setting "superText.text", and you should put the line of code you shared on the line before that, so the colour is set before the text is set. My thinking is as follows: the script has to be getting the dialogue from somewhere, so that would be the right place to also grab and set the colour data.

I'll be able to take a look at the code myself later, (things have been really busy for me, sorry!) but this should be a pretty easy feature to be able to add yourself!

Ok, a few things to try:

1) On your Super Text Mesh component, set your Quality to 16, to match the pixel size of the font. (Quality is the font size that is rendered for dynamic fonts, so pixel fonts should usually be kept at their original size to render properly) This font probably has a *lot* of characters, so setting the quality so high *could* be a potential cause of the issue, if it's tripping up Unity's internal font texture tools.

2) On your font import settings, try changing "Character" from "Dynamic" to "Unicode". This will make the font be non-dynamic, so it *usually* eliminates the garbled text problem, with the caveat of the entire font being pre-rendered into a texture. I'll say that this *used* to be a concern back in 2018, but nowadays I think any platform shouldn't see any performance hits from this. (Pre-rendering the entire texture can take up more memory, but with a pixel font it's not really a problem in the first place, even with such a large character set)

3) Are you enabling/disabling the SuperTextMesh *component* at any point? Is it possible to enable/disable the gameObject instead?

4) Is that the only font you have named "Fusion Pixel"?

5) Additionally, and this is really silly, but since you're using a pixel font, *disabling* "pixel snap" may give you better rendering if your text object is grid-aligned in the first place. I'm just using Unity's pixel snap method, and honestly it's just not as good as lining up text yourself. I think it's meant moreso for non-pixel fonts. Unrelated to your issue, just saying this since I'm talking about pixel font rendering!

Please let me know if that has a difference for you. Basically, the garbled text bug is caused by when a dynamic font texture rebuilds, and the text mesh does not receive the "OnFontTextureRebuilt" callback. So... this could be caused by the Super Text Mesh component not being active, Unity's backend not sending the signal for whatever reason, or an error within my OnFontTextureRebuilt method within Super Text Mesh... but looking at it, I can't seem to see what the cause would be from that, unless the text object glitched out and isn't aware of the fonts it has within it.

Ok, in that case, what version of Unity are you using? And do you have the latest version of Super Text Mesh? Please try reimporting, I've seen situations where an update doesn't properly apply in the past.

What do the import settings for your font look like? And would it be possible to send a screenshot of the inspector for your Super Text Mesh component?

Is the pink text there the same mesh as the text on the right side of the screen?

This took a bit to figure out, and honestly I'm not too sure *why* this is working now and how it even was working before, but within the method "ApplyOffsetDataToTextInfo()", please update this part of the switch statement:

case Alignment.Justified:
    /* drawText[jL - (hyphenedText.Length - drawText.Length)] != '\n' */
    if(jL < hyphenedText.Length && hyphenedText[jL+1] != '\n'){ //not the very last row, or a row with a manual linebreak?
       info[j].pos.x += justifySpace * passedSpaces;
    }
    break;

That seems to do the job! I would send you a new build, but I have a few other unpublished changes in there, but I'll make sure this fix is in the next update when I upload it! Luckily, Japanese text is already justified since it has even spacing, so you can just use "Left" alignment and get the same result for the time being, anyway!

Thank you for finding this!!

If you go into the sample scene for "links", you can see some code there for how to convert existing tags to STM ones... (e.g. <link=myLink> becoming <e2=linkSpawnEvent> etc) That way, you can keep the system you have, and just convert it for the text renderer.

I think the "Auto Pause Full" feature would work well for what you're trying to do, but it's also possible to just manually take the leftoverText field, and send that to a new box when you continue, too... (I would advise this if the text gets *really* long! And look at the "pagination" scene for an example on doing this, too) STM is just a renderer, so you have a lot of control over how to integrate it into *your* system.

Hm I suppose that would be "superTextMesh.leftoverText.Length > 0" as an equivalent to that boolean, but also if you set the cut off mode to "Auto Pause" or "Auto Pause Full", Super Text Mesh has that built-in if I'm understanding what you want to do correctly. Just call superTextMesh.Continue() to have it keep reading past the pause. (This works with the <pause> tag, too!)

What do you mean by "built in test printing functionality" and the scripting system in your text? Are you using your own tagging system? STM should be compatible with a lot of stuff since it's programmed to be generic in use, so would it be possible to use that? You can use pre-parsing in STM to convert your own tags to things STM would recognize if you have an entire script written up for your game already! I may be able to point you in the right direction if that's the case!

1. Ah I meant, try manually calling Read() or Rebuild(true) when updating text in your code! Also I forgot to ask, is this happening only in editor, or does it still happen in a build? There's unique behaviour for changing the rectTransform in the editor that causes a rebuild... but it shouldn't happen when the game is playing, which would be the bug. I'll take a look at it soon!

2. Ok I'm glad the ultra shader works here! It's eventually going to replace the other shaders anyway, so I'll accept it as a fix.

1. Have you updated to the latest version? I changed some things related to the text mesh automatically redrawing when the RectTransform is changed in a recent version, so I'm wondering if this is a side-effect... does disabling "autoRead" (under the timing foldout) produce a differet result?

2. At first it looks like just how the Universal outline shader renders when the outline width is too far, (that shader only does an 8-pass outline) but the outline being thinner than the text on that shader is something I haven't seen... What version of Unity is this? Additionally, try out the "Ultra" shader, that's where I've been putting more work into prettier outlines, recently!

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.