I've found a little gotcha that I'm aware of when you use JS in squiffy.

Let's say you are using a randomizer to figure out where to go, in solid JS...

    set("path2",squiffy.getRndInteger(1,3));

    if (get("path2")==1){squiffy.story.go("Section 1");}
    if (get("path2")==2){squiffy.story.go("Section 2");}
    if (get("path2")==3){squiffy.story.go("Section 3");}

I suddenly had this start to crash. Forced the randomizer to go down different paths (by giving it, say, a range of (2,2)) and even that would crash from time to time. Worse, it would occasionally run the wrong section.

This baffled me until I was out on a walk and suddenly know what the reason was. Can you guess?

Answer: Some of my sections I went to ALSO reused the variable "path2". This mean that even through I was in the initial section and had jumped to Section1, Section1 might rerandomize path2. Since I think there are threads involved here, I was still in the original section. So, if this piece made path2 1, and it ran Section1, which stated by rolling rath2 to 3, suddenly you'd go into Section3. Worse, you might even randomize to something you didn't want at all.

So yes, be careful reusing variables and note that it seams that squiffy might be doing a squiffy.story.go, I think it's still in the original code until it completes.

Note that I have no solid basis for this - I certainly don't know how the internals of squiffy works. All I know is that when I changed all my path2 variable to path2X, it never failed again...

Since I think there are threads involved here, I was still in the original section.

No threads. But squiffy.story.go runs all the JS in the specified section and displays its text. So your call to squiffy.story.go finishes after the page has finished displaying.

This is exactly what else if is for. Although in this case, I'm not sure why you are using a Squiffy attribute at all. If you just used a variable:

    var path = squiffy.getRndInteger(1,3);

    if (path == 1){squiffy.story.go("Section 1");}
    if (path == 2){squiffy.story.go("Section 2");}
    if (path == 3){squiffy.story.go("Section 3");}

your code is faster, and avoids this bug.

The only reason to use squiffy.set and squiffy.get is if you are generating a number for use in the next section.
(yes, I know that's only semi-relevant. But if you use JS variables for stuff within a script, and Squiffy attributes for passing values between sections, you're less likely to run into this situation.

Depending on your structure, it may be more efficient (and no less readable) to do something like:

    squiffy.story.go(["Section 1","Section 2","Section 3"][squiffy.getRndInteger(0,2)]);

or even:

    squiffy.story.go("Section " + squiffy.getRndInteger(1,3));

This is a pretty slick trick...

squiffy.story.go(["Section 1","Section 2","Section 3"][squiffy.getRndInteger(0,2)]);

Like most squiffy users, I use JS when I have to. If squiffy came up with a couple more things I needed (like a good randomizer and a couple of other things) I'd be happy not using it at all. As it stands, all I can do is google solutions and be wary of pitfalls.

The one danger for someone like me, using JS in the editor, is that failures don't identify. You only know something is wrong. And this is why I do only a couple of JS lines at a time, carefully recompiling.

Thanks for the feedback!

The one danger for someone like me, using JS in the editor, is that failures don't identify. You only know something is wrong. And this is why I do only a couple of JS lines at a time, carefully recompiling.

I don't know about the desktop editor, but on the web JS errors are reasonably well documented. You usually have to press something (I'm used to Ctrl+Shift+J, but I've heard people saying F12 in some browsers) to view the JS errors. Sadly it doesn't give a useful line number (or gives a line number in story.js, which doesn't always look much like your original code); but it will at least tell you what the problem is.

The offline editor will tell you what the problem is, like "expected ')' ". Of course, I'm looking at a sea of nested parens. No line numbers. Compile early, compile often.