Click and Live Macro Compatibility - possible bug

Issue #100 resolved
Doron Kipper
created an issue

Using the example from the Harlowe manual, the (click:) macro seems to stop working when in the same passage as the (live:) macro:


There is a small dish of water. (click: "dish")[Your finger gets wet.]

Does not work (clicking dish does nothing):

There is a small dish of water. (click: "dish")[Your finger gets wet.]

(live: 0.5ms)[(if: $variableA is "Happy")[I'm happy!]]

I'm using Twine 2.1.3 on Mac OS Sierra. Harlow 2.0.1

Comments (5)

  1. greyelf

    The (live:) macro creates a timer thread which will continuously trigger an event every X milliseconds until either it is stopped via the (stop:) macro or a passage traversal occurs, and a millisecond is 1000th of a second.

    Each time the event triggers it will temporary interrupt the user's ability to interact with the page, for example via a mouse click.

    In your example you have assign a value of 0.5ms, which is one 2000th of a second, this means that the related event will roughly trigger 2000 times each second thus leaving almost no time for the user to interact with the page.

    If you change the value to something like 500ms (1/2 a second) you will see that your code example actually works.

  2. Doron Kipper reporter

    I previously used code like this, and the refresh rate didn't seem to hinder continued clicking of the choices:

    Choose your gender: \
        (link-repeat: "Female")[(set: $player2gender to "Female")] or \
        (link-repeat: "Male")[(set: $player2gender to "Male")]
            (if: $player2gender is not 0)[\
                (stop:)(transition: "dissolve")[\
                    Selected Gender: (live:0.5ms)[$player2gender]\
  3. greyelf

    The (link:) related macros and the (click:) macro work differently:

    (link:) inserts the related HTML elements (and Javascript code) into the DOM at the time it is processed and then does nothing more until it is selected.

    (click:) waits until the entire contents of the passage has been process then scans the entire generated output looking for either the text or hook to attach to. This allows the (click:) macro to be placed before the indicated text or hook it references is processed in the content.

    If you use your web-browser's Developer Tools to Inspect the output of each of your examples (one at a time) you will notice that in the case of the (link:) macro example only the HTML elements related to the (live:) macro are being contently refreshed. (contently due to the shortness of your delay value)

    Where as if you inspect your (click:) example's elements you will notice that the tw-passage element and all it's children are being contently refreshed. I'm guessing that this is due to (click:) being a post process/effect, and that it's related scan is being triggered repeatable. (in this case 2000 times a second.)

  4. Log in to comment