Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

[Solved] <e> ignored if immediately after <e><pause>

A topic by mrtenda created Sep 20, 2018 Views: 66 Replies: 2
Viewing posts 1 to 3
(3 edits)

Hey, just upgraded to 1.8.1 and it's working great so far! There is one small regression from 1.7 involving the <e> and <pause> tags though that I thought I'd bring to your attention as it's probably worth fixing. It seems that now that if you surround a <pause> tag by two <e> tags, the <e> tag after the <pause> is ignored when the text resumes after calling Continue().

For example, when I feed this string into STM, "event1" is correctly received as a custom event as expected, but "event2" is never received after Continue() is called (though "TestB" is printed):


In STM 1.7, both event1 and event2 would be received. For now, I've managed to manually work around this in STM 1.8.1 by inserting a zero-width character between the <pause> and second <e> tag, so it's not really a pressing bug for me, but it still seems like something that'd be worth fixing in the future.

Also, someting unrelated: it looks like the "Events" foldout in STM's inspector has the "CustomEvent" field mistakenly displayed twice. I took a peek at STM's source code and I think a duplicated line of code here is the cause:

EditorGUILayout.PropertyField(serializedObject.FindProperty("customEvent"));     // customEvent #1
EditorGUILayout.PropertyField(serializedObject.FindProperty("customEvent"));     // customEvent #2 (remove this??)


Nice catch with the duplicated custom event, deleted that now.

Yeah, this but with the event isn't supposed to happen... I'll take a look and see what changed between the two versions. In v1.8 I fixed a bug where the first event/sound played by a mesh would ignore an initial delay, so it might be related to that part of the code. SInce it worked in the past, I'll be able to look at older code and get it running again!

I'll admit I have a bit of a queue of things to fix right now, but I'll keep you updated for when I've fixed the bug!

Developer (1 edit)

Update for transparency's sake: This should be solved in 1.8.2!

Essentially, <e><pause><e> actually ends up sticking two events on the same character, and both were being skipped. So now, as STM already does when an event is alone at the end of a string, it adds a zero-width space to hold the event on.