Howdy, Stranger!

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

Beta version of Harlowe 1.1

LL
edited April 2015 in Help! with 2.0
This is an offline HTML version of Twine 2.0.3 which contains a beta release of the next Harlowe version.

A rough pick of notable new features (described in detail here):

* Twine 1's StoryInit feature is now available by giving a passage (or multiple passages) the tag 'startup', and a variant which works only in Debug Mode can be used with 'debug-startup'.
* More importantly, though, is that you can declare a "header" or "footer" for every passage by using the tag 'header' or 'footer'. These can contain displayed text (like a special HUD, etc.) but more likely it will be used to hold prerender/postrender code, such as (replace:) macros that can selectively alter the text of every passage in the story.
* (savegame:) and (loadgame:). Basic usage: (save-game:"File A") saves the game under the name of "File A" and (load-game:"File A") restores it. For the moment, though, they can't be used if your game's variables contain complex values (such as changer commands, etc.)
* $Saves, a special datamap that Harlowe controls, which contains the names of existing savefiles. To check if a save named "File A" exists, check if $Saves contains "File A".
* $Passages, another special datamap, which contains data for existing passages. See if a passage exists with $Passages contains "Bakery", check a passage's tags array with $Passages's tags, or its source code with $Passages's source. You can dynamically add passages at runtime by doing (set: $Passages's "New Passage" to (datamap: "source", "My passage's ''code''", "tags", (a:"tag-1","tag-2"))).
* The preliminary return of escaping line breaks with \, as seen in Twine 1. I'm wondering whether the \ symbol is really the best, though... it's brief, but still a little ugly.
* Various other data manipulation macros.
* Computed data access: the ability to write $SomeArray's $SomeIndex and thus retrieve the value stored in the position denoted by $SomeIndex.
* Syntax highlighting:
undefined

Things not in, but which may be in the version afterward:

* An obvious way to obtain information about the current passage. Yes, $Passages's ((history:)'s last) can be used, but it's kinda clunky. I want to replace it with another Harlowe-controlled variable called $PresentPassage, or something, but with a better name that's one word instead of two, and isn't liable to be visually confused with something else (suggestions welcome).
* $History, a replacement for (history:) that equals an array of $Passages-style datamaps rather than string names.
* $Design, a datamap that would serve to style the HTML page in a CSS-esque manner, has been junked because I think the problem would be better solved with 'footer' code, and a hypothetical (style:) macro that could be used in there.
* The (link-append:), (link-repeat:) and (link-replace:) variants of the link macro. I hesitated to put them in because my original plan called for renaming (link:) to (link-replace:) and using its name for something else - however, now I'm leaning on making a new macro called (link-reveal:) and leaving (link:) as it is.
* Other programming helpers: some kind of iteration macro like (foreach:) or (fold:), and some way of producing lambdas (still mulling over this).
* Some way of "hygienically transcluding" the (display:) macro, so that hooks, (replace:) macros inside it can't affect the outside host passage. Maybe an (embed:) macro?

Any feedback and bug reports on these changes is dearly welcome.

A note about 1.1: I've been trying to make these changes backwards-compatible, however the addition of $Passages and $Saves (and my decision not to invent another sigil just for these entities) means that any existing stories which already use those names are liable to be in trouble (as are stories which relied on bugs in the {} syntax's whitespace handling) so to that end I'm thinking of not calling it "1.1" (implying backwards-compatibility with 1.0.1) but instead using "2.0" (implying backwards-incompatibility) as required by the the SemVer standard. So, don't be surprised if 2.0 is the version that comes out.
«134

Comments

  • I'm really excited to try out some of the new macros! Unfortunately, I found a bug.

    It appears that having a (click:) macro in a passage causes the entire passage to fail to load. If I take the (click:)s out, it displays everything else as normal. If I put them back in, it shows nothing again.

    Just in case it turns out to be relevant: I'm using Chrome in Windows 7.
  • Can I ask any people that decide to use this beta version of Twine / Harlowe to clearly state this when posting new questions in new threads about this combination, so whomever answers knows that you are not using the standard Twine 2.0.3
  • InspectorCaracal wrote:

    I'm really excited to try out some of the new macros! Unfortunately, I found a bug.

    It appears that having a (click:) macro in a passage causes the entire passage to fail to load. If I take the (click:)s out, it displays everything else as normal. If I put them back in, it shows nothing again.

    Just in case it turns out to be relevant: I'm using Chrome in Windows 7.
    I'd like to see the specific (click:) invocation, please.
  • L wrote:
    I'd like to see the specific (click:) invocation, please.


    No problem! In one story, I have this:
    (click: ?brush)[(set: $dragon's health to 1)
    (goto: "Hatching 2")]
    I tried taking out the (goto:) but leaving the (click:) in case that was the problem, but it didn't change anything.

    The other story, I have the following:
    []<statlink|(replace: ?statlink)[(display: "hide stats")]
    []<stats|
    [''Relationships'']<ships|(click: ?ships)[
    No relationships yet.]
    And this is in "hide stats"
    (click: ?statlink)[
    (replace: ?statlink)[(display: "show stats")]
    (replace: ?stats)[(display: "statlist")]
    ]
    I have to take out both of those (click:) macros.
  • Can't quite verify this with just those snippets... maybe supply me a story export, if that's OK?
  • Sure, published file or archive?

    ***edit: I attached the archive
  • OK, fixed the bug - it involved having a (click:) that referenced a ?hook, while inside the {collapsing syntax}.
  • Awesome. :)

    I don't know if it's related or even the same bug, but: I took out the {} around my (click:)s (in the dragon one) so I could play through without hitting that bug, and I ran into a new bug.

    It's doing a weird thing when I use a (goto:) - either as part of a (click:) or just by itself - where it stacks or layers the new passage text with the old one. Clicking a normal passage link clears everything as expected, though sometimes it leaves a sort of "ghost" back arrow.

    (I took out all my custom CSS too, I should note.)

    ***edit: Oh yeah, I meant to also ask about (if:)s. It looks like it no longer accepts the numbers 1 and 0 as true and false, is that an intentional change?
  • (if:) requiring booleans is deliberate - this change is designed to help catch bugs of the form (if: $value is 2 or 3). This may evaluate to either true or 3, and as such it shall now raise an error instead of silently coercing the 3 to true.
  • L wrote:

    (if:) requiring booleans is deliberate - this change is designed to help catch bugs of the form (if: $value is 2 or 3). This may evaluate to either true or 3, and as such it shall now raise an error instead of silently coercing the 3 to true.

    Aha, thanks! Good to know.
  • Hey, I've noticed that if I have div tags in my passages, which I'm using for some styling effects, transitions seem to break -- while in 2.0.3, they faded in and out along with the rest of the passage, in the new version, everything just shows up instantly. (example: http://squinky.me/tentacles/) Intentional behaviour, or a bug?
  • Re: saving.

    How does (savegame:) and (load game:) get written into a story? Do you need to use a link and a hook like (link: "Save the game")[(savegame: "A", "Beneath the castle catacombs")], and a similar (load game:)? Or...?

    Also, does it create the datamap, or do I have to do that and it fills in the values?  If the latter, is it like (set: $Saves to (datamap:  "Slot name", '' ")? I'm guessing here.

    Also, not being so up on the lingo I'm unclear about the statement from the changelog "(savegame:) currently has a significant limitation: it will fail if the story's variables contain values which aren't strings, booleans, arrays, datamaps or datasets." Um, does this mean all changer macros? Sensor macros? I'm unsure about what is not a string.

    Thanks.
  • I can answer at least a couple of these for you!

    Denny wrote:
    Also, does it create the datamap, or do I have to do that and it fills in the values?

    Yes, it creates it; you can't manipulate $Saves at all. From the changelog:

    &quot;A few variable names in TwineScript are now controlled by the game engine, and are read-only. These are $Passages and $Saves.&quot;

    Denny wrote:
    Also, not being so up on the lingo I'm unclear about the statement from the changelog "(savegame:) currently has a significant limitation: it will fail if the story's variables contain values which aren't strings, booleans, arrays, datamaps or datasets." Um, does this mean all changer macros? Sensor macros? I'm unsure about what is not a string.


    This is saying that if, when you create your variable in the (set:) macro, you are using any macros besides (array:) (a:) (datamap:) or (dataset:) in the variable's contents, saving won't work.

    Although (shuffled:) and (rotated:) shouldn't break saves, since they create array-type values.

    Also, I assume that the fact that "numbers" aren't included in that list was an oversight and (set: $var to 3) isn't going to make the save/load macros fail.
  • InspectorCaracal wrote:

    This is saying that if, when you create your variable in the (set:) macro, you are using any macros besides (array:) (a:) (datamap:) or (dataset:) in the variable's contents, saving won't work.


    So, that's only if there is a changer macro in (set:)? Favorites like (link:), (click-replace:) , (mouseover:), (font:), those are all okay by themselves?

    Now how to implement the (savegame:) (loadgame:) feature?

    Thanks



  • InspectorCaracal wrote:

    I can answer at least a couple of these for you!

    Denny wrote:
    Also, does it create the datamap, or do I have to do that and it fills in the values?

    Yes, it creates it; you can't manipulate $Saves at all. From the changelog:

    &quot;A few variable names in TwineScript are now controlled by the game engine, and are read-only. These are $Passages and $Saves.&quot;

    I still feel conflicted about uisng the $ sigil for computer-controlled variables. My main concern is that if I used a different one (such as #Saves) then people would accidentally type $Saves and it wouldn't work. However, by using the sigil, I not only break backwards-compatibility in a very minor but non-obvious manner, but also muddy what the $ sigil actually means. If you have any feelings about this, please convey them now.
    InspectorCaracal wrote:

    Also, I assume that the fact that "numbers" aren't included in that list was an oversight and (set: $var to 3) isn't going to make the save/load macros fail.
    That's correct. ;_;
  • Squinky wrote:

    Hey, I've noticed that if I have div tags in my passages, which I'm using for some styling effects, transitions seem to break -- while in 2.0.3, they faded in and out along with the rest of the passage, in the new version, everything just shows up instantly. (example: http://squinky.me/tentacles/) Intentional behaviour, or a bug?
    I'll... have to investigate this further. If you could supply a simple test story file which demonstrates this in just one or two passages, that'd be great.
  • L wrote:

    If you could supply a simple test story file which demonstrates this in just one or two passages, that'd be great.


    Here ya go: http://squinky.me/silliness/divtest.html

    Note: it looks to be just webkit browsers that have this bug. Chrome and Safari both demonstrate it, but Firefox works fine.
  • L wrote:
    I still feel conflicted about uisng the $ sigil for computer-controlled variables. My main concern is that if I used a different one (such as #Saves) then people would accidentally type $Saves and it wouldn't work. However, by using the sigil, I not only break backwards-compatibility in a very minor but non-obvious manner, but also muddy what the $ sigil actually means. If you have any feelings about this, please convey them now.

    I think using a different character like # or @ is the better option. It makes it clearer that it's special and can't be used like a normal variable, which I think is more important than trying to minimize inevitable typos.
  • InspectorCaracal wrote:

    It's doing a weird thing when I use a (goto:) - either as part of a (click:) or just by itself - where it stacks or layers the new passage text with the old one. Clicking a normal passage link clears everything as expected, though sometimes it leaves a sort of "ghost" back arrow.


    I'm experiencing this also, both with goto and also when attempting to use savegame/loadgame.
  • Could you go into more detail on collapsing whitespace? I see that it says it "should be removed outright and not allowed to accumulate", yet with or without the curved brackets it still keeps whitespace.
  • Neoroman wrote:

    Could you go into more detail on collapsing whitespace? I see that it says it "should be removed outright and not allowed to accumulate", yet with or without the curved brackets it still keeps whitespace.

    Could you supply an example of where you believe the collapsing is not working correctly and the output you expected?

    eg.

    {
    this should
    be on one line
    }

    should become:

    this should be on one line
  • greyelf wrote:

    Neoroman wrote:

    Could you go into more detail on collapsing whitespace? I see that it says it "should be removed outright and not allowed to accumulate", yet with or without the curved brackets it still keeps whitespace.

    Could you supply an example of where you believe the collapsing is not working correctly and the output you expected?

    eg.

    {
    this should
    be on one line
    }

    should become:

    this should be on one line


    As it is now:
    {
    Variables out the wazoo here
    Variables
    Variables
    And more variables
    }
    Currently outputs this: http://i.gyazo.com/c95a1d7bdcff26d78f04a9ba5d83640c.png
  • Neoroman wrote:

    greyelf wrote:

    Neoroman wrote:

    Could you go into more detail on collapsing whitespace? I see that it says it "should be removed outright and not allowed to accumulate", yet with or without the curved brackets it still keeps whitespace.

    Could you supply an example of where you believe the collapsing is not working correctly and the output you expected?

    eg.

    {
    this should
    be on one line
    }

    should become:

    this should be on one line


    As it is now:
    {
    Variables out the wazoo here
    Variables
    Variables
    And more variables
    }
    Currently outputs this: http://i.gyazo.com/c95a1d7bdcff26d78f04a9ba5d83640c.png


    Has this been addressed yet? No amount of effort or experimentation has seemed to remove whitespace. Is this a bug?
  • Here's a new beta that's pretty close to release version now.

    Most notable changes:

    I decided adding/planning a new sigil this late would be a bit rash, so, still dissatisfied with the current state of $Passages and $Saves, I've removed them and added some query macros instead.

    * Removed $Saves, replacing it with a (savedgames:) macro that can be used in the same place as it (for instance, $Saves&#039;s &quot;File&quot; becomes (savedgames:)&#039;s &quot;File&quot;).
    * Removed $Passages, replacing it with a read-only (passage:) macro which accepts a passage name (e.g. (passage: &quot;Crossroads&quot;)) and returns a datamap related to that passage, with source, tags and name data. (This means that modifying passages in-game is no longer possible for now.)
    * Importantly, (passage:) with no string returns information about the current passage, as a more versatile alternative to (history:)&#039;s last.
    * Fixed several bugs with the new whitespace collapsing syntax algorithm. (Try it again if you've been having issues.)
    * Datamaps may now have numbers as data names. You may now write (datamap: 51, &quot;Red&quot;, 72, &quot;Blue&quot;) without having to change the numbers to strings. Note that this may cause user confusion if they try to add or modify a data value whose name is number 1 using the string "1". Evidently a warning of some sort should be made when this occurs.
    * Fixed the aforementioned Chrome opacity bug (albeit with some difficulty - it now "guesses" whether the element to apply a transition to should be inline-block or block, and applies one or the other to allow the opacity transition to work.)
  • L wrote:

    * Fixed several bugs with the new whitespace collapsing syntax algorithm. (Try it again if you've been having issues.)


    The (click:)s inside curly braces aren't making passages fail to load anymore, but like Neoroman above, I'm getting a big chunk of empty space. Specifically: I have a separate passages full of (set:)s for initializing variables, named "initialize". I have (display: &quot;initialize&quot;) at the top of my first passage.

    The following tests all result in a bunch of blank lines at the beginning of the passage:

    * Enclose all of the contents of "initialize" in {}
    * Enclose (display: &quot;initialize&quot;) in {} in the start passage
    * Both of the above at the same time

    The only scenario that successfully collapses the lines is to replace the (display:) with the contents of "initialize", enclosed in {}

    In some good news, (goto:) seems to be loading new passages properly now!
  • I did fail to mention that there is another fix for it. If you have your sets or other collections of code on their own line, it will count that as a new line.

    So essentially, this setup will make all that whitespace:
    {
    (set: $This)
    (set: $is)
    (set: $an)
    (set: $example)
    }
    While putting them all on a single line will solve it outright:
    {(set: $This)(set: $is)(set: $an)(set: $example)}
    A super unorganized fix especially if you have a bunch of variables and other code before your text, but a fix nonetheless. Hope whatever is causing this to happen gets a good patching.

    EDIT: Disregard my last points; the new beta version has fixed these issues. Cheers, L!
  • Fixes seem to be working great!

    I'm running into a new issue while writing/editing, though: if I have lots of text in a passage, then performance takes a hit and it takes me several seconds after typing for text to appear on the screen. This doesn't happen in regular Twine 2.0.4, so I wonder if it's to do with the syntax highlighting. Also, I notice that the syntax highlighting starts to go a bit glitchy (see attached screenshot) while typing if there's a lot of text. (It goes back to normal after not typing for a few seconds.)
  • Hi. Following the discussion here: http://twinery.org/forum/index.php/topic,2662.0.html, the following works in Twine 2.0.4 but not with the Harlowe 2.0.0 beta (it doesn't show a clickable link)(Mac, Firefox 35.0.1):
    (set: $var to "somevalue")

    (hook: $var)[This is a hook macro based hook using a variable based hook name]

    (click: ?somevalue)[clicked]
    Love the new highlighting, BTW. It makes it so much easier to figure out my coding mistakes.
  • Denny wrote:
    Love the new highlighting, BTW. It makes it so much easier to figure out my coding mistakes.


    As helpful as it is, it's a major hamper on some CPU's, it seems. My laptop almost freezes up when I hold backspace for more then 2 seconds; the response times are really bad. I hope this particular bug can be fixed some time soon.
  • Yeah, it's at the point where I have to copy/paste all my text to/from a proper text editor. :-\
Sign In or Register to comment.