It seems that after the 5/21 update to Forge, the special textures for Dice So Nice are encountering an error when trying to load. I’ve tested this across multiple computers and with both Chrome and Firefox browsers and it’s failing consistently on each, though with different errors between Chrome and Firefox.
I’ve also tested this on my local install of Foundry (which I keep for module writing and testing), not hosted on the forge, and both in the client and loaded into a web browser, the dice are loading perfectly fine.
On both Forge and my local machine I am using Foundry v0.7.9 and a slightly modified version of Dice So Nice based on v3.3.4 to include some bugfixes introduced in later versions not compatible with Foundry 7.9
Here is a screenshot from my local Foundry install of what the dice should look like:
Here is a screenshot of what the same dice settings look like on Forge:
This is a screenshot of the error on Chrome:
This is a screenshot of the error on Firefox:
That looks more like you have an issue with your Custom Dice So Nice module than anything, WebGL is specifically failing to do something (or being blocked by your browser).
Also very hard to provide support for a custom hacked-up version of a Module for a now quite old FoundryVTT version. Why are you sticking on 0.7.9?
I don’t think it’s a browser issue, since my local Foundry install loads the textures just fine on the browser, as seen in my first screenshot. The first and second screenshots were both taken on Chrome.
I still use 7.9 only because I have a ton of modules installed and some of them don’t work well together on later versions of Foundry and I haven’t been able to find any alternatives.
I’d at least try to re-upload your custom Dice So Nice then, because every error there is about your module having a busted texture it can’t work with.
What modules do you have you can’t find alternatives to? Honestly, you’re missing out on SO much not being on FoundryVTT v9, it might be time just to drop the offending modules and move on up (taking backups beforehand of course).
Another important note here: Server update changelog - #163 by kakaroto
Nothing in there is anything about how Forge works/operates underlying for loading things.
You could try opening Dev Console + Right-Click reload arrow and click “Drop Cache and Reload” to see if you’ve got a bad browser cache of the files from Forge.
Thanks for the advice. Just tried reuploading the module, disabling and reenabling and still the same issue. I tried clearing my cache and cookies prior to my original post, with no improvement. I ran a game on 5/18 with no issues, but only today when I opened it to do some prep were the dice broken.
I really want to update to v9 even just for the performance improvements. The two modules I have the most problem with are Conditional Visibility and Multilevel Tokens. Because of the way the new author of Conditional Visibility reworked the effect handling, and because of the fact that the newer versions of Multilevel Tokens strips the actor data from cloned tokens, the visibility flags aren’t passed to cloned tokens. The newer Conditional Visibility is also much harder to use in general.
I’ve never played with Conditional Visibility, I think I looked at it briefly, but never played with it.
Totally get having a flow and not wanting it disrupted, but it might be time to take the plunge. Could also mean this issue clears up, since you’re using official modules.
Can you open the Dev Console (Press F12), click on the “Network” tab, and then reload your FoundryVTT tab? specifically look for things that errored out when loading:
(Like this image I failed loading on purpose here)
Post screenshots of the network tab sorted like this if you can.
Scrolled all the way through and there were no 400 or 500 level errors for any file, but all the webp files for Dice So Nice seem to have loaded once with a 307 redirect response and then again with a 200 response:
On my local version, the webp files seem to be loading only once with a 304, so maybe the redirect is what’s causing the issue? That would make sense given the console errors
307 + 200 is just how The Forge works, it’s redirecting to the actual Assets Library URL that your custom module has its files hosted on, so that should be fine.
I’m not to sure at this point, I’ve not had any issues like this, but I’m also not using a custom (and old) version of a module. Sorry I couldn’t be more help.
I ended up reverting to the official Dice So Nice v3.3.4 and it started working again. I had to edit it in the first place because one of my players was having an issue with it so I guess I’ll have to figure something else out.
As a note, after reverting to an official version, the webp files stopped loading with 307 responses and then 200 responses later, they only loaded once with 304 responses as seen here:
Hi,
Yesterday’s update did indeed cause your issue. There was an old issue in Foundry due to a buggy version of PIXI (the canvas Foundry uses) I believe, which was causing redirects to fail due to CORS (the specific details is that Foundry would see a texture under "/relative/path’ and would not enable CORS on it, and when the request ends up being redirected to assets.forge-vtt.com (a cross origin request), the canvas would fail because “CORS request was not enabled” or something like that, even if the server was correctly answering the CORS request. It was a very weird error).
I had temporarily (2 years ago) made it so that we just proxy things to the assets library internally instead of redirecting to it. This is a very inefficient and impractical solution, but it worked. I’ve tested 0.8.x and v9, and that issue is not there anymore so I reverted the code to do a redirect instead of proxying, and that caused your issue as you’re still on 0.7.9.
Note that this issue only happens because DSN is trying to access files that do not exist in your Data folder (i.e: Foundry is returning a “404 File Not Found” error, and the Forge intercepts that error, finds the image with the same path in your assets library and redirects there instead of giving you the error).
It works with the offiicial release with the 304 (Not modified) because the files actually exist in the Bazaar, they don’t if you upload the module as custom, since the images get sent to the assets library.
If you want to keep using your custom module AND stay on 0.7.9, one suggestion would be to make DSN use the links in your assets library instead of local relative paths when trying to load those images.
I hope that helps!
1 Like
I stand corrected 
Sorry about my misdirect here
My bad, I did forget to mention that change in the changelog
