[SugarCube] Strange behavior on first opening html file in a browser

Comments

• TheMadExile

  September 2014

  First issue:
  You have a grave error in your initial conditional logic.

  
<<if
SaveSystem.autosaveOK
&amp;&amp; storage.getItem("saves").autosave !== null
>>\


  You're using the method SaveSystem.autosaveOK() as if it were a data property, when it's a function (see: SaveSystem.autosaveOK()).  That will return the function itself, rather than calling it, which means that bit will always evaluate to true, so you're only really testing whether storage.getItem("saves").autosave !== null.
  
  Also, if you want to check for the existence of the autosave, simply use SaveSystem.hasAuto() (see: SaveSystem.hasAuto()).
  
  TL;DR: The above code is broken and not leveraging the API fully (to be fair, .hasAuto() might be more recent than your code).  Anyway, do this instead:

  
<<if SaveSystem.autosaveOK() &amp;&amp; SaveSystem.hasAuto()>>\


  
  Second issue:
  Your big problem is how you're calling state.display() in the <<else>> clause.

  
<<else>>\
<<script>>
alert("Testing!");
state.display(state.active.variables.first);
<</script>>\
<</if>>\


  You cannot call state.display() from within a call to state.display().  The call in the "Start over" button works because it gets called long after the original call has completed, not so with the call in the <<else>> clause.
  
  The technical details are that the second/inner call to state.display() happens during the rendering of the passage by the first/outer call, which actually does work as you'd expect (the history is updated, output is generated and displayed, etc.), but once that call completes the first/outer call continues and overwrites the output of the second/inner call.  So, you're left in a position where the history updates of both the first/outer and second/inner calls have happened (you can check this), but the display updates of the first/outer call have won out in exclusion of those by the second/inner call.
  
  The fix, while a little daft, is simple, use a timeout to delay the call to state.display() until after the original call completes.
  
  TL;DR: The above code cannot work, so do this instead:

  
<<else>>\
<<script>>
setTimeout(function () {
state.display(state.active.variables.first);
}, 10);
<</script>>\
<</if>>\


  
  Third issue: (just an annoyance really)
  Your two button are snuggling together hardcore, which (IMO) looks terrible.  I'd suggest adding a space between them.  For example:

  
);
insertText(output, " ");
var restartBtn = insertElement(


  
  Putting it all together:

  
<<if SaveSystem.autosaveOK() &amp;&amp; SaveSystem.hasAuto()>>\

You have a session already in progress. Continue where you left off?
<<script>>
var resumeBtn = insertElement(
output,
"button",
"resume-button",
"ui-autostart-button",
"Resume where I left off"
);
insertText(output, " ");
var restartBtn = insertElement(
output,
"button",
"restart-button",
"ui-autostart-button",
"Start over"
);
$(resumeBtn).click(function () {
SaveSystem.loadAuto();
});
$(restartBtn).click(function () {
SaveSystem.deleteAuto();
state.display(state.active.variables.first);
});
<</script>>\
<<else>>\
<<script>>
setTimeout(function () {
state.display(state.active.variables.first);
}, 10);
<</script>>\
<</if>>\

• TheMadExile

  September 2014

  TheMadExile wrote:

  
  The technical details are that the second/inner call to state.display() happens during the rendering of the passage by the first/outer call, which actually does work as you'd expect (the history is updated, output is generated and displayed, etc.), but once that call completes the first/outer call continues and overwrites the output of the second/inner call.  So, you're left in a position where the history updates of both the first/outer and second/inner calls have happened (you can check this), but the display updates of the first/outer call have won out in exclusion of those by the second/inner call.
  

  
  
  To blather on a bit more about that topic.  Essentially, by calling state.display() within a passage, you're doing a kind of recursion.  Furthermore, because of the way that state.display() is structured, the history updates act as a FIFO, while the display updates act as a LIFO.
  
  To use pseudo-code, state.display() works like this:

  
state.display():
update history:
render passage:
update display:


  So, when you call state.display() within a rendering passage, it would look like this: (I used three calls here)

  
state.display():
update history:
render passage:
state.display():
update history:
render passage:
state.display():
update history:
render passage:
update display:
update display:
update display:


  As you can see, the history updates happen in-order of call, but the display updates happen in reverse-order.
• Erik Temple

  September 2014

  Thanks as always, TME! This Start passage is probably the oldest extant code in this project, so I'm not surprised that the autosave API has improved slightly.
  
  Your explanation is very helpful. I have made the nested display error enough times that I should have caught that on my own, but I think that the fact that the nesting allows the history to update as normal but overwrites the text output threw me off the scent. (There's also the fact that, crazily enough, the bare state.display call did at one time "work"--in the sense that the passage displayed even on the first run in a given browser--before--though I can't see why that would be.)
  
  It's all working now!