Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Twine 2.0.5 questions
So... I am fairly certain that many of you out there can answer this... but I was thinking that there might be other new people who don't know (other than me, because I don't)... so maybe a new thread makes sense.
Why is this newest release (for Linux anyway) a hundred mb (unzipped)? I see that it has a .PAK file and some other things that the previous release did not have.
Will this now change the way I set it up and run it? In the past I just opened the folder and it all worked. I loved the simplicity.
Is this new size and folder content about being able to build native apps?
If so, should I assume that all new releases will ALL start coming this way to us? Or is this a one-off?
Thank you everyone. And thank you @Klembot for this new release... even though it's different, I assume it's better.
Why is this newest release (for Linux anyway) a hundred mb (unzipped)? I see that it has a .PAK file and some other things that the previous release did not have.
Will this now change the way I set it up and run it? In the past I just opened the folder and it all worked. I loved the simplicity.
Is this new size and folder content about being able to build native apps?
If so, should I assume that all new releases will ALL start coming this way to us? Or is this a one-off?
Thank you everyone. And thank you @Klembot for this new release... even though it's different, I assume it's better.
Comments
All the app versions are built using NW.js, formerly known as node-webkit. It's a very popular option for building executable binaries out of web-based applications. You're right, the file size has ballooned as a result... I actually don't know what that .pak file does, exactly! But the reason for that file size change is that it's now packaging a mini-browser with it.
Running it should be exactly the same experience as before, only instead of opening index.html, you're opening the Twine executable. The UI is the same as well, only it saves your stories to files on your computer you can see instead of to a basically invisible place in your browser. That said... I have not really tested it thoroughly on Linux!
There are two real reasons for this change. First, some people have been clamoring for a local app for some time. I think partially this is just a comfort level. It feels weird to open an HTML file to run an application.
The other reason, which I think is more important, is that it's not clear where your stories live in the web version. They don't get saved to a file that you can see. It also means that if you delete your browser history, you can trash all of your work accidentally. Trying to warn people about this just doesn't feel like a viable solution to me. It's scary to tell a new user "don't do these three things or else you'll lose everything," and it also seems probable to me that people don't remember warnings like this anyway.
So I like this app approach despite the extra overhead it imposes (believe me, putting out 2.0.5 was not as easy as the previous releases). If lots of people hate it, though, I'd be willing to consider going back.
I think your misunderstanding @feliwebwork question.
When using the off-line version of 2.0.4 you could use relative urls with an img element and those images would be visible during Test and Play as long as you placed them in a location relative to the location of the Twine 2.0.4 index.html file.
Because the NW version of 2.0.5 does not now use the user's web-browser during Test and Play there is no way to see the temporary HTML files location (no location bar) so there is no way to know where to locally locate the image files now.
@timsamoff:
If you are distributing a Twine story using an archive file then there is no need to host external media (like images) on a web-server.
Yes, thank you. I didn't express myself clearly.
is there any way of viewing the images during the test and play phase without having to publish the file?
It would be very helpful to have this feature (of viewing the images during the test and play phase before publishing). In fact, for that reason alone I am pretty much sticking to 2.0.4, as having the images present while I am working in Twine also helps with the inspiration for how the story flows, etc.
But if there IS a way of viewing the images offline without having to publish the file (ie. viewing it within the test and play of Twine itself) that would be great.
http://twinery.org/forum/discussion/comment/9773/#Comment_9773
If there is a way of doing this in the official release of Twine 2.0.5 that would be great. Otherwise, perhaps having the option of this web browser based version would be helpful to others. I know that it introduces the issue of where the archives are saved, etc., but I have got into the habit of saving and publishing to file so as to not lose work. Ideally if the .exe file version could include a way of seeing the images during play and test, it would be better.
@feliwebwork
I think for me also... the easy folder structure is better as well (2.0.4), it feels easier to install and easier to use. I'm also used to it now.
But if I had to guess... I would say this will skew almost directly along party lines. In other words, if you've been around here for a while... maybe good at programming, etc., the new direction of 2.0.5 will appeal to you more, whereas the newbies (myself included) take the path of least resistance for 2.0.4.
Funny commentary on this issue: I'll probably end up trying to learn 2.0.5 so I can be ahead of where things are going instead of always (either:) ["eating at the kids table", "playing in the shallow end", "staying in my comfort zone"]
I'm just saying that it would be nice if on the main page was a link to the offline version 2.0.5. As, for example, was on 2.0.4 - http://twinery.org/downloads/twine_2.0.4.zip (sorry for my English)
Can "either" have more than two options? I did not know that!
It will always be possible to generate local HTML versions of Twine. It's just a question of what's promoted.
@Sage, curious why you think 2.0.5 will be harder to work with. Could you elaborate?
I believe this could probably be solved by homing each build to a common, easy to find, directory. It would also be nice if Publish to File used the same structure. For example:
…/Documents/Twine/Published/{STORY_FILENAME}/…Or something like that.At the moment, yes, that would be my only reason for wanting to use the HTML version. I think the save features of the app version are great, and I think the concerns about people accidentally deleting their work when using the HTML version are valid concerns and very important. For that reason I fully understand the move towards an app. It makes sense.
It's just that not being able to see my images during the play and test part of Twine greatly affects my work flow and it is a bit of an interruption having to publish to file each time I want to change the CSS, etc. and see how it works. I can live with it and probably would get used to doing things that way, but if I could just press play and see the story as I would see it once published, that would be so much better.
Yes. I think you have summarised it well. Thank you.
I think @TheMadExile has it right. There is a standard method for web development where you just put it all in one folder and you make sure you take that folder with you (via FTP, for example) when you publish. It was a "build" metaphor that I understood.
Sure... on some level I know that "compile" is an option as well... but that perceived overhead is a reason that Apple went to Swift, for example.
The nice thing that Twine had (previously) was also that the program setup worked that way as well. Just grab the folder and ta-daa! it works and is already "installed." It's a simplified workflow.
Your move is the right one. I know that. You should build it with an eye towards where you want to be, not where people were most comfortable. Yes, there is something to say for the simplicity that was, of course... but if I gain, for example, the chance to now push this to an iPhone (which... I get, is NOT on the table, I'm just using an example) then I would obviously prefer the new method... no matter WHAT the learning curve.
The only caveat to that, for me anyway... really came from an example by @Sharpe.
He said to make an easy and short game. His thread went (pseudo) viral because it had no barrier to entry. It was dead simple and we all did it and we all felt awesome.
That level of easy is what Twine means to me. I assume it will stay that way, even with 2.0.5
To answer the question of why I think it will be harder now than it was, is a combination of what TME, and @Feliwebwork said, yes, but also that the PAK exists, the larger file size, the need to split the installs into different machines because Win v *nix v Mac where before it wasn't that way.
But all of this isn't real. That's the thing I want to make clear.
It isn't those things, per se... it is the perception of those things.
The workflow seemed easier before.
@Hanon Ondricek
Yes... you certainly can.
Here is a real example set up as a link for SugarCube:
Before you there is
[[a swirling mist|either("The By-way of the Buddhist","The Way of the Wiccan","The Path of the Pagan")]]Personally I really like 1.4.2 as the Twine standalone install, and it's a bit of a shame to see it left behind in favour of a new application that has some real comparative drawbacks. A better outcome in my mind would be to leave Twine 2 as the web thing, but include Harlowe with 1.4.2, and keep 1.4.2 in a prime spot alongside Twine 2.
Maybe even rename 1.4.2 to "Standalone Version", as the numerical designation implies 2.0 was a vertical development, when it was more of a side development.
Interesting idea. It makes sense, unless there is something about Twine 2 that really is better (says the guy who knows nothing about these things).
I don't know anything about 1.4.2, but it does make sense including Harlowe for it. Of course, all these things are up to the people who have to put the work into getting it done.
My tentative plan, pending technical and usability considerations, is that authors get a media library inside Twine that they can add to, and then embed media into their passages with a nice-ish UI. If you publish a story with media, you get a ZIP file that has everything set up for you; otherwise, an HTML file like always.
(Is this up for debate? Of course!)
The question of 1.4.3 vs 2.0.5 is tricky to address. I've always said, and still believe, that if the 1.x series is better for you, go for it! My feeling is people will vote with their feet, and that's the best way to determine Twine 2.x's role in the community at large.
That said, I do think 2 improves on 1 in the sense that is usable on many more platforms -- tablets, and I believe it's a lot easier to install on Linux as well -- and it cuts out some of the janitorial work in editing stories. i.e. do you need to create a passage called StoryName or StoryTitle to set your story's name? Is the syntax passage name or displayed text? You shouldn't have to remember exactly what a passage's name is in order to link to it. If you rename a passage, you shouldn't have to re-link it.
Are these earth-shattering changes? Nope. But if they were, I think we would be having a whole other discussion
I agree. I am such an "author" who would like things to be simple. (ie. "put your images here..."; "put your audio files here...", etc.), and then have a native way of styling the images with css (through asigning a class to each image), and a native way of handling the audio (cross-story-format, with ability to fade, control volume, intro, end, etc. per story and per passage).
sounds pretty good.
Agree
Depending on which story format an Author selects (Harlowe vs SugarCube) won't these issues still exist? Does this mean that you are going to release a 1.4.3 version containing all the fixes/updates done since jun-2014?
Error: Uncaught Type Function: undefined is not a function
whenever I click a link to go to a new passage. Everything else seems to work fine.
Also, the error message has the lower third of the bottom line cut off.
Thanks for putting so much time into Twine!
I don't know
Shouldn't; I believe all formats handle the text->link format and its reverse.
I slipped on this one -- should've written 1.4.2. My involvement in the 1.4.x series has been limited to posting releases. @L may be able to give you a better answer.