[Sugarcube] Not re-executing contents when going back

Zebradontcare

Hi all,

So I've had a pretty easy time figuring out Sugarcube on my own and am well on my way to making a fairly complex text adventure. The messages others have posted here have been extremely helpful. One thing is eluding me though. On several of my passages, there are a few widgets I've defined that have a certain chance to fire a random event or track something in the background like the passage of time. Those widgets are all working well.

However, on some passages, I have some text that is clickable that is only meant to give a short description. For example, the first time a character is introduced, their name is a link to a passage that gives a short description of them with a <<back>> widget at the bottom. Whenever the player clicks the back button, the widgets on the previous page all execute again, meaning, for example, that time passes twice if you click on a character's description. This is pretty obviously undesirable.

Any ideas as to how I can get these short descriptions in without rerunning all the widgets at the top of the page? Thanks!

TheMadExile

Assuming I've understood your issue. The problem is that the <<back>> macro undoes the history, so using it is like going to the passage original passage the first time.

Since you mentioned randomness. If the issue is only with your use of randomness within the widgets, then the problem is because the default PRNG's state is not synchronized with the story history. An easy solution would simply be to enable the seedable PRNG, which is synchronized with the story history. For example: (goes in Story JavaScript)

State.initPRNG();

If that's not the specific issue, let me know.

Zebradontcare

Unfortunately, it's not just the randomness, though enabling seedable PRNG would be useful with what I'm doing in the game. One of the widgets I commonly use is just counting things behind the scenes. So every time it gets used, it advances a few variables forward by one, checks to see how long it's been since the player has performed certain actions, etc.

So when the player hits back, those counters are getting moved forward again, which is undesirable. Basically, what I'm wondering is if there's a way to execute those widgets when the passage loads but not when the player comes back to the passage from a description.

Now that I'm looking at it again today, I'm pretty sure I solved my problem. I tagged description passages with the tag "description" and wrapped my widgets in an if statement to check if the previous passage's tag was "description." If it is, it doesn't execute the contents.

See any pitfalls here?

greyelf

@Zebradontcare
I was wondering if you can explain what you are doing in your widgets that is causing your counters to move forward a second time after returning to a passage via a <<back>> macro.

I tried the following and that did not happen to me. (note: using TWEE notation)

:: StoryInit
<<set $counter to 0>>

:: Widgets [widget]
<<widget "increment">>
<<set $counter += 1>>
<</widget>>

:: First
<<increment>>
counter: $counter
[[Second]]

:: Second
counter: $counter
<<back>>

... the counter equalled one when I viewed the First passage both before navigating to Second and after returning to First from Second via the <<back>> macro.

Zebradontcare

@greyelf The widget that was firing for sure was one that checks the player's health and, if it's below a certain point, gives a random chance to have a coughing fit. It's nested inside a <<silently>> tag at the top of the page. I can test it again if you like.

TheMadExile

Zebradontcare wrote: »

Unfortunately, it's not just the randomness, though enabling seedable PRNG would be useful with what I'm doing in the game. One of the widgets I commonly use is just counting things behind the scenes. So every time it gets used, it advances a few variables forward by one, checks to see how long it's been since the player has performed certain actions, etc.

So when the player hits back, those counters are getting moved forward again, which is undesirable. Basically, what I'm wondering is if there's a way to execute those widgets when the passage loads but not when the player comes back to the passage from a description.

The widget is invoked again, yes—I mean, obviously, the passage was played again, so any macro/widget invocations it makes are played again. That said, if you inspect your story variables, you should find that, as greyelf mentioned, their values are exactly as they should be at that point—they are not getting increased more than they should be by visiting the passage in question just once.

For example, say $count is 5 when the player enters the passage, then the widget increments it to 6 as part of playing the passage. Then they move on to the description passage, finally clicking <<back>>. What happens is that the history is rewound by <<back>>, so that it's like the player has just arrived for the first time. In other words, $count will be 5 again and will be incremented by the widget to 6 again. So, while the passage is replayed, the outcome should be exactly as it was the first time.

The only way that the values of your variables should differ is if you're using something whose state is external to the story state to set them—e.g. unsynchronized randomness.

Now, that only covers the state of the system. If your complaint is simply that the passage is replayed in full, including the invocation of its macros/widgets, then that's simply how the system works. You'd have to gate off either the widget's invocations or, likely easier, their contents.

Zebradontcare wrote: »

Now that I'm looking at it again today, I'm pretty sure I solved my problem. I tagged description passages with the tag "description" and wrapped my widgets in an if statement to check if the previous passage's tag was "description." If it is, it doesn't execute the contents.

See any pitfalls here?

If you're using <<back>>, then that should not work, since it rewinds the history—i.e. the previous passage at that point should be the one before the current passage, not the description passage.

To make it work, you'd need to use <<return>> instead, which does not rewind the history. And in that case, as long as there's no way to go to another passage while viewing a description, thereby making the previous passage not a "description" passage, then that should work.

Zebradontcare

Right, I failed to mention that when I started tagging description passages I also switched to <<return>>. Thanks for your help!