So I can see two things that could be going wrong: 1) the if condition is failing so it’s not setting setup.Path correctly, or 2) the setup.Path isn’t right so it’s not finding the images.
If you use the browser inspector on the broken image, what does it show? If you look at the browser’s location bar, where is the game that you’re testing: does it have AppData in the location? (or you could put console.log(document.location.href) or alert(document.location.href) in your story JavaScript to show the location in the browser’s JavaScript console or in a pop-up box).
Also if you’re not on Windows then the code you’re using won’t work, because AppData is where it goes on Windows, not (I don’t think) on MacOS or Linux, so you’d have to adjust the if condition.
Which Operating System (brand, version, edition) are you using?
Are you using the Web-browser based or Installable release of the Twine 2.x application?
[if web-browser based] Which brand & version of web-browser are you using to run the Twine 2.x application?
As partly explained by @JoshGrams , the conditional expression being used in your 1st code example is trying to determine if the Story HTML currently being viewed:
was generated via the Twine application’s Play or Test related options.
is a HTML file, like that generated via the application’s Publish to File option.
And unfortunately that conditional expression makes assumptions that aren’t always correct, as they depend which combination of all of the above you are using.
ex 1. The window.storyFormat property being searched for only exists when the Play or Test related options of the Web-browser based release of the Twine 2.x application are being used to generate the Story HTML.
ex 2. The AppData folder name being search for in the URL is specific to Windows. So if you’re using another Operating System it may not exist.
Thanks for the quick replies, I’ll try and address both.
Inspecting the broken image shows the proper local path (if I open that link, I see the picture on a new tab). AppData indeed exists on the location bar, as does Temp, file:/// and so on. The console.log() and alert methods return the same path.
OS: Windows 10 Pro 22H2
Twine: it’s the installable 2.7.0.0 app… So there’s the first issue. Is there an alternative way for the non-browser version?
So here’s what I did, and so far, it actually works. Hopefully it will help in case someone runs into the same issue.
Everything checked out, all paths were correct. Inspecting the image would only show a tooltip saying “The image can’t be displayed”.
So I figured the only difference between the path of the play/test temporal file and the one set up inside the story JS was file:///.
if (document.location.href.toLowerCase().includes("/temp/")) {
/* Change this to the path where the HTML file is
located if you want to run this from inside Twine. */
// Running inside Twine application
setup.Path = "file:///C:/.../"; //and so on
console.log("Hello, the location is: " + setup.Path); //test log returns the path as written above
} else {
// Running in a browser
setup.Path = ""
console.log("Hello, this is running in the browser";
}
The picture is now shown when running play or test mode from Twine.
I still don’t know if this prevents Twine from making redundant backups, though. Does it?
One thing I noticed when looking at the Temporary File area of my Windows 10 operating system is the folder name is Temp (upper-case T).
Generally a URL is letter case sensitive because all other operating systems are such when it comes to folder & file names.
eg. temp and Temp would be considered two different folders, where as Windows considers them as two references for the same folder.