fungus

Open full view…

TextMeshPro RichText and LineDrop issues

soulkarl
Thu, 12 Sep 2019 00:15:27 GMT

==REGARDING RICH TEXT== So this issue has bugged me for a while and I can't seem to address it myself so I'm coming here asking for it as a feature request for the future. Currently, if using TextMeshPro instead of the default TextMesh, the fungus richtext tags don't work (ie: { } {color=red}color{/color} or {i}italics{/i}). This is likely due to the fact that the richText tags in TextMeshPro use lessThan/greaterThan symbols for their bracketing (ie: < > <color="red">color</color> or <i>italics</i>). THESE richText tags DO work, however they have a serious issue in that, as they are typing out, we see the tags type out before actually making the change for the desired effect (which is to say, we would see <color="red", before it closes the brackets and the color text comes out as red). This is obviously a huge issue and just makes it impossible to use richText at all with TMP. ==REGARDING LINE DROP== A similar problem happens whenever there is a linedrop needed from the text wrapping. It SHOULD work similar to how Fungus used to work (I think it's changed anyways - haven't been using the base textMesh in over a year, and realistically no one should since Unity bought out TMP and it's part of the package manager now) where it used to reveal hidden text rather than actually just typing out per token. However, the way it currently works is as you would expect from typing in something like Microsoft Word. The word starts typing on the top line, and only realizes it needs to line drop once it has gotten too long for the current line its on. What this means is that the text drops down LATE and starts initially on the line above where it is supposed to go. The current way text is parsed in Fungus is DENSE and spread out over a couple of scripts, so it is way beyond my ability level to solve myself, hence why I'm asking for it potentially in future updates. The TMP documentation is fairly robust (http://digitalnativestudios.com/textmeshpro/docs/) and they also have this video tutorial showing how they'd approach typing out text (https://youtu.be/U85gbZY6oo8) which seems to fix both issues. ==REGARDING WRITE SPEED LIMITATIONS== One more thing regarding the text (but not related to TextMeshPro) is the typing speed. I'm fairly certain that the token writing used to be handled in Writer.Update(), which I could no longer find, but the issue still seems to be the same - namely, that the text writing speed is capped at the same speed as frame rate (which is honestly way too slow). Is there some way to change this to not be that way, and/or to change it so a % of the total string is written out per frame (rather than a limit of 1 token) to allow for both a faster and more consistent speed of text crawl?&quest; if anyone knows of any quick bandaid fix to any of these issues also please let me know as I don't mind editing any of this code myself, I just kinda need to know where to look. Thanks in advance and keep up the great work on this asset!

Steve Halliwell
Fri, 13 Sep 2019 22:04:17 GMT

Can you share any more details around the rich tag issues you are seeing, I did a quick test in the TMPro Demo scene changing the Say Story Text to "{b}Say {i}with{/i}{/b} TM{color=red}Pro{/color}" seemed to display as it should.

soulkarl
Tue, 17 Sep 2019 21:20:26 GMT

So I did some testing for this Steve and while it does not work in my copy (using fungus3.10.0) it DOES work the way you're describing in a fresh project using fungus 3.11.2. That said there doesn't appear to be anything in the changelog between those two that would explain this discrepancy. Here's an example of what's happening when I use both methods (tmp richtext tags and fungus richtext tags). I'll continue to experiment past this to see if I can solve this on my own though since at least this issue is rectified in a fresh install. [Fungus richtext](//muut.com/u/fungus/s1/:fungus:1Zaq:fungusrichtext.jpg.jpg)

soulkarl
Wed, 18 Sep 2019 00:05:56 GMT

On further testing I've found it IS in fact an issue with 3.10.0 (made another clean slate and installed 3.10.0 to see if the tags would work and they did not - same as in my actual project). The changelog didn't show anything directly related to this until I looked deeper into pull727 https://github.com/snozbot/fungus/pull/727 the info listed inside clearly shows that this change is what fixed it, so at the very least my issue with rich text tags is solved. (Externally in the changelog it's much more vague "#727 Support use of TMPro in Set Text, Get Text and Narrative Log Menu commands") I assume this still doesn't fix the linedrop issue (which I can screen grab if needed to illustrate the exact problem) or the text write speed issue as listed in my original post. Is there any hope of getting either of these changes implemented at some point? Thanks for the help Steve!

Steve Halliwell
Fri, 20 Sep 2019 22:10:42 GMT

RE: typing speed, I've put in a PR to correct the bug and allow for laster than 1 char pre frame.

soulkarl
Fri, 04 Oct 2019 20:35:21 GMT

Thanks Steve, could you also possibly put in a pull request for the linedrop issue as well? I realize this may be more on TMP's side of things though so if that is the case just let me know and I'll search for a solution on that end myself. Cheers!

soulkarl
Fri, 18 Oct 2019 22:15:05 GMT

Steve: I just discovered a possible solution but don't know enough about #ifs and #defines or the full inner workings of the fungus namespace to want to mess w/ it myself. But I noticed we also have problems with ProBuilder prefabs, and realized we NEVER had problems with Spine based prefabs. Sure enough at the top of the Spine scripts (above using even) we have the following: #if UNITY_2018_3 || UNITY_2019 || UNITY_2018_3_OR_NEWER #define NEW_PREFAB_SYSTEM #endif there may need to be accommodations made for the newer prefab system that I was unaware of and that could very possibly be causing the problems that stem up from fungus with this. (Also worth noting in case this ISN'T an issue: both fungus and probuilder are pretty rigid in regards to what's going on in the inspector, which is to say, both want you to use THEIR ui and tools and generally don't let you edit manually through the inspector (this is aggressive w/ probuilder). I feel like that could pos sibly be what is not playing nice with the new prefab system if that helps for looking into it at all). Cheers!

Steve Halliwell
Sun, 20 Oct 2019 08:00:04 GMT

Thanks for the info, it'll be handy. I had a look into it for a bit last week and wasn't able to reproduce the prefab errors. I'll keep poking at it.