Common resouces for HTML5 projects

#1

Hi,
I have multiple projects that will share part of the resources: instead of copying multiple copies of the same resources in several assets/gfx folders, specified in project.xml like this

<assets path="assets/gfx" />

I’d like to specify an upper level folder like this

<assets path="../commonRes/gfx" />

Is this possible? I already tried to do this, but preloader stops loading at about 95%, in the console (Chrome) I read

Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:2000/commonRes/gfx/aniBG_.jpg

EDIT: ok, locally I can’t have a folder level upon root, trying a different strategy…

#2

Try <assets path="../commonRes/gfx" rename="commonRes/gfx"/>.

#3

It works!
Thank you!

#4

Or use the “include” XML tag to import a shared project XML :slight_smile:

#5

You mean like this?

<include path="industrial/application.xml" />
    merge(new ProjectXMLParser("industrial/application.xml", defines));
#6

Well, no, wait, it worked because I didn’t noticed that using “rename” I created a local folder, that was not at the folder level I wanted.

My folder structure is

commonRes/
projectFolder/
	Assets/

if I use

<assets path="../commonRes" rename="commonRes"/>

and compile, I obtain the folder structure

bin/
	index.html
	Assets/
	commonRes/

but what I need instead is

commonRes/
bin/
	index.html
	Assets/

so I can put more projects online and obtain this structure

commonRes/
binA/
	index.html
	Assets/
binB/
	index.html
	Assets/
binC/
	index.html
	Assets/
binD/
	index.html
	Assets/

all sharing commonRes/ folder, that must be seen as …/commonRes/

How can I do this?

#7

I mean like this:

shared/include.xml

<assets path="Assets" rename="assets" />

MyProject/project.xml

<include path="../shared" />
#8

I’m lost, please can you explain this with an example?

#9

Make a folder with your shared assets, make an “include.xml” file with relative paths to any assets you want in your shared stuff.

In your project, use an <include /> tag with the path to your shared directory, or the include.xml file directly. The tools will find the include.xml file and pull in the defines, haxelibs, assets and other things you put in your shared location

#10

It works!
But… how the h**l does it find the shared folder even if I change the level of the complied folder path?! It is like magic, unless I missed something…

#11

This is compile-time, so it’s relative to the location of your project.xml file :slight_smile:

#12

And it works even if I copy the compiled project to another folder, at a different level, I am still wondering how this is possible… :fearful:

Anyway I will do other tests, mainly with post-build script to centralize the compiled projects: I will report the progress in Change compile path

#13

Well, when it compiles, it copies the files into your Export directory, just as it would ordinarily. It just uses your shared XML file, so you don’t have to copy and paste all that stuff into all your project files :slight_smile:

#14

Oh s**t! I didn’t notice it (because the shared assets have the same folder structure of the local ones): no good, I have to share the same folder, not the same assets doplicated for each project!

Ouch… :sadpanda:

#15

So these aren’t build-time dependencies, you want to share a common folder of assets on your server?

You could try using something like:

<assets path="assets" rename="../shared/assets" />

I’m not quite sure if the tools would be alright with this. You could also copy files yourself, and use Loader manually (like the good 'ole Flash days)

#16

For now I am going to stay with the duplicated assets, they are just XML files and shouldn’t take much space on the server, I just need to update all of them each time I update the compiled projects on it.

#17

Revive!
Now I am trying to use both shared assets and local assets, and I’d like to overwrite the shared ones with local ones, if they have the same name.

In my project.xml I have

<include path="../_SharedAssets/shared.xml" />
	
<assets path="Assets/Audio_MP3"	type="audio"	rename="Assets/Audio"	unless="html5" />
<assets path="Assets/Audio_OGG"	type="music"	rename="Assets/Audio"	if="html5" />

and shared.xml contains

<assets path="SharedAssets/Audio_MP3"	type="audio"	rename="Assets/Audio"	unless="html5" />
<assets path="SharedAssets/Audio_OGG"	type="music"	rename="Assets/Audio"	if="html5" />

I thought this would write SharedAssets/Audio_XXX to Assets/Audio, and then Assets/Audio_XXX to the same folder Assets/Audio, overwriting files with the same name.
What I find instead are the files from SharedAssets/Audio_XXX folder, so the possibilities are two:

  • assets cannot be overwritten at compile-time
  • include xml is processed AFTER the local assets

Do you know what is happening when compiling?

#18

Try disabling the shared paths for a moment, and confirm if the files copy.

I have a feeling it’s using “copy if newer” logic, so it’s respecting the file modification time

#19

Disabling include/shared paths I confirm files copy correctly. I also checked the files date: Assets files are newer than include/shared ones, but they are not overwritten over the shared ones.

Xml lines order is usually meaningless, so I think that include/shared tags are always processed before or after assets ones, anyway if it is true that the compiler keeps the newer files, how comes I have older versions of files that are in both include/shared and assets paths?

i.e.:
Assets/Audio (assets path) contains

  • file1.ogg, 4-3-2015
  • file2.ogg, 11-11-2015

SharedAssets/Audio (include path) contains

  • file2.ogg, 9-9-2015

I will obtain
Assets/Audio containing

  • file1.ogg, 4-3-2015
  • file2.ogg, 9-9-12015

It would really help knowing if include paths are processed before or after assets ones: the test suggests that the order in the xml is not relevant, as I obtain the same result by setting both assets/include and include/assets order.

#20

The XML processes down the list, but copies only on the “update” step after processing the project completely. Update currently uses “file is newer” logic. Perhaps we could disable this, though I assume it helps with performance when there are a lot of files?