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:
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.
Comments
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.
No problem! In one story, I have this: 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: And this is in "hide stats" I have to take out both of those (click:) macros.
***edit: I attached the archive
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: $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.
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.
Yes, it creates it; you can't manipulate $Saves at all. From the changelog:
"A few variable names in TwineScript are now controlled by the game engine, and are read-only. These are $Passages and $Saves."
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.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
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.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.
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.
I'm experiencing this also, both with goto and also when attempting to use savegame/loadgame.
Could you supply an example of where you believe the collapsing is not working correctly and the output you expected?
eg.
As it is now: 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?
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's "File"
becomes(savedgames:)'s "File"
).* Removed $Passages, replacing it with a read-only (passage:) macro which accepts a passage name (e.g.
(passage: "Crossroads")
) and returns a datamap related to that passage, withsource
,tags
andname
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:)'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, "Red", 72, "Blue")
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
orblock
, and applies one or the other to allow the opacity transition to work.)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: "initialize")
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: "initialize")
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!
So essentially, this setup will make all that whitespace: While putting them all on a single line will solve it outright: 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!
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.)
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.