itch.io

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?

I'll give it a look shortly! But yeah that doesn't sound right... it should use the linebreak rules for japanese unless break text is turned *on* (which just, ignores formatting)

Maybe there's a rule I missed in regards to 「 characters so I'll give it a look next

Just to finish off this thread, (I know, I haven't been marking threads as "solved"...) we discussed further through email, and this should now be fixed as of 1.13.3!

Thank you for understanding! I really can see the value in it now though, so it's something I'd like to add sometime, too. I'm glad you found a working solution, though!

Right, double outlines could be useful! STM's main use is dialogue text, but as a damage pop up that would be really useful to have! Hm... that gives me an idea for a way to implement that... Ok I'll think about it for sure, then!  But I can't give a time estimate... sometimes shader things turn out to be easy, and sometimes they turn out to take years... But a hard-coded solution that's less-than-efficient should be possible to hack together over a weekend! But I'd want something fully customizable without code for a full release.

Hey!

Hm, out of the box, an effect like that isn't possible. If you're handy with shaders though it would be possible to edit the two types of outline shaders that come with STM to have additional colour passes! The "Universal" shader would just need more passes added that reference a different colour, and the "Ultra" shader would need... probably just a couple more calls to the function that draws outlines, but with different distances & colours.

Eventually I'd like to extend the new Ultra shader to be able to support effects like this (outline & dropshadow at the same time is planned first, though!) but it's not a very common effect for dialogue text, so there's other things I need to prioritize first, sorry!

Oops, sorry about that broken link, should be fixed now! How long was that there for...?

Thank you for your inquiry!

-Kai

I got the email! Will give it a look soon!

Would it be okay to have a look at your loading code? If the <w> tag is being sent to STM, and then STM is rebuilding... it *should* be animating... Is there anything going on with timeScale in your game, maybe? Is there a difference if "ignore timeScale" is enabled in STM? It's enabled by default so it may not be that, but it's worth checking!

I'll give it a close look this week! Thank you so much for your patience

Hmm... is Rebuild() being invoked when reloading? It could be that the variable that tells text to animate isn't being triggered somehow... Does enabling "force animation" make any difference for you? When text rebuilds, STM has an internal timer it keeps to animate text, so something may not be updating.. somehow.

right, i think one of my reasonings for leaving it in was that I was making a lot of textboxes with ample whitespace on the sides at the time (like the sample scene) but for something with a scrollrect... I'll revisit my line-end algorithm soon! It might be a bit since it's a low priority and you already have a workaround and I've been very busy recently, but I do want to make this change!

Hey!

This is something that's been in STM for a long time, and I kept wondering if I should change it or not... essentially, it works like this so that as it inserts hyphens, the rest of the mesh doesn't change to accommodate this, and manual hyphens get included in this too.

I really should revisit this and make it work in the way that would feel more natural, though. I feel like I would have tried to make it work that way and hit some wall in the past, but maybe I can come up with a real solution, now.

Hello!

Super Text Mesh just renders the data from the font directly, so not all fonts will be aligned with one another.

What I recommend is...

For text that uses a single font, you can edit the "baseOffset" variable to align the font how you like. But for multiple fonts, you can use the <y=offset> tag to offset text vertically.

So a string could look like... "ABCDEFG<f=chinese><y=0.2>你好</y></f>" (With 0.2 being whatever offset the text needs)

You can simplify this further by using Super Text Mesh's "Voices" data! If you create a voice named "chinese" with this text: "<f=chinese><y=0.2>", then all you have to type in your script is "ABCDEFG<v=chinese>你好</v>" !

I hope this information helps!

Hm, I'm not sure if I'm able to tell what the cause of the issue is from this screenshot, would it be possible to record a gif? What shader are you currently using? Is this in-editor, or in a build? What Unity version is it?

I just published a new update, so please let me know if v1.13.2 works for you! I made some changes to the "Ultra" shader, so maybe that's the cause here? There was an issue with rendering bitmap fonts on the previous update.

Ok, I think I've finally got a proper fix for this. Will be publishing an update shortly! The error seemed to be: I had those icons set as textures used by quads to show certain buttons to press in sample scenes, but as icons assigned to scripts/unity UI elements, that seemed to cause some kind of conflict.

Ok, I think I've finally got a proper fix for this. Will be publishing an update shortly! The error seemed to be: I had those icons set as textures used by quads to show certain buttons to press in sample scenes, but as icons assigned to scripts/unity UI elements, that seemed to cause some kind of conflict. 

Hmm, I'd believe it being a Unity bug, because without HideInspectorStuff(), there's no call to HideFlags whatsoever... I may just have to hard-code it so that whenever Unity tries to make a build (onpreprocessbuild?), the Fix() code is called...?

I'll take one more look soon before resorting to that method though, the fact it may be related to an initialization even will help! Thank you so much for your patience and help!!

Ok, perfect. I should have a new update out soon that this error shouldn't appear in.

gah I didn't consider this when I added the new class. It's just a warning not an error, correct? It should be fine to ignore for now, and I'll adjust it so it doesn't report an error in the next update. Sorry!

This problem has been reported for a while and as far as I can tell, I can't seem to find any code that would change the hideflags of the file whatsoever, so I thought the script to manually change the hideflags would solve it for good... Hm... maybe because the file is an icon to a script, that script could be having a hideflag applied to it and that's passed on to the icon somehow...? I do have some code within STM that changes the hideflags of the meshfilter and meshrenderer components, but I can't see how it's related to the icon... I'll be able to take another close look at this soon, sorry for the delays. But this really is a strange problem that's been bigger than it has any right to be. This is very good information though, if it's something happening just during editor runtime, that narrows down where the problem is.

If you want to test something for me, within the file "SuperTextMesh.cs" there's a method named "HideInspectorStuff". if you remove everything within that method, does the problem still occur? This is the part of the code that sets the meshfilter and meshrenderer hideflags I mentioned. I haven't been able to reproduce the bug in a while so that would be a huge help!

Put that code on any gameobject, drag in the files causing the error into the field, click the gear icon in the top-right of the component and select "Fix" from the dropdown menu!

Hey, replying to you here since it's a duplicate issue.

https://pastebin.com/0M2kf8D6 Here is the script I wrote that fixed the issue on my end, and what I did to the file before publishing. If you run this script on the same file, does the issue still persist? If so, I need to dig deeper as to why me running this code didn't fix it for everyone else, and if not... well I guess it's back to the drawing board. Sorry for the trouble! It seems that a few other assets have been effected by this type of error, too... If all else fails, it's just a bad .png file that can be deleted and everything else will work fine.

Ok, uploaded a fix for this (Hopefully correctly, this time...) As a note, the build number is the same (v1.13.1)

gah oh my god thank you for catching that, as you can see in my patch notes, I was supposed to fix that not building, but messed it up in another way... Really sorry about that! Will patch it soon