Today I’m happy to release Twine 2.4.0, which is a significant change from the 2.3 series. Release notes are here. The home page has also been updated and a new set of documentation has been released, the Twine Reference. The idea behind the reference is to document the ins and outs of the Twine app itself, whereas the Cookbook is story format centric. I see these two things as complementary.
If you notice a bug or have a concrete suggestion for an improvement, please create an issue here. But I also wanted to create a topic here for general discussion of the release.
Thanks so much for all of your hard work on this! I’ve been using the beta, and the reduction of lag on larger files is a huge lifesaver. Your continued efforts to improve this wonderful system are truly appreciated!
Congratulations on releasing the new version, what a change!
Some questions/observations
There doesn’t seem to be a way to collapse the editor toolbar, as you could previously do with Harlowe’s version. On a small screen a lot of height is lost to that bar.
There doesn’t seem to be a way to expand the editor to be wider. That was very useful on the 2.3 version for editing large HTML structures.
Those are both reasonable suggestions… in particular, I want to add a maximize option to the dialogs in the near future. But for now, no, you can’t collapse a toolbar or widen the dialogs.
Asking here, because it’s clearly not a “bug” but I don’t know if it’s intended.
The file encoding for 2.4 has changed from 2.3, in that quote marks in passage content are now escaped as " entities, whereas before they were not. Single quotes remain encoded as ' . The change increases file size, and might have some effect on file import/conversion, which is why I was wondering if it was deliberate.
Question: The tags applied to stories are stored in the <tw-storydata> element in the tags attribute. Where are the colours assigned to the story tags stored? Are they user-dependant? i.e. if a story was moved to a different user, would the colour of the tag go with it, or be set depending on the new library?
I really like 2.4.0, and I think being able to see two passages at the same time is going to be really useful. Unfortunately the limited editor size means I can’t enlarge the text enough to read it comfortably. Also, the editor being on the right hand side of the screen is the wrong side for me, because my left eye is my dominant one. I know you’re planning to work on the editor next, so I’ll just have to wait patiently for the update.
Nope, this wasn’t intentional. I think it was a side effect of upgrading the version of Lodash Twine uses (it uses escape()).
These are user preferences. I think they need to be because tags colors need to be consistent–they’ve always been with passages, and I think (a? the?) point of tag colors is to make things easier to visually spot. So if I have stories tagged “nonfiction” in my library and I’ve chosen for that tag to be red, I don’t think importing someone else’s “nonfiction” story who preferred the tag to be blue should overwrite my choice.
This issue gets at some of this, maybe–are you talking about vertical space, horizontal space, or both?
The most obvious answer that suggests itself to me is to allow people to put dialogs on the left side as a preference, but I’m not sure how to make this work. What we can take advantage of now is that we can pad the story map on its right side so that you can always reach passages while dialogs are open. The reverse isn’t true (I think) because you can put passages right up against the left side of the window, and dialogs will make them unreachable while they’re open. I hope my description makes sense–I feel like I’m not describing it that well.
Do you have any suggestions on how to make it work better for you? This kind of accessibility issue is really important to me to address.
It was a combination of both: I had to enlarge the whole app using CTRL&+ which of course made the top “editor bar” take up even more space (on a full size desktop screen if I had more than 3 tabs open at once there was no space left at all for for the actual passage text.)
Also, a separate issue was that tabs opening below pushed the topmost, first opened tab up and hid its Close button, so I couldn’t get rid of it without closing other tabs first. But that’s a minor thing, I think. Having more than one passage open at once is likely to be only an occasional thing when I want to copy code or a description from one passage to another, or check to make sure I’m really referencing the same variable and not making a similar-but-new one! (I’d often cut and paste a passage into notepad and ctrl+tab between them.)
I think the most useful setup for working for me would be to have a max of two passages open at once, with them tiled side by side so they take up the whole of the screen. You see, the main passage selection window gets less and less useful the more you start using macros for navigation, because only double-bracket notation causes the flow-arrows to be drawn, so having the passage selection window permanently take up half of the screen is a waste of screen real estate anyway. I reckon I spend 95% of every coding session with the editor open, getting either the logic, the syntax, the white space or the story text right.
– but this is only a beta, and I’d assumed that editor->max was further down the roadmap.
Would it be programmatically more simple to open a passage and then be able to split the editor, with the two panes able to display different passages? (Or is that the same thing as starting over from scratch?)
Oh, by the way: I wanted to say an especial thank you for having the “new passage” button at the top of the screen. In the 2.3.* editor, once the app had been enlarged with ctrl&+ it used to wrap to below the bottom of the app and I’d have to use temporary double-bracket notation inside an extant passage to spawn a new one. I’m looking forward to forgetting that workaround, LOL!
The downside though is that it makes archives produced by 2.3.* and 2.4 editors incompatible. This could make collaboration on projects more difficult for novice coders (like me.) I didn’t have a clue what had gone spoing - only that the project I’d opened in 2.4 suddenly couldn’t be compiled in 2.3 any more.
Happily, publishing it to a file in 2.4 and then re-importing it in 2.3 fixed the issue, but I’d be worried about continually doing that. It was an anxious half hour!
I liked the mini-menu that appeared at the bottom of the passage. It facilitated the process of testing individual passages. It is now a little more difficult to click on the general menu link.
I noticed this too. I’m not a Twine power user – just the opposite! But possibly making the editor a dialog box, if I understood you correctly, is not ideal. Could it be a child window? To me (and yes, my right eye is nearly useless), having it on the right is just weird as well as making it more difficult to read the text. Why can’t it be dragged around and resized? Clicking on what ought to be the drag bar at the top just minimizes it.
Allowing the text size to be enlarged would be lovely too.
I’m not trying to be a nag, honestly! I really appreciate your hard work on this amazing software! I’m just saying, the UI in 2.4 immediately struck me as less friendly than it was in 2.3.x. I have observed in the past that sometimes developers seem to feel a need to change things that were already just fine. That happened when the Sibelius 6 music notation software was upgraded to Sibelius 7, for instance.
Two things come to mind hearing about your workflow:
2.4 adds the ability for formats to add lines to the passage map so references in macros are visible. A format has to implement this, though, so you may not see this happen for a while.
If you find the passage map not that useful, you might be better served with a CLI tool like tweego or extwee that lets you use a text editor to work? I don’t mean this in a bad way, just that the passage map is a big reason to use Twine, and if it’s not useful at all, it may not be the best tool for your particular use case.
Fair opinion! My reasoning was that moving actions into a static toolbar makes it feasible to take action on multiple passages at once. I tried a similar hover on multiple selected passages but it felt awkward to me. If the toolbar centered itself on the selected passages, it could get lost when you scroll around. If I made the toolbar stick to the edge of the window if it was going to go offscreen, it became unclear which passages actions would affect.
Not saying this is a perfect solution either, but this was my reasoning.
Well, for one I am scared of implementing a full-fledged windowing system . I will say that the model I had in mind was less windows, more the palettes you see in tools like Photoshop or Figma that dock to the side of a window. But they do look like windows right now.
You should be able to do this either using View > Zoom In in the desktop app or your browser zoom settings. If they don’t work, that’s definitely a bug. You can also adjust the passage editor font size using preferences.
Yes, I know what you mean: I have looked at using Tweego, but as yet I’ve not found any editor which does syntax highlighting for Harlowe (I’ve found a couple for Sugarcube, but none for Harlowe.) I find that syntax highlighting helps me avoid at least some coding pratfalls!
I agree too, that the being able to see the flow of the game from passage to passage is very helpful in seeing what’s going on. (Hey, why does one of the “kitchen argument” passages link to “highway”? WTH?) I often wish that there was a way of manually drawing those arrows. They wouldn’t update with changes in the code, true (so having “user created” arrows visually distinguishable from the automatically generated ones would be good) but it would still be helpful. But that’s just wishing.
But what I was trying to say is that even if I was using the passage network map fully, you don’t use that screen to write the game. That’s what takes the time, and that’s why I’d want to be able to devote the whole of my screen to the editor. I’m sorry if it sounded dismissive: it wasn’t intended that way.
. I will say that the model I had in mind was less windows, more the palettes you see in tools like Photoshop or Figma that dock to the side of a window. But they do look like windows right now.