OpenFL: XmlLoader can't find files at runtime

[Tiago-Ling]

Hi, i have been trying to use mloader with OpenFL, however, the loader does not find any assets at runtime. Example (file tree):

/bin
    application.swf
    asset.xml

Trying to load asset.xml:

var loader = new XmlLoader("asset.xml");
loader.loaded.add(onLoaded);
loader.load();

Returns this error:

Assets.hx:220: [openfl.Assets] There is no String or ByteArray asset with an ID of "asset.xml"

I know it works if i put the asset.xml file inside OpenFL's asset folder, but doesn't it defeat the whole purpose of using a loader?

I'm using the latest version of the libs from Haxelib: OpenFL (1.0.6), mloader (2.2.0), Haxe (3.0.0).

Sorry about posting this as an issue (this may well be a misuse of the lib on my part), but there is no other place to post questions or comments about the library.

Thanks!

[dpeek]

Hi! To be honest mloader hasn't been used extensively with OpenFL, you'll notice we only recently added support for it (switching from NME).

One problem you have to deal with in OpenFL is the different behaviours of the platforms. In Flash/JS you can load everything over Http, on native you have to use Http for remote resources, sys.io.File for local resources. I'm also not sure what the differences are regarding file system access in native applications – is the current working directory always the application package?

The approach at the moment is to load anything that starts with http:// as normal, and to defer to the asset API for everything else. I agree, this isn't ideal.

Perhaps you could think about some of the use cases around this and report them here so we can make things better?

[Tiago-Ling]

Hi David! Yeah, i agree it's not so simple to deal with multi-platform use cases. However, i think mloader shouldn't use the Assets class for all platforms. The way i see it, whenever possible openfl.Assets should be used directly by the end user, there's no need to abstract it even more.

The loader functionality for at least some of the targets (like Flash and Desktop) should be the same on OpenFL as it is in pure Haxe. Instead of using compiler defines like "nme" and "openfl" this can be treated per target (i.e. using #if (flash | desktop)): this way the loader would function the same regardless of OpenFL.

As far as i know, at least on flash and desktop targets (I have tested this on flash, windows and mac) flash.net.URLLoader works normally on OpenFL to load local files with relative paths to the binary location (absolute paths should work also).

I'd defer the loading to the Assets api on mobile targets for the moment and keep the functionality transparent for desktop and flash. I suppose the file locations on mobile (iOS and Android) are relative to the application package, and the way to access local stored files varies depending on the operating system.

Thanks for the answer btw, i just found about Massive Interactive's libs and they are awesome!

[Richard-Walton]

I've just experienced the same issue. At first glance I agree with Tiago-Ling's thoughts.

There is maybe some scope of integration between mloader and openfl's Assets - But right now I've commented that section of code out in my build until I have more time to think of a proper patch. In the meantime if anyone else fixes it, I'd be very appreciative.

Cheers.