Using SugarCube 2.10.0 with tweego.
So I have a passage that is dynamic; it has branching and affects story variables.
I would like to trigger this passage behind the scenes and being able to display it a number of times.
My current scenario involves sending a hireling to do a job, and having the option to view the job result right after it is completed, or at the end of the week; like a recap.
Obviously just storing the result passage title and re-playing it would not work; the user would see a different outcome each time. Also pressing F5 would essentially repeat the result.
So I've looked into this and the only path I've come across is the undocumented
Wikifier
object. I've seen it used in macros, but since it is undocumented I can't help but wonder if there is proper, documented, method of doing the equivalent to this:
This strips formatting. This is not ideal.
var fragment = SugarCube.Wikifier.wikifyEval(SugarCube.Story.get(resultPassageTitle).processText());
var resultText = fragment.textContent;
So it requires a macro context (not tested). But I can't persist the DocumentFragment as-is between states.
handler : function () {
let fragment = this.args[0];
this.output.appendChild(fragment.cloneNode(true));
}
So my current solution is to mix both approaches; getting the fragment, putting it in an htmlelement and getting the innerHTML. Essentially converting the Node to an HTMLElement to HTML code:
let div = document.createElement('div');
let fragment = SugarCube.Wikifier.wikifyEval(SugarCube.Story.get(resultPassageTitle).processText());
div.appendChild(fragment .cloneNode(true));
var resultHtml = div.innerHTML
I'dd love to get some input on how to solve this problematic.
Comments
Moving on. How complicated are your results going to be? If they're not hugely complicated, you could simply store the result within a story variable for later printing.
To simplify this, store the variables relevant to this scene in one object and just swap the object back and forth with a temp variable. That way you don't have to (re)set them all individually.
Unless you're doing something highly complicated, this will allow you to reuse the passage and have it act as though the 'old' values were still set. To avoid the player 'replaying' events, just set another variable that signifies that the player is revisiting the passage, and then adjust the links to take the player back to where they were.
Anyway,
No it's not possible to revive the passage, I have around 25-30 different result passages with different structures. Such as the hireling finding a treasure containing a randomly chosen item, or the hireling finding nothing, or getting attacked, or getting robbed. I'dd have to keep track of everything, which would be complicated and not flexible.
And namely I want to store the flavor text, the functional results would be applied to the game state and discarded. Approaching "store the text" with a "store the result" solution would be anti-pragmatic.
I personally would have just kept track of everything but I assume your methodology makes sense in context.
Rendering the passage, converting the node graph into HTML text, and storing that for, possibly later, use is not significantly different from what I had in mind. As another snag of your current method, converting the node graph into HTML text will break all links and other interactive elements.
For example, imagine that this is one of the passages we're talking about: Storing the HTML text result of rendering that within some variable is not significantly different from simply silently rendering the following: In both cases you're storing the flavor text you wish to be able to display to the player, either at render time or deferred until the player is ready. The latter is actually a bit more flexible as you can choose when to evaluate any expressions contained within the flavor text markup, whereas the former forces immediate evaluation of all parts of the flavor text markup.
EDIT:
Regardless. If you're determined to store an HTML conversion of the rendered node graph—which will break links and interactive elements—then I'd suggest using the, documented, <jQuery>.wiki() extension method.
For example, you might do something like the following:
I was referring to MoLoLu's idea of storing individual results and plugging them back into the passage when it was displayed.
Using the jQuery method works out, as long as HTML elements (break line, coloring, etc) are preserved, it is an acceptable compromise to lose interactive elements. And the nature of these are more akin to status updates, so I wouldn't need any interaction within.
I am happy to be using an exposed and documented method instead of the Wikifier.
Thanks