Issues Dynamically Loading Assets in Production

Issues Dynamically Loading Assets in Production


When we released the latest version of our game (3rd release, but first time with a large number of players), many, but not all, users randomly had issues dynamically loading a wide range of assets (via cc.loader.loadRes or cc.loader.loadResDir). This occurs at all different points throughout the game (when trying to load assets), and only occurs within our production environment. The game is built on Cocos Creator 2.0.9 for a web-desktop platform and is published to Facebook. We enable MD5 when building the project and have confirmed new hashes for main.js, project.js, and settings.js.

We are currently in the process of trying:

  1. Deactivating our CDN’s temporarily
  2. Incorporating cc.loader.md5Pipe.transformURL(url) when loading assets

But would like to ask for any additional ideas in solving this issue because we are quite frankly stumped :smiley:

Thank you in advance for any help!

P.S. Separate but perhaps related topic: Whenever we build our project in Jenkins using the following command, the hashes for the built files do not change:
C:/CocosCreator/CocosCreator.exe --path . --build "platform=web-desktop;debug=false;md5Cache=true;sourceMaps:false;buildPath=./release"

Any ideas why?


I was able to reproduce this error in my dev environment, but I don’t think this is the issue that our players are having, because for them, the problem goes away when they clear their browser cache. Either way, this is a concerning issue, so I’m posting an update.

After building (with MD5 enabled), one of the assets I was trying to load randomly did not have a hash assigned to it:


Of course, when I try to load this asset, I get a 404 error: Invalid Format. When I try the URL without the hash, it works. This is an older asset that has not been changed in a while. Any idea why Cocos might have randomly skipped this one?

Also, to address the P.S. from my original post, it appears the npm package gulp-rev-all is used when you enable MD5, and settings.js and initialize.js always get new hashes with new builds, but project.js and thus main.js only get assigned new ones if the logic of the code has changed, which makes sense :slight_smile:

perhaps you can do a dirty workaround, like a post-build script that checks that files in “res” folder match the format of something.md5hash.extension and if not, manually generate the md5 hash and rename the affected file? though i’m not sure if then you have to change the settings.js as well…

Check the build log. Is there any error? Could be the file was being used by another process and couldnt overwrite?

@Karg We attempt to load an asset several times before giving up, so my hack idea for this particular problem is to attempt to load without the hash after failed attempts. This way, settings.js doesn’t have to change either :upside_down_face: Has this happened to you before, though?

@StudioAMK That’s a good thought, but unfortunately there were no errors in the build log, and the asset wasn’t open/being used by anything else.

Once again, though, I don’t think this is the issue that our players are having as they say the problem goes away when they clear their cache :thinking:

i don’t think i’ve encountered any loading errors because of missing md5 hashes, but, in all honesty, i use loadRes sparringly.

when you load things with cc.loader.loadRes/loadResDir, what kind of errors/exceptions are thrown? is there a pattern, e.g. only happens for images, or for sounds, or for jsons, facebook-related things (e.g. profile pix) or for just about anything?

are the loading errors more frequent after a release?

could it be that perhaps you’re trying to load too many things at once?