SugarCube Widget Wierdness

Claretta · February 2015

Getting some oddities with SugarCube widgets where they randomly break. This:

<<widget "hangar">> <<set $hangaropen to random(4)>> <<if $hangaropen is 0>><audio src="hangar1.wav" autoplay></audio><</if>> <<if $hangaropen is 1>><audio src="hangar2.wav" autoplay></audio><</if>> <<if $hangaropen is 2>><audio src="hangar3.wav" autoplay></audio><</if>> <<if $hangaropen is 3>><audio src="hangar4.wav" autoplay></audio><</if>> <<if $hangaropen is 4>><audio src="hangar5.wav" autoplay></audio><</if>> <</widget>>

When I put in <<silently>><<hanger>></silently>> Produced the message Error: <<silently>>: error within contents (Error: macro <<hangar>> does not exist)

This works (only difference is I removed the quote marks from the widget name):

<<widget hangar>> <<set $hangaropen to random(4)>> <<if $hangaropen is 0>><audio src="hangar1.wav" autoplay></audio><</if>> <<if $hangaropen is 1>><audio src="hangar2.wav" autoplay></audio><</if>> <<if $hangaropen is 2>><audio src="hangar3.wav" autoplay></audio><</if>> <<if $hangaropen is 3>><audio src="hangar4.wav" autoplay></audio><</if>> <<if $hangaropen is 4>><audio src="hangar5.wav" autoplay></audio><</if>> <</widget>>

Then I put in the quote marks again, reloaded my story, and the first one worked and produced no error message, arrrgh. :P

So I'm afraid of widgets just breaking randomly.

These widgets are kept in a <<silently>> tag in the passages since they produce no text. The silent tag is also referenced in the error message. I don't know if that changes anything. It's difficult to test due to the random breakage.

Though this is the only widget that is giving me such weirdness. I have tons of widgets in my game and this is the only one that breaks, which makes it even more perplexing. All my other sound widgets have not broken on me.

TheMadExile · February 2015

I assume you are putting all of your widgets in a passage tagged with widget. Correct?

Anyway, without a live example of the issue, the only thing I can do is guess. If all you did was remove the quotes (and it started working) and added them back (and it continued working), then one of your original quotes may have been a typographic quote (i.e. curly quote) or you had a non-printable mixed in, which was deleted with the original quotes. /shrug

PS: You're processing $hangaropen more often than you need to for what you're doing there. As a suggestion, look into using <<elseif>>. For example:

<<widget "hangar">> <<set $hangaropen to random(4)>> <<if $hangaropen is 0>> <audio src="hangar1.wav" autoplay></audio> <<elseif $hangaropen is 1>> <audio src="hangar2.wav" autoplay></audio> <<elseif $hangaropen is 2>> <audio src="hangar3.wav" autoplay></audio> <<elseif $hangaropen is 3>> <audio src="hangar4.wav" autoplay></audio> <<elseif $hangaropen is 4>> <audio src="hangar5.wav" autoplay></audio> <</if>> <</widget>>

n.b. Since you're throwing the output of the widget away, and the extraneous whitespace won't be an issue, I went for maximum readability there.

Claretta · February 2015

I have no idea what's going on with that widget. After I removed it, it worked for one story load. Then I didn't touch a single thing, and came back to my story later, then got the error message again.

I concluded that the widget is haunted and have just put the whole thing in the relevant passages.

The only possible thing I can think of is I didn't make that widget from scratch. It was formerly named "click", then I changed the sound effect, so renamed it hanger. Then the weirdness started. So maybe something with browser memory is going on and Twine for some reason wants to keep reading it as "click".

Thanks for the tip about elseif. As I learn more stuff I'll keep optimizing my code.

TheMadExile · February 2015

Claretta wrote:

I have no idea what's going on with that widget. After I removed it, it worked for one story load. Then I didn't touch a single thing, and came back to my story later, then got the error message again.

I concluded that the widget is haunted and have just put the whole thing in the relevant passages.

That's a little extreme, but. /shrug

Claretta wrote:

The only possible thing I can think of is I didn't make that widget from scratch. It was formerly named "click", then I changed the sound effect, so renamed it hanger. Then the weirdness started. So maybe something with browser memory is going on and Twine for some reason wants to keep reading it as "click".

Hmm. It shouldn't have worked with the name click at allthe built-in <<click>> macro should have seen to that as <<widget>> should absolutely refuse to clobber existing macros. Do you have some scripting that is modifying SugarCube or something? Not that I'm saying you shouldn't, it's just that I can't think of another reason why trying to use click as the name of a widget didn't make <<widget>> throw an error.

Actually, that makes me think of something else. Did your ever add SugarCube to Twine 2 manually (via the Formats menu in its sidebar) or was your first time using it after it was made one of the built-in story format choices? Also, your version does identify itself as v1.0.16, yes?

Claretta · February 2015

I have no answer to that first question. I seem to remember it as "click" but I could have got that wrong in my post and had it as openclick or something, since I'm not using any scripts that modify SugarCube in that way.

Yeah, using 1.016, it was included in 2.0 at the time I downloaded Twine.

TheMadExile · February 2015

Okay. Just wanted to make sure it wasn't some weird manually installed vs. built-in snafu going on.

Oh, BTW. While I do encourage quoting the names of your widgets in the call to <<widget>>, as long as you limit yourself to a simple word, basically, you don't actually have to. For example, the following two invocations are equivalent:

<<widget "dothething">> [] <</widget>> <<widget dothething>> [] <</widget>>

So, if you run into a similar issue in the future, where dropping the quotes fixes your widget, feel free to just leave them off. Just don't start dropping quotes everywhere.

Claretta · February 2015

I don't know, I'm running into a whole heap of weird problems and it's not just related to widgets.

I've set it up so that it plays a certain sound unless I have the tag "notyping" in the passage, with:

prerender["autotypingsounds"] = function (content, task) { new Wikifier(content, "<<typing>>"); };

and

<<widget "typing">><<silently>> <<if tags().indexOf("notyping") === -1>> <<set $typing to random(3)>> <<if $typing is 0>><audio src="typing1.wav" autoplay></audio><</if>> <<if $typing is 1>><audio src="typing2.wav" autoplay></audio><</if>> <<if $typing is 2>><audio src="typing3.wav" autoplay></audio><</if>> <<if $typing is 3>><audio src="typing4.wav" autoplay></audio><</if>> <</if>><</silently>><</widget>>

This works for every passage except one, that seems to completely ignore the tags feature, which will keep playing a sound even with that tag.

And the ultra weird thing is even if I tell that passage to play another sound by referencing another widget, it refuses to and will just play the typing sound, while not throwing up an error message for the widget it's not recognising. It's like it's not remembering the correct information in the passage and is defaulting to an older version that's stuck in memory somewhere.

Then when I changed the passage to include the raw html reference to the new sound I wanted playing, suddenly the notyping tag started working again.

At this stage the best idea I have is to wipe my browser's memory after saving backups and reinstall twine and my story.

TheMadExile · February 2015

Claretta wrote:

This works for every passage except one, that seems to completely ignore the tags feature, which will keep playing a sound even with that tag.

If you start playing an audio clip, navigating to a new passage will not automatically terminate/stop the clip. Your shown code only ensures that a new clip isn't started (and yes, you can have multiple instances of the same clip all playing at once), it does not stop playing clips.

Claretta wrote:

And the ultra weird thing is even if I tell that passage to play another sound by referencing another widget, it refuses to and will just play the typing sound, while not throwing up an error message for the widget it's not recognising. It's like it's not remembering the correct information in the passage and is defaulting to an older version that's stuck in memory somewhere.

Then when I changed the passage to include the raw html reference to the new sound I wanted playing, suddenly the notyping tag started working again.

That's probably caused by how you're playing the audio clips. At least with the code you've shown, your rendering the <audio> element outside of the DOM and then throwing away all references you have to the element, so it's sitting in limbo just playing away.

Claretta · February 2015

TheMadExile wrote:

If you start playing an audio clip, navigating to a new passage will not automatically terminate/stop the clip. Your shown code only ensures that a new clip isn't started (and yes, you can have multiple instances of the same clip all playing at once), it does not stop playing clips.

Well, it's working 99.99% of the time (I have heaps of passages), so I don't know why the exception is occurring. If I was doing something seriously wrong I'd see the problem occurring more than that?

I might just switch to putting the raw html audio call in every passage without any widgets, just to be safe.

Claretta · February 2015

I cleared all my browser memory, upgraded to Twine 2.03, then imported my story from a backup, and all the problems mysteriously disappeared.

Howdy, Stranger!

Categories

SugarCube Widget Wierdness

Comments