Has anyone else encountered what looks like a bug where sometimes, for no apparent reason, an attribute that should be set to the value of another attribute in fact get set simply to 'true'?

I've encountered this in several different scenarios:

• when using a textfield to allow the user to input something (eg a name) - most of the time this is set correctly, but sometimes it's just set as 'true' and the player's name is then 'true'; for the rest of the game
• when setting an attribute to the value of another attribute, eg {@charname=@ridersname}

This might be a Firefox-only bug, though I can't confirm it. And it doesn't always happen - perhaps 1% of the time - but I can't find any common denominator (though the {@attribute1=@attribute2} syntax may be a common factor !

Hmm… I notice that undefined values are translated into true by the set method. So it's possible that if your @attribute2 hasn't been set yet, it would be treated as true. (I believe this behaviour is to enable the @set attribute and @set not attribute functions to act as true and false – setting an attribute to an unspecified value makes it true)

If the value is set, I wonder if there's some kind of race condition in some browsers… if values in LocalStorage are being queued before being saved to disk, then I don't know if loading them should block. In any case, the implementation of get and set seems to be a little awkward… it might be more efficient to fetch the attributes from local storage only the first time they are needed, and then keep them in memory.

I don't think this is likely to be a problem, but I can imagine it being possible as an edge case.

Here's a first guess off the top of my head for how a possibly-more-efficient implementation might work. (replacing two of the existing JS functions… I think this would have to be implemented by modifying squiffy.template.js or story.js, and it might not work as intended if changed from within game code)

    squiffy.set = function(attribute, value) {
        if (typeof value === 'undefined') value = true;
        value = JSON.stringify(value);
        if (!squiffy.storageFallback[attribute] === value) {
            squiffy.storageFallback[attribute] = value;
            if (squiffy.ui.settings.persist && window.localStorage) {
                localStorage.setItem(squiffy.story.id + '-' + attribute, value);
            }
            squiffy.ui.settings.onSet(attribute, value);
        }
    };

    squiffy.get = function(attribute) {
        var result;
        if (squiffy.storageFallback.hasOwnProperty(attribute)) {
            result = squiffy.storageFallback[attribute];
        } else if (squiffy.ui.settings.persist && window.localStorage) {
            result = localStorage.getItem(squiffy.story.id + '-' + attribute);
        }
        if (!result) return null;
        return JSON.parse(result);
    };

(and in squiffy.story.restart, remove the else { and } surrounding the line squiffy.storageFallback = {};)

Thanks mrangel - I'm going to see if this solves it!

I'm not sure if I have one bug or two - the one that results in attributes being set as 'true' when they should take on a value provided by the user is obvious because it occasionally results in their character's name, which gets amended towards the end of the story, being changed to 'true'. It's rare, but we've had perhaps twenty in 1200 playthroughs.

The other one (or possibly same one, if that one is caused by the same thing) sometimes seems to introduce this lag where atrributes aren't updated straightaway, but a couple of sections later. Which does sound like it could be the same thing, if it's the case with the first bug that @attribute2 isn't being updated immediately. Though I've never seen a 'true' later update to what it should have been!

Anyway, I shall report back!

Hmm, that seems to have broken my staging version! https://www.dragonchoice.com/you-choose/game-dev/

It was a quick bit of code off the top of my head, so entirely possible I've got a mistake in there somewhere.

Trying to debug it through the JS console; but not sure what's going on now.
It seems that it's failing at some point in the initialise interface script… if I go to the JS console and enter squiffy.story.go("Start"), it seems to behave (and to save properly, resuming when played again).

I can only assume there's some conflict between the function-replacement at the start and the new get/set methods… I'll take a look into that when I've got a little more time.

Just a bit of extra data gleaned from talking to some of the people playing the game and encountering some of these issues!

The name attribute being set to 'true' when it should be set to whatever name the player inputs increasingly looks like a Firefox-specific issue - perhaps soemthing about how its LocalStorage is configured? One player said that happened for them on every run until she cleared cookies, and then it was OK. Does Squiffy even set any cookies, or does the cookie clearing process simply also clear down LocalStorage?

The 'lag' issue doesn't seem to be Firefox-only, however - that's happened on Chrome and on mobile browsers too.

I've seen some strange things in Firefox in squiffy. Nothing that I could pin down but yes, stuff that otherwise makes no sense.

Hi all, I've only been using Squiffy a few days but I've already run into a problem that seems similar to what the OP posted and it's breaking my brain. I've added lots of diagnostics and I think I've narrowed the problem down a bit but not sure exactly why it is occurring or how to fix it. mrangel's suggestion earlier in the thread that it might be a browser race condition seems plausible at this point.

The following isn't my actual code - it's pseudo-code that will hopefully illuminate the problem I'm having very clearly:

@set not Attr //initialise attribute
...
...
...
[[Section A]]:
Diagnostic 1: {Attr} // reports (correctly) Attr = false
Call [[Section B]]

[[Section B]]:
Diagnostic 2: {Attr} // reports Attr = true - it should still be false!
...
...
...
Diagnostic 3: {Attr} // reports Attr = true - ditto
{if not Attr:Hello}{else:Goodbye} // prints "Goodbye"
@set Attr
Diagnostic 4: {Attr} // reports Attr = true - correct

If I comment out the @set between Diagnostic 3 and Diagnostic 4, then Diagnostics 2-4 all report Attr = false and "Hello" gets printed.

So, it looks like that @set is being executed BEFORE the if, rather than after. So, again, Maybe mrangel's hypothesis about the race condition is correct. I'm using the Brave browser by the way.

I'd prefer not to get into heavy JS if possible, as I'm not a JS guy - would probably prefer to modify my game so as to dodge the problem.

Incidentally, I've tried using both numerical and string attributes in place of Boolean, but with analogous results.

And there aren't any references to Attr that I have forgotten or misspelled - I've used the editor's Find function to check this.

One last thing: all my other attributes seem to be working fine.

Any help on this appreciated...

Might be something silly - trust me, I've been fussing with squiffy all day.

Double click on your variable name and make sure it highlights on the other places it's used. You might have a tiny typo (or case problem) which could be throwing off your logic. One way to be sure - copy and past from Section A to Section B to be sure it works correctly.

Also, do you have a master section (i.e. [[]])? That could be resetting it.

Really desperate? Change the variable name. Maybe you stumbled into something used internally. I seen to recall that happening a couple of years back.

Also, you aren't using // for squiffy comments, right? You need to use <> for comments.

Another thing. Make sure you aren't relaying on squiffy to execute sequentially - I believe it runs its code in passes. Try running this...

{attr}
@set attr

You would think attr should show NULL since it prints before the set. Not so. I find its much better to use this...

{attr}
{@attr}

This executes the commands in the right order. You can find a nice handout on how to use these styles of commands here...

https://dynalist.io/d/kocz1psBWP_sDFR0bk8wApfY

BINGO! This worked like a charm:

{@attr}

Thanks so much, Bluevoss, and also for the documentation link - at first glance, it looks way better than the official documentation.

I don't know if anybody is actively maintaining Squiffy, but making it execute in sequential order would seem to be a desirable improvement.

So, it looks like that @set is being executed BEFORE the if, rather than after. So, again, Maybe mrangel's hypothesis about the race condition is correct. I'm using the Brave browser by the way.

That's not a race condition.

When a squiffy file is compiled, each section (or passage) is split up into 3 parts:

1. section.attributes (all @set, @inc, @clear, and similar instructions)
2. section.js (all javascript)
3. section.text (everything else, including {command} sections).

Each of those parts is interpreted according to different rules, and they are executed strictly in that order.

Woops. I mean a "rare" condition. This is what I get for typing and not checking. You'd think I'd learn after all the bugs I put into my code yesterday.

Holden Meursault : I had to force myself to do a lot of my code in JS because if I used @set ANYWHERE in a section, it set it all over the section. These {@} commands work a lot better, including allowing you to check variables against other variables, which is very handy. Glad you liked it - lots of very good information there.