Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Twine 2.0/Harlowe Images and Dropbox
I have a story in Twine 2.0/Harlowe that makes use of many images. As a test run, I put images in Dropbox and referenced them with proper addresses and such. They show up in the story fine... as long as it's on the desktop used to link them, and nowhere else. I'm working in browser, so I can get them to show whether it's Chrome or Firefox.
I need to get these images visible on someone else's machine, not just mine, without a lot of work.
But if I Publish to File, copy to flash drive, and hand the flash drive off to someone else, the links break. This happens even if the second computer is the owner of the Dropbox folder where the images are stored... they definitely have permission. And the breakage also happens if I use a second computer and can sign into Dropbox using my account.
The only solution seems to be to open up the Twine file editor, once for every new computer, and manually recopy every single link. This is an effective workaround, but clearly an impractical one. My audience is strictly internal/co-workers at the moment, with whom I can share Dropbox access, but I'm not telling my readers/players that they must paste in all the art addresses.
Other potential solutions I see but might waste my time:
* Web hosting of the images rather than Dropbox
* Saving all images to flash drive and praying the file extension remains the same when slotted into a new machine
There's got to be an easier way... what am I missing?
Thanks in advance.
I need to get these images visible on someone else's machine, not just mine, without a lot of work.
But if I Publish to File, copy to flash drive, and hand the flash drive off to someone else, the links break. This happens even if the second computer is the owner of the Dropbox folder where the images are stored... they definitely have permission. And the breakage also happens if I use a second computer and can sign into Dropbox using my account.
The only solution seems to be to open up the Twine file editor, once for every new computer, and manually recopy every single link. This is an effective workaround, but clearly an impractical one. My audience is strictly internal/co-workers at the moment, with whom I can share Dropbox access, but I'm not telling my readers/players that they must paste in all the art addresses.
Other potential solutions I see but might waste my time:
* Web hosting of the images rather than Dropbox
* Saving all images to flash drive and praying the file extension remains the same when slotted into a new machine
There's got to be an easier way... what am I missing?
Thanks in advance.
Comments
In the past anything placed within the Public folder (like media files) could be easy accessed by people other than the owner of the account, but this is no longer the case as explained here.
The Share on dropbox.com > Share a link section of the Give people view-only access to your files page of Dropbox help explains how to create a share link. By default the share link they generate leads to a page where the media file can be downloaded, you need to change the dl=0 at the end of the URL to dl=1 if you want to access the image directly.
The following example show how to show dropbox hosted image as a Harlowe background.
html { background-image: url('https://www.dropbox.com/s/wday49trengwfhq/some-image.jpg?dl=1'); }Re: Saving all images to flash drive.
If you don't have your own web-server to host your images on then I personally believe that this is the better option. As long as you use relative URLs that are relative to the location your story HTML file is stored in then there should be no issues with others viewing those images (as long as you supply them a copy.)
I generally create a new folder per project and store the story HTML file I create using the Publish to File within it. I next create a sub-folder (named media) within the project folder to store all my media files in, and I use an URL like the following to reference a media file.
html { background-image: url('media/some-image.jpg'); }When I want to send a project to someone to view I create an archive file (eg. ZIP) that contains both the story HTML file as well as the media sub-folder and it's contents.
And as I work on several computers in the office, at home and on the road, my local working folder is put on a clone of the Github repository on Dropbox.
And finally, I use a small widget for displaying medias in the passages.
<<widget "auto-image">> <<nobr>> <<set $image to $online_medias_url+passage()+".jpg">> <figure> [img[$image]] <figcaption>$args[0]</figcaption> </figure> <</nobr>> <</widget>>I don't know if that workflow is a good way to do, but I like it...
As I explained in my previous post a Dropbox URL needs to end with ?dl=1 to force their web-server to send you the actual file as the response to your request. So at minimum you will need to change the <<set>> macro in your widget to something like:
My issue with using a file hosting service like Dropbox to host important media files is that unless you are paying them (have a contract) then you have very little control over the files you store there. Otherwise they choose if/when they allow others to access your files, they can block access to the files if the traffic becomes too high, and they can delete the files if they deem it necessary.
I have a little more confidence in Github than in Dropbox... And as I have local copies and a domain registrar distinct from my free Dropbox hosting service for the custom domain name, I could always painlessly migrate my work...
I'm not in trouble with other accessing my files, because all my texts, pictures and son on are released under Creative Commons BY-NC-SA since I ever published on the Web.
You can see the result here in the Little Planet I wrote about for some days.
Hmm, it looks like they're changing things in March, which, given the way my luck is going, could start a new round of links breaking even if I get it right now. Perhaps sending the files and telling the recipient to copy them properly is a better bet.
None of the images I have use a URL that ends in dl=0 or dl=1. The art I'm using is not for the purpose of background images. They use the "img src=" command. For example,
<img src="https://photos-3.dropbox.com/t/2/AAD93Izur22vCKMTcPPUFtKiU3CTDf3ccgbfV1wGwFKCyA/12/499269786/png/32x32/1/_/1/2/PartheniaWings.png/ELiT6oYEGDAgAigC/RxKfjsASqc7p1XcRlb6dKrbjXMze35Qvz1fNmhQ8ADY?size=800x600&size_mode=3"; height=375 width=304>
I'm trying this now, but it has a few setbacks.
1) Creating an extension for the flash drive works for Twine 2.0 when I access it via a hard-drive-based version but NOT for my browser-based version. It seems the hard-drive version will accept flash drive extensions but not Dropbox, and browser-based versions will accept Dropbox but not flash drive. When the image source and the Harlowe version conflict, the images don't display and I am back to square one.
2) If I e-mail the art to the intended audience, I will have to tell them to copy the files to Desktop or something similar... which will have to get around the fact that my desktop file extension will say "C:\Users\myusername\Desktop" and theirs will say "C:\Users\theirusername\Desktop." Again, 40 art files will break and I can't ask the audience to correct them all by hand.
3) If I save it to a flash drive and give them instructions saying "copy this to your own flash drive," all I have to do is have a file extension on my flash drive that matches theirs exactly: ("F:\Twine_Art_Archive\ImageNameHere") -- so I can just do one pass through the story and it will match up once they install their own copy on F:\. This will have a few requirements: they will need to have a port that matches exactly (i.e. the F drive and not an E or G or something); and they will need a flash drive to play it. Me sending them my own physical flash drive is a less than optimal solution because they're in Beijing. (Hopefully their computers' Mandarin interfaces won't choke on my instructions.) But at the moment, this seems like the optimal solution, because web hosting no doubt carries its own learning curve.
4) I could also download Twine 1.4 and see about the difficulty of copy/pasting into a format that supports images better.
Any helpful input that could help me test this out is appreciated.
I described a method using a folder and sub-folder that is used by many people to access locally referenced images in a Twine based Story HTML file, the technique works for both images referenced in CSS as well as those referenced in an img element's src property.
An img element referencing the same local file as my previous example would look like: ... you should never include full drive information when referencing a locally stored image.
This option will only work correctly if the total size in MBs of all the embedded images is not too large otherwise the application will run out of memory when trying to build a Story HTML file. The exact limit is not known (because it depends on a number of things) but it is generally somewhere between 50-100MBs.
Thanks a ton for this. It's saved me considerable frustration.