HiEv
commented
4 years ago If you take a look at my "Displaying Images in Twine" sample code, it shows how to work around that problem. Basically, it attempts to detect whether the HTML was played normally or if it was launched from Twine, and then it either uses a relative or an absolute path, respectively. (You can click "Jump to Start" in the UI bar to see other sample code there.)
Another option is to simply publish your story to wherever you want, open that HTML in a browser, and then, when you make a change you want to see, simply publish again and then hit CTRL+F5 in the browser to refresh your view.
As for whether the issue you're talking about "could be simply fixed", I don't think it's that simple. First of all, what you're describing wouldn't even be possible in the online version, due to how browser security works. And in the offline version, normally all of the information about a story is stored within the story itself. The model would have to be changed to store other information about each story somewhere else, and that information wouldn't be included in the archived or published files.
I've suggested to the developer adding a better way to detect whether a game is launched from Twine or not (#620), which would make the solution I suggested up top work much more simply.
Hope that helps! :grin:
howtophil
everythingability
Hello,
this is a feature of Twine that causes me, and my students, SO MANY issues that doesn't need to exist.
The problem is this:
When using media with Twine (locally) you can't just put the media in the same folder as the Twine file because it doesn't exist - or rather it does, lurking in the bowels of the /tmp folder somewhere. So a student can't create a story they use media that is already hosted online.
Processing solves this problem easily, lessons could be learnt from the way it handles it. But I would propose a simpler solution.
When you create a project -> SAVE THE FILE then... into its own folder (with the same filename). For example "My Lovely Game" would be in a folder called "My Lovely Game" and called "My Lovely Game.html". In that folder Twine could create an "assets" folder... or one might create one.
Then I could simply refer to files like this {embed image: "assets/my logo.jpg"}
It could be called "media", or whatever, doesn't matter. In fact it doesn't have to create a folder, but just the notion that relative media could be downwind of the working file (always) is what's important.
THIS WOULD HAVE THE MASSIVE ADVANTAGE that media was relatively referenced and I could just, at the end of my project, move the whole lot onto a hosted server and it would work with NO CHANGES.
Of course I could use hosted media still if I wanted.
There would be another MASSIVE ADVANTAGE in that, Twine could be configured to save after every passage is closed rather than requiring to Publish to file. This would mean I could keep the same window open and refresh, rather than rack up umpteen open windows etc.
I mentioned Processing, well, it lets you start work on a file, and assigns a folder to it. In there you can create a "data" folder ... but when you SAVE your work, the data folder is moved with it... so all relative references still work.
This would make teaching Twine SO much easier, because currently there is no good way to manage media in Twine, but there could be.
My preference would be for there not to even be the /tmp working copy... and by NAMING AND LOCATING the project at the beginning, rather than on Publish to file... an author would be able to start their story, add a few images (I too am a fan of not using "too many images") to the same folder (or folders within that folder) and create stuff very easily.
I know this means REWORKING how it all works, but in my opinion this makes loads of sense, makes it easier to author with media, easier to publish. Previously I created a variable that detected IF I was hosted or local and swapped paths accordingly (but teaching that to students feel all kinds of wrong).
Thanks.