There’s a CORS error occuring with some TADS 3 games via Parchment across browsers. It doesn’t seem to be all of them (for example, According to Cain is fine). I’m not sure what the pattern is.
What you’re describing is consistent with the behaviour you see when you’re in the UK, which is still geoblocked by the IF Archive. Is it that case that “play online” links to the Archive unboxing service are the ones that fail and links to story files hosted elsewhere work? Is it possible that your internet connection is being identified as originating from the UK for some reason?
EDIT: Sorry, with less Gen-Z in my veins this time: Was my game removed from the archive, or…? I thought I would have been emailed about that, if it happened.
EDIT 2: Oh, I guess a geoblock would also look like file removal, huh?
unbox.ifarchive.org is currently experiencing downtime. Some URLs still work, because they’re cached in Cloudflare, but the underlying service is down. @Dannii
full hard drive problem related to parchment or IF Archive ? in the latter case, is worrisome, because everyone known that by early september will be uploaded a very sizeable .zip file which WILL be accessed by scores, if not hundreds of online players…
More specifically ? The unboxer is at the core of IF online playing, and the prospect of scores of online IFComp judges requesting unboxing from the big IFComp .zip file is my main worry in light of this issue…
Since, as you say, the IFComp Big Zip is generally the largest zip file of the year, we set a flag to make sure that unbox doesn’t touch it. If you look at Index: if-archive/games/competition2025 , you’ll see that IFComp2025.zip has no “view contents” link; only the individual game zips do.
(* I should say, virtual machines hosted by Linode. They’re not physical boxes, but they’re configured as distinct Linux servers and each one has its own RAM and disk quota.)
The Unboxer is actually perfectly happy to unbox the big ifcomp zips, though it does need to evict a lot of other zips out of its cache to do so. I’m pretty sure there’s some kind of race condition which means that files aren’t being deleted from the cache when they’re meant to. I’m thinking of just running a script on a timer to check if the cache is bigger than it should be because even though it wouldn’t be fixing the underlying problem it would still stop the server from dying.