CDN - dynamically change the paths of scripts and assets

Hi everyone, Hi Playcanvas-Team!

I’m working on a bigger Playcanvas Scene and trying to make it work inside a DIV because of the requirements of the CMS of the client according to this engine patch. This works well so far.

My problem: the URI of my JSON files and the assets are dynamic and not static so I need to assign then at runtime.

Example for settings.js: How to change CONFIG_FILENAME = "/images/config.json"; dynamically at runtime to something like CONFIG_FILENAME = "www8/462638/14/images/config.json";?

I think there are around 40 URIs in the scripts and JSON files that need to be updated at runtime.

Thanks a lot

Just to check, do you need this at runtime after the app has preloaded or before the preload process starts?

I think it should be before the preloading process. The CDN URI will not change after the site is opended.

The variables in the settings.js file are in the global scope.

You would need to modify the __start__.js script to change those values before they are used to configure and start the app.

Edit: It would be as simple as

CONFIG_FILENAME = 'some url';

At the top of the __start__.js file

With the scripts and assets, as long as they have the same folder structure, you can use the SCRIPT_PREFIX and ASSET_PREFIX , scenes etc to reference the base directory that you need.

Some of this will depend on how the app is structured and how this should be loaded.

Great, thanks a lot for your fast reply!

I think I’ll just overwrite ASSET_PREFIX, SCRIPT_PREFIX, SCENE_PATH and CONFIG_FILENAME after setting.js is loaded. Will give feedback on how it goes.

Thanks again

Modifying the paths worked perfectly, thanks!

Now playcanvas finds the files but a new problem came up: it can’t parse the JSONs, Chrome is giving me this error:

SyntaxError: Unexpected token g in JSON at position 0
    at JSON.parse (<anonymous>)
    at Vh (playcanvas-stable.min.js:6)
    at playcanvas-stable.min.js:6
    at Gh (playcanvas-stable.min.js:6)
    at Function.e.parse (playcanvas-stable.min.js:6)
    at e.parse (playcanvas-stable.min.js:6)
    at (playcanvas-stable.min.js:6)
    at playcanvas-stable.min.js:6
    at Object.callback (playcanvas-stable.min.js:6)
    at e.t._onSuccess (playcanvas-stable.min.js:6)

Has this something to do with the server serving the JSON file as ‘xhr’? I was reading about it, not sure if I really understand it. This is what the network tab of Chrome showing me:

Thanks a lot in advance!

Without trying it out myself with a link, at a guess is that the file is malformed/corrupted.

Has the server been setup with the correct mime-type for JSON files?

If you went directly to the URL for the JSON files, do they have the correct content?

In the columns of the devtools under network, add the ‘type’ column, what mime type does it give?

1 Like

Thanks a lot. Unfortunately, the server is behind a VPN so I can’t send you a link.

Yes, they have the correct content if I go directly to the URL of the JSON files. Same size + same content when compared in VS Code.

It says “xhr” in the type column:

But in the response header it says “application/json;charset=UTF-8”:

HTTP/1.1 200 OK
Date: Sun, 16 May 2021 10:19:04 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"140183-1621160103000"
Last-Modified: Sun, 16 May 2021 10:15:03 GMT
Content-Type: application/json;charset=UTF-8
Content-Length: 140183
Cache-Control: max-age=0
Expires: Sun, 16 May 2021 10:19:04 GMT
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive

That’s a good question. I asked the admin but did not got any answer so far. Is the “Content-Type: application/json;charset=UTF-8” the correct type even when it’s says “xhr” in the network type of the devtools?

Thanks a lot for everything!

Without a link to the build to look at, my only suggestion here is to change out the minified version of the engine to the debug version to make the debugging easier for you:

Can you show the response of the config.json file?

The response looks like that:

and the complete response, just downloaded with chrome:

BTW: This is the project I’m working on:
Not sure if you can access it. Unfortunately I can’t send you the link to the build on the client’s server.

Thanks again!

The JSON looks valid.

Would I be able to reproduce the issue with the project? If not, there’s little I can do support wise.

The error points to a server configuration issue but the response looks okay?

What I would do is use the debug version of the engine mentioned above and inspect the response before it tries to be parsed and see if there are any clues there.

No, I think you can’t reproduce the issue with the project.

Yes I’ll use the debug version and will try to get some clues. Thanks!

Okay I narrowed down the issue, it is not the config.json or the other json files, the problem has somethig to do with parsing the gltf:
var gltf = JSON.parse(decodeBinaryUtf8(gltfChunk));
(line nr 32279 of playcanvas-stable.dbg.js)

To find out what’s wrong with the gltfChunk I logged them:

	var parseGltf = function parseGltf(gltfChunk, callback) {

		// ------------- Logging to find the JSON issue
		var str_log = String(gltfChunk);
		console.log(">>>> Log gltfChunk String() :" + + str_log.substr(0, 200));	

		console.log(">>>> Log gltfChunk direct   :" + gltfChunk);	

		var str_log = JSON.stringify(gltfChunk)
		console.log(">>>> Log gltfChunk stringify:" + str_log.substr(0, 200));

This how the log console looks:

When I download the gltf via the network tab I get an working gltf file.

Do you have any idea what’s causing this? Thanks!

Assuming that you are not loading .gltf files directly and using .glb, chances are that maybe the glb files mime type on server is incorrect.

On the phone at the moment so can’t check, look for a GLB in the network tab and check the mime type compared to how PlayCanvas serves it.

Yes sorry, my failure I’m using .glb.

On the network tab of the client’s server (with the issue):

On the network tab of my personal server (without the issue):

It looks the same to me… hmmm.

Please check the response header, it should be served as model/gltf-binary

Nope, no content-type at all:

So it needs to be configured on the server side right?

Interestingly, on my private server there is no content-type for gbl in the header and it still loads perfectly.

Edit: While we are at it: should I be concerned that the server serves the JSON files as Content-Type: application/json;charset=UTF-8 and not just Content-Type: application/json?

This should be fine.

I’m not too clued up on server configuration but it is my understanding that the response headers can change how the data is read/loaded by the browser.

@vaios or @slimbuck might be able to help more here.