Format Data in Twine to on Mac OS X (Yosemite, 10.10.5)

Carradee

It looks as if I have the same sort of problem this person did on Windows: https://twinery.org/forum/discussion/4875/cant-install-sugarcube-2-to-twine-2-help

SugarCube 2 was working. I'm not sure when it broke in Twine 2; I've been using Twine 1, and when I realized how to put SugarCube 2 on that, I did so and noticed there was an update. I went to install that on Twine 2 (while it was closed), and now I get "The story format “SugarCube 2 (local/offline)” could not be loaded ()."

I've tried to re-add the file, and I get "The story format at file:///Applications/_game_making/_game-making_applications/Twine/Twine_2/offline_formats/SugarCube-2/format.js could not be added ()."

And now that "The story format “SugarCube 2 (local/offline)” could not be loaded ()." appears in triplicate.

Where do I go to clear out that local formatting data? I suspect the problem is that I changed directories and now have conflicting data, but I'm not sure where to look to check. deleting preferences files and reloading a new copy of Twine 2 didn't help.

Thanks!

Carradee

As an update, I tried wiping all preferences (using AppZapper to find them). I still can't add the link. Is it something wrong with my link?

ETA: I've been creating the link via Terminal. I instead got it from my browser, opening the file, and that worked.

TheMadExile

Carradee wrote: »

ETA: I've been creating the link via Terminal. I instead got it from my browser, opening the file, and that worked.

Please, if I may ask. What was the difference in the URLs? Also, how did that compare with the instructions within the SugarCube 2.x in Twine 2 guide?

Carradee

TheMadExile wrote: »

Please, if I may ask. What was the difference in the URLs? Also, how did that compare with the instructions within the SugarCube 2.x in Twine 2 guide?

Main difference seemed to be the handling of spaces in file names, which doesn't explain why Twine wasn't working right with the one above quoted link, where I removed the space, but I assume that had to do with preferences getting corrupted.

After I tossed all my preference files, the difference in links is this:

UNIX shell link:
file:///Applications/_game\ making/_game-making_applications/Twine/Twine_2/offline_formats/SugarCube-2/format.js

URL link:
file:///Applications/_game%20making/_game-making_applications/Twine/Twine_2/offline_formats/SugarCube-2/format.js

The instructions in the SugarCube documentation don't specify which type of link to file is needed, just that it needs a link.

It's possible there's something else going on—like maybe I had an extra space at the end of the first link, when I tried using it—but I know the URL from the browser worked, so… [shrug]

TheMadExile

Carradee wrote: »

UNIX shell link:
file:///Applications/_game\ making/_game-making_applications/Twine/Twine_2/offline_formats/SugarCube-2/format.js

URL link:
file:///Applications/_game%20making/_game-making_applications/Twine/Twine_2/offline_formats/SugarCube-2/format.js

The problem is that the space in _game making is not valid within a file URL and must be percent-encoded, as you can see in the latter. The backslash escape in the former is for the shell.

Carradee wrote: »

The instructions in the SugarCube documentation don't specify which type of link to file is needed, just that it needs a link.

Actually, it's quite clear that you need to use a file URL—while it mentions the path to the file, no other terminology is ever used to describe the "link" that must be provided to Twine 2. It also provides a link to the Wikipedia article on them, in case one is unfamiliar.

I suppose I could add some additional text belaboring the point.

Carradee

As I said, the link wasn't working even when I changed it to not have a space, but that could've been corrupt preferences. After I ditched the preference files, space encoding had to be figured out.

I didn't see that file URL link before. Step 6 does refer back to step 2, which says "take note of the path to it"—so it references both UNIX path and file URL. Contradictory.

ETA: So you could fix step 2 in order to reference the file URL and have the link, so step 6 is clearly referring back to that, rather than defining what you mean outside of the explicit references to it (which is what the current structure effectively does).

TheMadExile

Of course both are mentioned, as I pointed out in my previous reply, as you cannot create the file URL without knowing the actual path to the file. That does not, however, change the fact that it's the URL that you must use in Twine 2.

Regardless, I'll see if I can't make the instructions clearer.

Carradee

You can right-click and open the JavaScript in your browser. That'll give the file URL. No need to know the path.

TheMadExile

You're making an assumption that because it worked for you, with apparently little fuss, that it will work for everyone else just as readily.

My right-click context menu allows me to send the format.js file to exactly one browser, which refuses to load a naked JavaScript file. I sincerely doubt that I am the only one for whom your method will not work without altering settings—not something you can depend on people being willing to do or knowing how to do in the first place.

Carradee

Surprises me that it doesn't work for you, since I've done that sort of thing across multiple systems and browsers (over years, so things could've changed in non-Mac setups since I last used them), but hey, diff folks and system setups do differ. (Did it not even encode? Loading the JS shouldn't have mattered—and you know you can override the "recommended applications" thing, right? Sometimes unrecommended programs work better than recommended ones.)

That still leaves my point of item 6 and item 2 conflicting with each other, as written (unless it's been changed since we started this discussion). If you already know what they're intending to mean, they make sense, but if you don't? They could be read multiple ways.

Anyway, here's me tossing my stick away from the dead horse. I'm just one of those people who tends to get paid to double-check clarity and comprehension when either is potentially in doubt, and I still have the sense that we're still not talking about quite the same thing—but this has hit the point of "more frustrating than helpful".

Hope you have a great weekend!