Import Additional Javascript

[mike-koch]

Is there a way to easily import additional Javascript source files (either via HTML or JS) into a skin? I've tried using:

$.getScript('myJavascript.js')

However, since the URL is relative, the path becomes something similar to http://localhost:25555/myJavascript.js, instead of going to the skin's directory (I'm assuming this is due to how the server is written). Additionally, I cannot assume the skin name will be the same as users can change it.

That being said, are there any helper functions that can assist in importing additional Javascript files?

[denilsonsa]

Alternatively, et2-telemetry-server could provide a "shared" folder, available for all skins.

---

Context: in ets2-mobile-route-advisor#2 we were able to slice up the map you made into 7381 tiny images and serve them in user-friendly map UI. The next step is putting the map inside a skin.

However, other people might also want to make skins containing a map, so instead of copying all images and JavaScript files to each skin, such assets could be stored in a shared folder, available for all skins.

(even better if we could store all the images inside a ZIP file, and the server could serve them from the ZIP; but that requires more work)

[Funbit]

@mkoch227 You may try to load the script inside "initialize" skin's function using skinConfig.name property to construct the full path, i.e.: "/skins/{skinConfig.name}/myJavascript.js". Just as a temporary solution.

@denilsonsa I'm very glad that you guys managed to create a tiled version of the map! As for the shared folder suggestion, I'll try to come up with something this weekend, probably will add support for a shared map and additional javascript/css files defined inside skin's config file. I'm not sure that ZIP support would worth it, we're living in the world where it does not matter if a folder is 5mb (zipped) or 10mb (unzipped).

[denilsonsa]

Regarding the suggestion of zip support: sure, 32.8MB of disk space instead of 8MB is not a big deal. The issue is that some systems struggle when working with thousands of tiny files. My windows system takes a while to create/copy them. At the same time, it is done only once, so it's not a big deal anyway.

(Zip support is still something "nice to have", but only if implementing such stuff is trivial, if you have a library to directly read files from zip archives.)