StoryInit passage caching?

[Lavorther]

When modifying passages, I can always just refresh the game in my browser (after recompiling) to see the changes immediately. However, any changes I make to the StoryInit passage seem to be completely ignored until I close the compiled game's tab and/or the browser, and reopen it again. Only then does it seem to register for example a different value in a set macro.

Tested this in Chrome, using both the normal and testmode of the story, as well as the web version of Twine and Tweego. The behavior is the same using all of those variants.

From my testing this seems to only affect the StoryInit passage. Normal passages, JS code and CSS all get changed instantly when I refresh the compiled game's page. It's not a huge issue for finished games, but it is getting annoying to have to close and reopen my game every time I need to test a change to the StoryInit passage.

[Lavorther]

Turns out, using the Restart button to reset the game does in fact apply the new StoryInit passage properly, so this only happens when reloading the page manually, which kind of makes sense I guess.

[ChapelR]

StoryInit is run in both cases, but any changes to the state (e.g. variables) will be completely overwritten by the incoming state being reloaded from session storage when you refresh. It functionally has the same effect as loading a saved game.

[Jaydax1729]

If you have a large game with multiple passages then it's inconvenient to have to run through the game to test an alteration to a later passage. The answer is to test the game in debug mode and periodically turn on test mode then 'Watch' then 'watch all'. You can then drag across the entire list of variables and copy it into a text editor. I sort it alphabetically to make it easier to find items, edit it to start each line with <<set , insert the missing ' to ', add >> at the line end. All easy using my chosen tex editor (EditPlus). I then then create a new passage called 'setvariables[id]'. Into this I paste the variables and add a goto to the relevant entry point. I make an entry point passage with links such as <<link "West from courtyard with dynamite" "setvariables06">><> This seems to cope quite well, the only drawback being that visited() will not show the correct number of times a passage has been visited.

[tmedwards]

StoryInit is run in both cases, but any changes to the state (e.g. variables) will be completely overwritten by the incoming state being reloaded from session storage when you refresh. It functionally has the same effect as loading a saved game.

^ That. If you simply reload the page, then the current playthrough session is restored. This serves to (a) keep players from accidentally blowing away their playthrough by reloading the page, either intentionally or accidentally, and (b) allow games/stories to work on mobile browsers at all, as mobile operating systems commonly sleep/suspend applications, which in the case of browsers does not preserve their current state.

Using SugarCube's restart functionality clears the current playthrough session in addition to reloading the page, so you start a fresh playthrough.

[ChapelR]

You can also fix the data with the console. Say you add <<set $items to {}>> to StoryInit, you can "fix" your save by typing SugarCube.State.variables.items = {} in the console.

For massive changes, you'll need to either plan ahead to avoid such changes, create actual save patch code using Config.saves.onLoad(), or just restart and replay. You can also create your own debugging features that let you jump around within the game.