Closed WumboSpasm closed 1 year ago
The problem are the relative URLs you are using in https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/kelti.wrl. Normally relative URLs are resolved agains the scene's URL. For instance "sever.jpg" would be resolved to https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/sever.jpg.
But when the scenes URL is a blob, the relative urls cannot be resolved anymore, because there is not knowledge about the URL https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/kelti.wrl.
For this case, there is the possibility to set the baseURL of the browser, see https://create3000.github.io/x_ite/reference/browser-services#baseurl, which would be in your case look like this:
player.browser.baseURL = "https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/kelti.wrl";
My code does use baseURL
- I just didn't include it in the linked fiddle because the issue occurred regardless. However, it seems like it's been fixed now. Thank you for the swift response!
I'm developing a web frontend for the Flashpoint Archive that loads files from zip archives and uses open-source players such as Ruffle and X_ITE. While refactoring the code, I noticed that if a multi-asset world is loaded from a
blob:
URL created using theURL.createObjectURL()
method (which is necessary when loading from a zip), X_ITE would get stuck on the "Loading X files..." screen with no errors present in the console. Single-asset worlds, on the other hand, load without problems.I previously avoided this issue by overriding the
fetch
method so it would serve files from zips. However, this override was primarily meant for Ruffle and has the ability to cause a slew of other issues.Here's a very simple example of the bug in action: https://jsfiddle.net/u8nhfk0o/2/