FlxG.assets: A way to overwrite and customize the way HaxeFlixel fetches or produces assets from ids

[Geokureli]

Fixes #2953

AssetsFrontEnd

Accessed via FlxG.assets. The main interface for the asset system. By default, OpenFl's
Asset system is used, which uses relative path strings to retrive assets, though you can completely
avoid Openfl's asset system by setting custom methods to the following dynamic fields: getAssetUnsafe,
loadAsset, exists, isLocal and list.

Common Uses

The initial reason for making customizable asset system
was to allow for "hot-reloading", or testing new assets in your game without recompiling, with
each change. Say, if you would like a debug feature where you load assets from source assets,
rather than the assets copied over to your export folder, you could overwrite this system to do
just that.

Other potential uses for this are modding, bypassing the manifest and loading resources from
a remote location.

Quick Setup for "Hot-Reloading"

To simplify the process mentioned above, the FLX_CUSTOM_ASSETS_DIRECTORY flag was created.
By adding -DFLX_CUSTOM_ASSETS_DIRECTORY="../../../assets" to your lime build command
it will automatically grab assets from your project root's assets folder rather than, the
default "export/hl/bin/assets". This will only work with a single asset root folder with one
asset library and will use the openfl asset system if the asset id starts with "flixel/" or
tries to references a specific library using the format: "libName:asset/path/file.ext".

To Do

• Add coverage and/or unit tests Nah
• Check if sys, or implement on html or other non-sys targets somehow
• Rename to singular AssetFrontEnd (check other front-ends for pattern)

[moxie-coder]

if I’m being honest, this is a very good change since it helps reduce imports (removing the need for openfl.utils.Assets) and makes code cleaner in general, so I like this so far

[T1mL3arn]

There is some problem with async text/binary assets. They are not cached by lime. This can lead to inconsistencies between html5 and sys targets: a user expects to get the cached asset with FlxG.assets.getText('atlas.json', true) but instead receives error asset "atlas.json" exists, but only asynchronously.

// Project.xml
<assets path="assets" embed="false" preload="false"/>

// Main.hx
openfl.Assets.loadText(AssetPaths.atlas__json).onComplete(json -> {
    // error on html5 "asset "atlas.json" exists, but only asynchronously"
    trace(openfl.Assets.getText(AssetPaths.atlas__json));
});

Possible solutions:

• use the same cache rules for text/binary as lime does - no useCache param for getText() getJson() etc
• flixel maintains its own text/binary cache for non sys targets (sys targets treat any asset as local, so such asset is read from file system when it's not cached)
• make Lime team to implement cache for text/binary

[Geokureli]

There is some problem with async text/binary assets. They are not cached by lime.

The purpose of this PR is to add the ability to override the functionality of how flixel loads assets from string paths, I created FlxG.assets as an easy place to find this feature (and perhaps various other asset related features).

What you're describing seems like a separate feature related to flixel's asset system, which may or may not be implemented regardless of whether this PR is merged. Do you agree? If so, I would make a new issue, if not, I may need you to elaborate, cuz I'm not seeing the relevance

[T1mL3arn]

I may need you to elaborate

At brief look this pr api suggest text/binary assets can be cached, but in fact - they are not. May be it should be more clear in doc about that.

a separate feature related to flixel's asset system, which may or may not be implemented regardless of whether this PR is merged. Do you agree?

I am kinda agree. This pr fits for text/binary asset cache feature in a way that without new asset front-end it's hard to implement the feature.

[EliteMasterEric]

This would be great to see implemented. It would improve some of the issues I've had with overriding asset loading with Polymod.

[TechnikTil]

10/10. That's all I'm saying.

[Sword352]

Just making sure, is there any breaking changes with the introduction of these new features?

[Geokureli]

Just making sure, is there any breaking changes with the introduction of these new features?

There are never breaking changes on a minor release, if any PR causes breaking changes then it must be released in the next major version, i.e. 6.0.0, where this is for 5.9.0

Also any PR with breaking changes will list them and tips for migration. It will also use the "Breaking Change" label