Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Processing and storing a passage for later viewing (SC)

edited October 2016 in Help! with 1.x
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

  • First. Do not use the SugarCube global object in your code. It is for debugging purposes only. Properly written user code does not need it, since it would be executing within SugarCube's core module to begin with.


    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.
  • I'd suggest what Exile said. Use a temp variable to store the player's results. Swap those with the actual values when the player revisits the passage. Then replace back the actual values when the player continues.

    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.
  • All the code I wrote was written with testing as it's sole purpose and written within Google Chrome's console; which isn't inside the SugarCube context. Using the SugarCube object was unavoidable. Especially since there is no documentation for this; the console at least lets me peek at the members and quickly test.

    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.
  • Hm okay. Well. I dunno why you went about it that way and will probably not know w.o. a practical example but I can see one really simple solution: grab the output HTML from the DOM and save that for later use. Then just paste that in as needed.

    I personally would have just kept track of everything but I assume your methodology makes sense in context.
  • edited October 2016
    sssk wrote: »
    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 think you're misunderstanding what I'm talking about—or I'm misunderstanding what you're looking to do.

    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:
    <<if $job52Success>>
    /* State mutations here (via <<set>> or whatever). */
    Your minion returns with the fabled //Dewitchery Diamond//.
    <<else>>
    /* Other state mutations here. */
    Your minion returns empty handed, so you feed them to your trained attack sharks.
    <</if>>
    
    Storing the HTML text result of rendering that within some variable is not significantly different from simply silently rendering the following:
    <<if $job52Success>>
    /* State mutations here (via <<set>> or whatever). */
    <<set $jobStatus to "Your minion returns with the fabled //Dewitchery Diamond//.">>
    <<else>>
    /* Other state mutations here. */
    <<set $jobStatus to "Your minion returns empty handed, so you feed them to your trained attack sharks.">>
    <</if>>
    
    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:
    var resultHtml = $(document.createElement('div'))
    	.wiki(Story.get(resultPassageTitle).processText())
    	.get(0)
    	.innerHTML;
    
  • I think you're misunderstanding what I'm talking about—or I'm misunderstanding what you're looking to do.

    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

Sign In or Register to comment.