Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Sugarcube 'version' confusion
I like to use the Sugarcube Story Format, but am confused as to 'versions'.
When I select it from the menu in the online version of Twine it says 'Version 1.0.34' but I've seen people on the forum talking about 'Version 2.9.0'
I want to make sure I'm using the latest, but don't see a '2.9.0' option version anywhere??
When I select it from the menu in the online version of Twine it says 'Version 1.0.34' but I've seen people on the forum talking about 'Version 2.9.0'
I want to make sure I'm using the latest, but don't see a '2.9.0' option version anywhere??
This discussion has been closed.
Comments
a. The 1.x series:
This is the series which the 1.0.34 version that current comes with Twine 2.11 belongs to and it is the older of the two series. This series is no longer being actively developed by it's developer (TheMadExile) but it does receive bug fixes as required. The latest version 1.0.35 is available for download from the SugarCube 1.x website but you will need to manually add it to your Twine (1 or 2) application.
b. The 2.x series:
This series is only downloadable from the SugarCube 2.x website and you will need to manually add it to your Twine (1 or 2) application. This series is still being actively developed by it's developer (TheMadExile) and the latest version is 2.10.0
I only wish the desktop version was as user-friendly as the online one.
You first need to extract the contents of the ZIP file into a folder on your local hard-drive, and then open the index.html contained in that folder with your web-browser.
How do you believe they differ?
But they don't even look the same?? In the online version you can choose the story format, you can access CSS and JavaScript, and the whole thing is just cleaner and more user-friendly.
Unless I'm missing something where the desktop version is concerned.
They look and function virtually identically.
Twine 2 is simply a web application. The executable builds merely come wrapped within a web-shell—specifically, NW.js—which largely only affects how and where your projects get stored. As to that difference, which is fairly significant, the executable builds store your projects as files on your hard disk, while the browser-based builds store them within their Web Storage—this makes the executable builds quite a bit safer.
Again, they largely look and function the same—since they really are the same.
You must be confusing the executable builds of Twine 2 with something else. Perhaps Twine 1—though that doesn't make much sense, since you can do all of the things you talked about in it as well, though in a slightly different way. I suppose another possibility is that you may have downloaded a really old version of the executable builds.
In the executable build you tried, is there a UI bar on the right side? If so, what version does it report at the bottom of the bar? If not, does it mention a version in the title bar?
Okay, how can you say they are identical??
Desktop
Online
Sorry about that. I've now downloaded 2, and it is indeed identical.
Personally I have never have a problem with losing my projects because I back them up, which people should be doing anyway even if they are using the NW.js release.
A sensible backup routine in no way invalidates the benefits of having safer data storage by default.
You mean the one that the application in some way encourages the user to overwrite with their published stories? The same one that uses a file extension that most people (and their operating system) associate with a HTML document where at best it is a XML file.
I try to encourage people to use the release type they feel the most comfortable with while also pointing out the limitations of each release type, because in general one type is not better than the other as they both have their faults.
Try the different releases of both the Twine 1.x and 2.x applications, also look at the command line tools if that option interests you.
Personally I use the Twine 1.x application more than the 2.x ones, although I need the different Twine 2.x releases installed to simulate the environments of the people I try to help.
As part of his explanation as to why he chose a convoluted keybind in the first place, CK did mention that he didn't want end users accidentally inspecting the Twine 2 UI to prevent confusion, however, that only affects the main window—which you may still inspect in the latest v2.0 release (v2.0.11). He never stated that the loss of the developer tools on the Play/Test sub-windows was intentional and did, specifically, state that he wanted to restore the ability.
I think you're overblowing the issue and attempting to ascribe blame not evidenced by any of the details we know.
IIRC, end users have published to their Twine Stories directory, as far as we know, a handful of times—and, yes, there's probably been several more unreported occurrences. It's also squarely the fault of the end user not paying enough attention—more on that below.
I'm unsure if you conflated project overwriting with the far more common occurrence of end users posting files from their Twine Stories directory, thinking that they're the compiled HTML files. That particular issue, at least, I would certainly agree is enabled by a poor file extension choice. That said, however, it's still primarily the fault of the end user not paying enough attention—again, see below.
And no, I'm not picking on the end users here. Publishing to file in the executable builds presents the user with a standard save as dialog, clearly showing where the file will be saved. Overwriting files they didn't personally save in the first place and not taking notice of where their files are being saved is solely caused by a lack of attention. You cannot blame that on Twine 2. (Don't misunderstand me, I'm no Twine 2 apologist, evangelist, whatever. It has plenty of issues of which I'm more than happy to talk about—great and small, both with its code and the management of its development.).
For the sake of argument, however, even if we assume that Twine 2's executable builds enable end users to make poor choices when publishing, that's still completely irrelevant as to whether or not Twine project data is safer within separate files on the filesystem or inside a browser's web storage.
A browser's web storage is often stored within a database in, gently, hidden locations which often receive little in the way of backups—either by versioning or general backups. Worse, besides normal in-browser methods of purging web storage, there are far, far too many other programs which happily remove such data—computer "cleaning"/"speedup" programs being both the worst offenders in this category and often used. A browser's web storage is under no circumstances a safe place to store anything you cannot absolutely afford to lose, because you probably will at some point.
The default location used by the executable builds is in a location which a) doesn't get purged at the drop of a hat and b) is a likely target to be collected within general backups, if any happen to be set up.
Coming back to what started this. A sensible backup routine is a good idea and more end users should do so with their important data—I totally agree with you on this point. That said, even taking into consideration the fact that end users do not pay enough attention to what they're doing and allowing that the executable builds have some confusing naming issues, your filesystem—thus executable builds—is still safer for Twine project data by default.
The project data files containing a partial HTML document in no way makes them XML files.
That clarification aside, I do happen to agree with you on this point. While the current file extension is technically correct, a different extension would have been a better choice—to avoid both potential confusion on the part of end users and allowing other programs to be associated with them.
There is no (offical, non forum) documentation telling them not to use the first two locations. If the end-user comes from a Twine 1 background, which by default encourages the end-user to save their output in a location relative to their story project file, it is even more understandable that they use the Show Library related folder.
While the custom markup elements contained within the project file may embody HTML/Javascript/CSS markup within them they are not HTML elements them self nor do I believe it is reasonable to state that the over-all file is a HTML document as it is missing a number of things required by the related W3 specification(s).
Is Twine 2 helping here? No. This is still, however, a problem of inattention.
Does this make web storage a good candidate to replace normal files for storing project data? No. At least with normal files, end users who are confused can always learn what they need to be doing—either by figuring out themselves or asking for help. Web storage is always dangerous by default and there is no way to make it safe.
Partial documents—those with omitted tags, including the basic document tags—have always been allowed due to issues with the original specification. They are also now explicitly spelled out within the specification since the introduction of HTML5.
Custom tags have been allowed by browsers for almost as long as partial documents. They are also now enshrined within the specification since the introduction of HTML5. Further, they are currently in the process of being explicitly extended into full on custom elements—i.e. you may define custom behaviors and interfaces for them within the DOM.
Project archives are missing a DOCTYPE preamble, however, that's a strict validation issue. They are as legal as real-world HTML documents may generally be depended upon to be.
I'm not claiming the file extension wasn't a poor choice. It was, for multiple reasons—as I outlined previously. Twine 2 is, again, not helping here. That said, they are HTML documents and maintaining otherwise is poppycock.