Howdy, Stranger!

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

Twine 2.0.2 is released

edited January 2015 in Chit-Chat
So I think we're ready to begin real testing of Twine 2.0. Obviously, this has been in-progress for some time, but I think we've hit the point where it will be helpful to get a broader base of testers. I would not depend on this release for a big project, but in my testing over the past few months, I have not see any issues that caused data loss. At the same time, I think it would be very prudent to save any work to a file often.

Enough disclaimers, how can I get my hands on this?

You can either download it for offline work here: https://bitbucket.org/klembot/twinejs/downloads (choose twine-2.0p2.zip)
Or you can play with it online here: http://twinery.org/2

Inevitably, there will be tweaks before preview 3. (Right before I wrote this post, a pull request came in to fix a potential bug!) If you want to try the bleeding edge, you will be able to do so here:

Offline: https://bitbucket.org/klembot/twinejs/downloads#tag-downloads (choose the tip version)
Online: http://twinery.org/2test

I will be updating these pretty regularly, so be sure to bring a hard hat! I will be doing my best not to upload broken versions, but you never know.

If you grab the tip version off Bitbucket, you'll need to do some work to get it working -- see the repository readme for details. If you're never used Node.js before, you may just want to use the online version.

So is this replacing Twine 1.4?

I see these two versions co-existing for a while, at the very least. As you will see, not every feature from 1.x has made it into 2.x yet. Some will eventually do so, some won't. If you end up preferring 1.x, I won't be offended!

How do I report a bug or suggest an improvement?

Do that over at the bug tracker. I will be interpreting the number of watchers on a bug as a rough metric as to how much important it is to the community, so that's the best way to influence priorities.

Wait, you said some features aren't going to make it from 1.x to 2. What does that mean?

There are three main reasons that I've been making changes during the 2.0 development process. First is improving what I view as broken or annoying behavior. For example, you can now set a story title through the GUI instead of using a specially-named passage. Secondly, I'm trying to remove unnecessary complexity. An example of this would be zoom settings -- instead of zoom in/zoom out, there are just three zoom settings that correspond to levels of detail.

Finally, I'm also making changes so that Twine 2.0 is usable on a touch-based interface, e.g. tablets. That's why, right now, you can't marquee select passages by dragging, because that's the same interface gesture that a touch-based device would use to scroll around. I totally recognize the need to select more than one passage at a time, but I don't yet have an alternate UI for that. I do see that as a problem that needs to be solved.

Whew, I think that's it! I hope you enjoy trying it out.
«134

Comments

  • klembot wrote:

    Finally, I'm also making changes so that Twine 2.0 is usable on a touch-based interface, e.g. tablets.

    I WILL LOVE YOU FOREVER.  ;D ;D ;D
    klembot wrote:
    I totally recognize the need to select more than one passage at a time, but I don't yet have an alternate UI for that. I do see that as a problem that needs to be solved.

    If you mean you're not sure how best to do that for touch devices, and presuming pinching won't be used to zoom based on how you describe zoom working, one solution for this would be to place two fingers on the screen and drag them to make a selection box. Obviously this only allows to select in a rectangle. For more freedom, how about one double taps on a blankspace to start multiple selection, a little box pops up saying something like "select passages now, tap here when finished". The user can then tap each passage they want to select, click on the pop-up when they're done, and then move/delete/whatever them at once. This solution could also work with a mouse.
  • klembot wrote:
    I totally recognize the need to select more than one passage at a time, but I don't yet have an alternate UI for that. I do see that as a problem that needs to be solved.

    A second possible solution is to copy the method used to highlight text on touch screens. eg. you tap on a word once. then you drag the dot to highlight the rest of the text.

    NOTE: In Twine 1.4 the passage frame widgets are not drag resizable, I am assuming that Twine 2 is similar.

    You could get the user to select the first passage widget, causing it to be surrounded in 4 (sides only) or 8 (corners as well) 'dots'.
    The user could then drag a dot in the related direction which would result in other passages also being selected.

    The two upsides are that firstly this is a technique that the touch screen people would already be used to, and secondly it should also work with a mouse.
  • There isn't really any documentation of the proposed next-generation syntax, but take a look at this page anyway.
  • Can I just go on record and state I love the hook macros.  Very intuitive and easy to use - I managed to set up a nice little conversation dialogue in one passage with very little effort, at the minute for this to work in 1.4 I've resorted to a very clumsy combination of custom javascript, css manipulation...etc. 

  • I like the idea of hooks as well. Maybe you could take it a bit further though.

    I'm writing a game in Twine (1.4) that has a lot of dynamic behavior and a problem I'm encountering is that the flow of the code and the flow of the story difficult to follow because of the syntax: the code can't be formatted for optimal readability because that would break the formatting of the story, while the story is hard to read because there is so much code mixed in. Hooks would allow to separate the code from the story.

    However, if the code is separate (inside the same passage but not inside the same paragraph), there is no real reason to stick with the slightly awkward macro syntax. For one, it is pretty verbose, with "<<" and ">>" surrounding every macro name and many requiring a close tag as well. Also the existence of shortcuts like "<<click-append>>" is only necessary because there is no convenient way to attach a processing instruction to an event.

    Let's take this modified example from Leon's page:

    You see puppies, puppies, puppies and more puppies.
    \
    <<click-replace "puppies">>dogs<</click-replace>>
    (I changed the close tag to read "click-replace" instead of just "replace" and I added the backslash to eat the newline. I don't know if the latter is needed with Harlowe, but with SugarCube having newlines at the end of a passage will lengthen the separation line between the main content and the side bar.)

    Ideally I'd like to write code like this:

    You see puppies, puppies, puppies and more puppies.
    --
    puppies { click: replace dogs }
    I'm using "--" here as a separator between story and code; it can be any unique string. Since the code is in a separate section now, there is much more freedom to choose a syntax for it. I picked something CSS-like here: selector { event: action }, but maybe with the right convenience functions it could be JavaScript instead:

    $('puppies').onClick = replace('dogs');
    (It probably won't work exactly like that.)

    Having inline macros like <<if>> and <<print>> is useful, but for many of the other macros having them inlined in the story is a disadvantage. The hooks mechanism makes it possible to have a reduced set of inline macros and deal with most dynamic behavior in a code section (or multiple) within the passage.
  • I'm not entirely sure where this is appropriate to put this, but Chris Klimas suggested here:

    Basically, I'm wondering how you would write a setter link in version 2.  In 1.4 you could write it like this:
    [[passage1][$variable to "foo"]]
    However, this doesn't appear to work in Twine 2.0. The passage is named as 'passage1$variable to "foo"'.

    This works for one word links:
    [[link]]

    <<click "link">>
    <<set $variable to "boom">>
    <</click>>
    but this doesn't work:
    [[option two]]

    <<click "option two">>
    <<set $variable to "boom">>
    <</click>>
    Is this something that will be introduced, or will there be a different way of doing it entirely?  I know this is a work in progress, so I'm not expecting all the functionality of 1.4 to appear in 2.0 right now, but I guess most of it would be included eventually?

    Also, regarding stylesheets...I've tried using a stylesheet from a 1.4 project, and it seems to work except for using background images - how would you recommend that we use background images in 2.0?

    I tried saving the image in the same directory as the index file and calling it via url('background.jpg') but that didn't work.

  • Well, here's my wish list of features for a web server based twine.  I understand you're mostly looking at how to get the editor working, but the following would help leverage your placement of Twine on a server...

    1) The ability to connect an external server (LDAP based) for user authentication.

    2) The ability to set up access controls so I can say who can play, read the source for and edit each story.  Note that being able to be played by unregistered users is a separate access to being able to be played by specific registered users. There should be a way to configure it so 'playable by unregistered users' defaults to off (and cannot be turned on) for all users.

    3) Multiple editors for each story

    4) Multiple concurrent editors for each story (passage level locking, not story level locking), updates being dynamically reflects to all current editors.

    5) Reviewer functions? (Ability to add comments/critiques to a story (probably per passage), possibly a level of access between Read and Edit).

    6) A story template library? Could be done with read only stories, but a template library sounds better.

    7) Ability to download the compiled html for a story so it can be hosted/distributed outside of the Twine Authoring environment.  The author should be able to restrict the access level at which this can happen or it should be a separate access right - Download.

    8) The ability to Publish a story should be a separate right, typically, but not necessarily, granted to all editors.

    9) The ability to put #tags on a story and to sort/filter the stories you can see by #tag.  A bit of autotagging by author wouldn't hurt - #sharpe #play would show me all the sharpe stories I can play.

    10) Feedback mechanism (not the detailed in story review) allowing readers to leave comments on a story?

    I'm not expecting any of these in the near future, but they might help shape your thinking about where Twine on a web server could go...
  • mykael wrote:

    Well, here's my wish list of features for a web server based twine.  I understand you're mostly looking at how to get the editor working, but the following would help leverage your placement of Twine on a server...


    You are aware that currently the stories you create in Twine 2 are stored on your local machine within your browser's storage and not on the web-server even when running via a remote web-server.

    It is currently a stand-alone app similar to Twine 1.4 except instead of being written in Python it is written using HTML and Java-script.
  • Yes, but I can still package that up and run it off my hard drive.  Why go through the hassle of putting it on a server if you're not going to make it do server things?
  • I'll start by stating that this is my own vision for Twine, which is not meant to be the final word on such things.

    The point of making Twine 2 a browser-based app -- and I'm using that phrase intentionally here instead of server-based -- is that it eliminates many cross-platform issues, and it provides a means for people to use Twine on tablets (and perhaps phones, if you are particularly brave). Maintaining four versions of a Twine app at the least -- Mac, Windows, iOS, and Android -- is infeasible given the number of people working on it, in my opinion. Leon has a hard enough task just keeping up Mac and Windows versions of Twine 1.4. I personally think that browser capabilities have advanced to the point that they can accomplish the things that Twine needs just as much as an app can.

    The reason why I posted the app to twinery.org is so that people can try it out for themselves, and to make it accessible to tablet users period.

    mykael, I think the vision you are articulating is an interesting one-- it is just one that I don't think is possible right now given the small group of people working on Twine out of the goodness of their hearts. If someone were to appear with a wheelbarrow of money and asked me to assemble a team to work on it fulltime, then the calculation might change. And if someone wanted to assemble a team themselves to work on that project, I would do whatever was reasonable to help them out.

    One of my goals working on the single-user-oriented version of Twine is to avoid decisions that would make it hard to adapt to the multi-user scenario you're describing. I think of it almost as a reference implementation in that respect.
  • Then out of all that lot I'll just say that the ability to store the story data on the server or in cloud space is probably the most important. Why?  Because if I've got 5 mins I might use my phone to work on something, but I don't want the story 'trapped' on my phone or to be unable to work on it because it's on my home system.

    Maybe once you've got it running to local storage we could look at the google cloud storage API or some such.  See if we can get google to directly charge the user rather than the server host...
  • mth wrote:

    Ideally I'd like to write code like this:

    You see puppies, puppies, puppies and more puppies.
    --
    puppies { click: replace dogs }
    I'm using "--" here as a separator between story and code; it can be any unique string. Since the code is in a separate section now, there is much more freedom to choose a syntax for it.

    I've independently proposed this idea to Chris myself - the idea that the passage editor (and thus the passage data structure) be divided into a "text section" above, and a "silent section" below, where all the code in the silent section behaves like it's in a <<silently>> macro. There isn't yet any implementation, though.

    As for different macro syntax inside the "silent section"... I have been contemplating some kind of "block syntax" for macro tags that lets you forgo the "<<" and ">>" and separate them by other means, but I haven't yet thought of anything I'm satisfied with, and that doesn't seem like an unintuitive departure from the normal style of macro tags.

    (One advantage to leaving the macro syntax in its verbose form, I guess, is that the silent section could also have comments interleaved in it in the form of plain text. (Not that people comment their Twine code that often, though.))

    bawpie wrote:

    I'm not entirely sure where this is appropriate to put this, but Chris Klimas suggested here:

    Basically, I'm wondering how you would write a setter link in version 2.  In 1.4 you could write it like this:
    [[passage1][$variable to "foo"]]
    However, this doesn't appear to work in Twine 2.0. The passage is named as 'passage1$variable to "foo"'.

    This works for one word links:

    [[link]]

    <<click "link">>
    <<set $variable to "boom">>
    <</click>>
    but this doesn't work:
    [[option two]]

    <<click "option two">>
    <<set $variable to "boom">>
    <</click>>
    Is this something that will be introduced, or will there be a different way of doing it entirely?  I know this is a work in progress, so I'm not expecting all the functionality of 1.4 to appear in 2.0 right now, but I guess most of it would be included eventually?

    One suggestion is that you should be able to make the link become a hook by doing [[Link text->Passage name]][a]... but I'm a bit dissatisfied by the fact that the [ ] brackets have multiple different meanings, so close together.

    Another suggestion is to make links be "implicit hooks", that can be immediately referred to by a new sigil or something... but there's a lot of possibilities for this. <<click [[Passage name]]>> ? <<click [[Link text]]>> ? <<click link 1>>? (I dislike the idea of referring to hooks by text location rather than their actual features.) <<click link "Link text">> ? <<click "Link text" in links>> ? (I hesitate to add an all-new "in" keyword without thinking how it'd work for any other macro.)
  • mykael wrote:

    Then out of all that lot I'll just say that the ability to store the story data on the server or in cloud space is probably the most important. Why?  Because if I've got 5 mins I might use my phone to work on something, but I don't want the story 'trapped' on my phone or to be unable to work on it because it's on my home system.


    I agree with you there. I've looked into the possibility of saving to Dropbox or Google Drive from the editor, but there would need to be some server-side code to facilitate that-- same-origin policy prevents JS from talking to the Google Drive API directly, and Dropbox's Saver interface wants you to give it a temporary URL to download from. I'm not an expert on either API, however, so there might be a workaround!
  • If there is no a way to get around "same-origin policy" (and there should not be without server-side code) there is another option.

    If the Author has the Dropbox Application installed on their machine/device of choice (as long as it is not iOS based) then you could implement an Import/Export feature. (like SugarCube's "Save to Disk" / "Load from Disk")
    This would allow Authors to load/save the contents of their story to a file in their local dropbox directory/folder.
  • Here are some ideas for further Twine 2 development that have come to mind:

    Regions as tags

    It's become clear to me that passage tags ought to come back, due to the variegated benefits that Twine 1.4 has given them. But I've been thinking of a new way to tag passages: draw a rectangle over the Story Map, and give it a colour and a name. Any passage inside that laid-down rectangle is considered to have that rectangle's name as a tag. You can thus tag passages by dragging them off and onto the rectangle, or moving the rectangle around. If you want to tag two very separate passages with the same tag, simply duplicate the rectangle and lay it down over there. What do you think of this idea?

    Stylesheet passages

    Throughout early development of Twine 2, it was assumed that all of the "special passages" - StoryTitle, StorySettings, the script passages, etc. - would be peeled off the Story Map and placed in separate side-menus, as single text blocks. However, I feel like maybe in the case of certain "scoped assets" - and I'm thinking here of tagged stylesheets - there'd be call for putting them back on the map, so that they can, as in Twine 1, be arranged alongside the passages that use them. This relates to the "regions" idea - the idea of the Story Map as game asset organisation as well as story structure organisation.
  • If I may, I'd like to request "tabs", like in browser tabs.

    I'd love to be able to put, for example, all my "town" passages on one tab, all my "overworld" passages on another, all my "dungeon" passages on another, all my "combat" passages on another, etc.

    Not a big deal or anything. Just throwing that out there. I think I've heard it requested before, too.

    L wrote:
    But I've been thinking of a new way to tag passages: draw a rectangle over the Story Map, and give it a colour and a name.


    That sounds really cool!

    L wrote:
    Stylesheet passages[/b]

    Throughout early development of Twine 2, it was assumed that all of the "special passages" - StoryTitle, StorySettings, the script passages, etc. - would be peeled off the Story Map and placed in separate side-menus, as single text blocks. However, I feel like maybe in the case of certain "scoped assets" - and I'm thinking here of tagged stylesheets - there'd be call for putting them back on the map, so that they can, as in Twine 1, be arranged alongside the passages that use them. This relates to the "regions" idea - the idea of the Story Map as game asset organisation as well as story structure organisation.


    I like the idea of just having special passages be menu options. That's cool. And, yeah, style sheets could certainly be an exception to that for reasons mentioned.

    However, you could also just maybe have a check box or whatever by the style sheet on the menu to go with your regions idea. Either way.

    However, could I request an option to make style sheets include the default CSS rather than just appear blank? I request that for a quite number of reasons. "It will scare newbies" is overridden by, "It will make newbies lives hell trying to figure out why the CSS isn't working due to conflicts," IMO. Just saying.
  • re: Regions as tags

    Though this sounds cool, I can see two possible issues:
    1. Passages that need multiple tags, would the passage need to be in more than one region.
    2. The screen background could become quite messy depending on the number and size of these regions. A region could easily cover multiple viewports worth of screen real estate, or do you plan to add scroll bars to the region?

    Sharpe wrote:

    However, could I request an option to make style sheets include the default CSS rather than just appear blank? I request that for a quite number of reasons. "It will scare newbies" is overridden by, "It will make newbies lives hell trying to figure out why the CSS isn't working due to conflicts," IMO. Just saying.

    I think that giving the Authors the ability to "view" the default CSS is a good idea, however making it directly editable could result in a broken default stylesheet. How would the application help them undo a bad change to the defaults?
  • Really interesting reading, to see what folks's wishlists are. Right now I am trying to focus on the gaps in Twine 2, e.g. reasons why someone couldn't use it fulltime. To me, those are:
    • No tags
    • No find/replace
    • Can't copy/paste passages, in particular several at once
    • Can't plug in templates, e.g. Sugarcube
    ... but I bet there are others.

    Not sure how I feel about regions -- I like the idea of graphically representing things like tags, but I wonder if it has the potential to create monstrous Venn diagram-ish things.

    I get why you would want to see the built-in CSS for a template, but there are two somewhat ugly possibilities with the implementation:
    • You allow people to mess up the built-in CSS-- then you have to give people a way to restore that.
    • Outputted stories contain redundant CSS -- the user-tweaked version and then the original CSS.
    I think there definitely need to be mechanisms in Twine to make large-scale stories easier to work with. Here's what I've thought about:
    • Tabs: not a bad idea, but you're limited by the width of the user's window (or else you have to scroll through tabs-- not fun).
    • Folders, e.g. double-click a folder or pile of passages to zoom into a sub-section of the story: seems plausible except you need a good way to represent links running between disparate folders. That is, if a link from a passage three folders deep goes to a different folder, how do you represent that graphically?
    • Bookmarks, e.g. one big story map that you can jump around to designated parts of: the easiest implementation, but does it really solve the problem?
    • Compose a story out of multiple story files: feels like dumping the problem on the user, e.g. now you have to manage multiple story files and make sure they all travel together. Moving passages between story files is cumbersome.
  • klembot wrote:

    You allow people to mess up the built-in CSS-- then you have to give people a way to restore that.
    Outputted stories contain redundant CSS -- the user-tweaked version and then the original CSS.
    Tabs: not a bad idea, but you're limited by the width of the user's window (or else you have to scroll through tabs-- not fun).



    [list type=decimal]
    Create a new stylesheet and delete the old one, which is how one currently restores default CSS.
    I don't see a big problem with this. I do see a big problem with conflicting CSS, and that happens all the time in 1.x.
    I don't think tabs in Twine would be any more limited by the user's browser window than they already are, and no one would have to use them. You can put everything on one tab, just like you don't have to make new tabs while browsing the Internet.


    Just my opinions! :)
  • Sharpe wrote:

    3. I don't think tabs in Twine would be any more limited by the user's browser window than they already are, and no one would have to use them. You can put everything on one tab, just like you don't have to make new tabs while browsing the Internet.

    A small difference between tabs in the browser and ones within a HTML page is that the ones in the the browser are separate DOM's so you dont have to worry about things in one tab effecting other tabs.
    Tabs within HTML pages are just a visual effect, so to make sure one tab did not effect the others the existing code would need to be restructured to sandbox each tabs' properties. (tab title, passages list; maybe storage file name; etc)

    klembot wrote:

    Compose a story out of multiple story files: feels like dumping the problem on the user, e.g. now you have to manage multiple story files and make sure they all travel together. Moving passages between story files is cumbersome.

    I have used ER / Class modelers that have implemented this by visually showing an external sub-model file (list of passages) within the current/parent model as a single table/class widget (coloured differently) to represent the whole external sub-model. When you double clicked on the widget it would open the sub-model in a new window.

    Moving items between windows was done either via drag-n-drop or by right clicking on the widget (or pre-selected group of widget) and using a "move to sub-model" feature.
  • Rather than tabs, how about the ability to use the tags as filters for the display?  Check 'All' and they all show up. Uncheck all but town and you're left with only the town tagged passages.  Check only town and night and your left with only the town at night time passages.  Cheap to implement, gives us a nice way of scoping down the display without many of the drawbacks of the other methods.  Links to undisplayed passages should be either hidden of indicated via a fading link.  Could be done in 1.4 even ;-) 

    Regions I'm not so keen on.  Yes, there are regions of contiguously tagged passages - but that's not necessarily so and, as Greyelf said, it gets messy when I want to start adding multiple tags to a passage.
  • mykael wrote:
    Rather than tabs, how about the ability to use the tags as filters for the display?


    The  whole reason I like the concept of tabs is to unclutter and organize the work space and have more room to display passages. With that system, you still wouldn't be able to place passages on top of passages (nor would you want to do so!), so it does nothing to further any of those ends, in my opinion. 

    I want tabs for more room, so I'm opposed to the argument that it would make less room.

    mykael wrote:
    Regions I'm not so keen on.  Yes, there are regions of contiguously tagged passages - but that's not necessarily so and, as Greyelf said, it gets messy when I want to start adding multiple tags to a passage.


    Yeah, on second thought, it sounded cool, but there's just not enough work space to have multiple regions without a bunch of scrolling and the addition of multiple tags makes it a difficult reality to implement. Anyway, 99 of 100 of my passages all have the same tag: "nobr". Those that don't wouldn't need to be placed in a separate area. Not saying the fact that I personally wouldn't use it is a good argument against it, though. I understand that things for which I have no use doesn't mean others wouldn't get a lot of use out of them.

    All just my opinion. I like Twine enough how it is now. :)
  • Tagging is a very versatile mechanism; only some of its uses apply to passages that are closely connected. For example, in a game where a hero travels to complete a quest, there could be passages tagged as "cold" where your health suffers if you don't have warm clothing. Those areas would be a closely connected subgraph that could easily be placed in a rectangular region. There could also be passages tagged as "campsite" where you can choose set up a tent and rest for the night. Those areas would be spread all over the story map and there would likely only be one passage per area. So using rectangles to tag only covers some of the uses of tags.

    What you could do is add an easy way to add/remove tags from selected passages. Then you can use a rectangular selection to tag grouped passages at once.

    Using colors to visualize tags is a good idea in my opinion and will become more feasible when there are fewer types of special passages, since that would free up colors for the user to assign.
  • L wrote:

    One suggestion is that you should be able to make the link become a hook by doing [[Link text->Passage name]][a]... but I'm a bit dissatisfied by the fact that the [ ] brackets have multiple different meanings, so close together.

    Another suggestion is to make links be "implicit hooks", that can be immediately referred to by a new sigil or something... but there's a lot of possibilities for this. <<click [[Passage name]]>> ? <<click [[Link text]]>> ? <<click link 1>>? (I dislike the idea of referring to hooks by text location rather than their actual features.) <<click link "Link text">> ? <<click "Link text" in links>> ? (I hesitate to add an all-new "in" keyword without thinking how it'd work for any other macro.)


    Thanks, I tried something like this:
    [[Link text]][a]

    <<click ?a>>
    <<set $searched += 1>>
    <</click>>
    But it didn't work, the 'a' becomes a separate click able link. 

    I also tried:
    <<click [[Passage name]]>>
    <<set $searched += 1>>
    <</click>>
    This generated a new linked node, but the actual link 'passage name' didn't show up in the screen when testing.  Though I think you were just suggesting a way of writing this, rather than giving a working suggestion.

    I do like the suggestion of having the window split, one into text and another into the actual 'silent' code.  It seems a lot cleaner to me.  :) 
  • Here's another idea that's been on my pan recently:

    A <<render>> macro for extending formatting syntax

    @ inline-style syntax - both fairly verbose.

    What this macro will do is allow you to select text by defining new markup patterns:

    <<render %text% thus. color: azure>>
    <<render .:text:. thus. background: [img[sparkle.gif]]; font-size: 120%>>
    <<render ^^text^^ thus. bold; italic;>>

    Here's .:some flashing text:. followed by ^^bold italic^^ text.
    (They keywords "text" and "thus." are quite tentative.)

    What these do is define new markup syntax extensions, and accompanying CSS attributes to apply to the markup. But, you could also use it to override or extend current markup styles:
    <<render **text** thus. color: gold>>
    The author's familiarity with the markup syntax is thus directly transferable to use of this macro.
    You may note that one of the above examples only specifies "bold" and "italic" as attributes. I'm thinking, to aid authoring, that for certain property values that the CSS spec ties to a single property (such as "bold" for "font-weight", and "super" for "vertical-align"), the property name can be omitted. These would be a small set of very common values (mostly bold, italic, centering, capitalize, etc.).

    You can use this in single passages to apply styles just to this page, or you could put it in, hmm, some kind of "transclusion" passage* to make it apply globally all over the story.

    I'm also thinking of a slightly different kind:
    <<render ?red thus. color: red>>
    <<render "crouch" thus. font-size: 90%>>
    That is, as a hook/pseudo-hook macro. I feel like this should also be possible, but maybe as a different macro. Maybe this should be called "render" or "present", and the other one "stylise" or "define" ?

    *Something that, perhaps, contains only a silent area, which has the same inclusion functionality that Twine 1's stylesheets have - global, or local to a tag if it bears one. Call it an "appendix" or "glossary" passage?

  • [quote]The  whole reason I like the concept of tabs is to unclutter and organize the work space and have more room to display passages. With that system, you still wouldn't be able to place passages on top of passages (nor would you want to do so!), so it does nothing to further any of those ends, in my opinion.

    I want tabs for more room, so I'm opposed to the argument that it would make less room.

    Well, you might need to add a smarter auto-layout algorithm and a way of defining a set of filter settings and a layout as a view.  Either remembering where you've put things for each different filter setting, simply leaving things where they are or auto-packing them in some way.  As you say, simply leaving them in place and hiding everything else in the big display isn't going to work so well.

    View 1 - everything except macros and style sheets
    View 2 - only macros (default layout overridden)
    View 3 - only style sheets (default layout overridden)
    View 4 - only campsites and inns (default layout, view 1 as a grey scale backdrop)
  • klembot wrote:

    mykael wrote:

    Then out of all that lot I'll just say that the ability to store the story data on the server or in cloud space is probably the most important. Why?  Because if I've got 5 mins I might use my phone to work on something, but I don't want the story 'trapped' on my phone or to be unable to work on it because it's on my home system.


    I agree with you there. I've looked into the possibility of saving to Dropbox or Google Drive from the editor, but there would need to be some server-side code to facilitate that-- same-origin policy prevents JS from talking to the Google Drive API directly, and Dropbox's Saver interface wants you to give it a temporary URL to download from. I'm not an expert on either API, however, so there might be a workaround!

    I know this might be a bit late, and I've probably misunderstood, but there's not really a need for an API when saving to mobile devices/PCs when using Google Drive.  I have several PCs I use, including one that I use purely for working away from home.  At home I have the ability to save everything onto my file server so it's not an issue, but it means I have to sync the laptop with anything I want to take with me and as I can literally be called out with 2 hours notice I prefer to have clothes over my Twine stories lol.

    If you install the Google Drive PC program on your PC it creates a folder that works like a normal folder (so things can be saved to it) except it syncs to the cloud.  If you have the app on your phone/tablet as well then they will sync too and it's a doddle to just up it to Drive anyway.  I do actually use this system and not just for Twine so it works really well.  The only problem I could see with it is the fact that it requires additional software installed on a PC and if you don't have admin rights (work/library PC etc) then it would be a non-starter.

    If I've got this wrong and not understood fully, then I apologise, but I've just mentioned it in case anyone didn't know about the PC app.
  • L wrote:

    Here's another idea that's been on my pan recently:

    A <<render>> macro for extending formatting syntax

    I'm of two minds on this new idea but I suggest that if you do implement it you don't name the macro render.
    As the macro is designed to extending formatting syntax, maybe naming it style or format would be better.
  • AntonMuerte wrote:

    If I've got this wrong and not understood fully, then I apologise, but I've just mentioned it in case anyone didn't know about the PC app.

    No need to apologize,  the process of file syncing you described is a good one and it works well with the desktop application version of Twine because it saves your story content within a TWS file in a location of your choice.

    Unfortunately this not the case with the future HTML version of Twine as it uses a feature built into the web-browser to store your story content in the browser's own internal storage area. So this is why a means to copy the story contents from the browser's internal storage to some other location is needed.
  • I take it the browser's internal storage area something that's separate from the cache (which would present issues in itself if the cache was flushed)?  If this is the case, is there no way of at least letting the user know where the file is and what it's called so they could sync it themselves?  I know it's an extra layer of stuff to do, but if it helps preserves the work then I'd consider it a necessary evil.  I'm not sure what the process would be if you worked on it on another device and then needed to transfer it back - would the file name change on another device, or cause some problem with a checksum or some form of validation?

    I'm guessing using a wrapper like PhoneGap wouldn't simplify things, at least in regards to phones and tablets in order to save to local storage as an actual app.  I can also foresee people with Apple devices would have no end of problems installing it as an app unless they were on jailbroken devices, or an account was made with the app store which can be pretty costly.  Android devices wouldn't have an issue if they enabled the "Unknown Sources" for app installation.
Sign In or Register to comment.