Just wanted to report a bug I've found with nested font tags. I have a screenshot of the effect below with the text that leads to it. If you open one font tag inside another then close the inner font tag, the display font returns to default rather than respecting the font of the enclosing tag.

Let me know if any additional details would be helpful! ^^

<f=Retron2000Regular>Gombön is here to <e=bleepOpen><f=Helpers>fuck</f><e=bleepClose><e=excl=open> you up, baby!<e=excl=close></f>

Hey!

This is the current intended behaviour, a new tag will always override the state of an old one, so you'd want "<f=baseFont>1<f=newFont>2<f=baseFont>3" for this. I could add this as alternate behaviour in a future update maybe? I feel there was some reason I was avoiding it (I suppose it was because I didn't like the idea of needing closing tags, but I could still make that optional...? Or that this system technically runs faster since I never need to check which tag is closing, just override it with a null value), but with recent backend updates, it might not be that bad to add in now.

Ahh, I. gotcha! It's not a huge deal for me either way, as I can code around it. I do feel like it might be clearer to eliminate the font close tag entirely if it simply acts as a font change tag. Otherwise I would prefer itpushing/pulling to a stack as the tags open and close though, which would act more like I had initially anticipated.

Thanks for the quick response! ^^

Well, with the current way it works, the closing tag means that *any* closing tag (not just fonts) will return to the default setting for that tag, which has its own uses! (But there is the <clear> tag already for clearing everything to default I suppose...) I guess I think of them more like programming the text as it's read out, rather than formatting existing text? I think I wrote a bit about this system int he docs, but I could make it a bit clearer. Anyway, should all still be workable!

Huh! Ok, that is really good to know! If I just started treating the opening tags as state changers and didn't bother to close them at all, would that lead to problems on my end? I'm not sure whether unclosed tags lead to any kind of unexpected issues on STM's side.

Unclosed tags will not lead to any issues with how STM currently works, and if I were to add this tag stacking change I would also not require tag closing! As it stands, when text parses, it just goes forwards, not backwards.

(There's some benefits to the current system by the way... color tags of a different type can stack (color, gradient, texture) but now that I've got the combo color tag (<c=myColor,MyGradient,myTexture) and customizable color-mixing rules for color data, adding an alternate tag parsing system could be interesting...)