itch.io

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.

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...