The mesh that does not load is random, and it will never load for the rest of the session. It will load instantly if you join a new server. This does not happen very often but it’s annoying when it does, such as your hair mesh missing.
Neither of those work. MeshContentProvider is an internal service that handles mesh data. If MeshContentProvider fails then it’s out of the developer’s control to force a reload. Please make sure you do a bit of research so you’re able to make more informed responses if applicable.
I’m having similar issues when loading into a studio session, a good quarter of the assets will just not load and they always seem to be the same ones. https://gyazo.com/19f67d280fd6b8f7439bbbcb4e445b7a
If you really want to go out of your way to address it yourself you can manually listen for fails like this with LogService::MessageOut and hotswap out the asset reference, busting the cache with an extra query parameter (E.g.: http://www.roblox.com/asset/?id=XXX&bustCache=1234)
It’s less that it can’t be fixed, it’s about how exactly to fix it being a very open question, since it’s vastly more complicated than a simple “resend the request when it fails”:
What if it failed to load because the service is under excessive strain? If you try to reload it over and over you’re effectively DDOSing an already stressed service. There are various solutions to this but it’s an example of one complexity.
What to do about versioning? The version of the asset that existed when the request was first sent may differ from the version when it eventually succeeds. This might matter or might not.
Just in general, philosophically: How much should Roblox try to hide the problem / not hide the problem? If we internally retry the asset requests, should we also internally retry DataStore requests that fail? Probably not, but where do you draw the line? Right now the line is very clear, not silently retrying web requests to make them look like they succeeded.
I see, so the issue is the distinction of valid vs invalid assets. If there’s no way of knowing if an asset is invalid (since the server may fail for valid assets at times) then you don’t know if retrying is pointless. Thanks
My players constantly see this problem in my game with random body parts not loading for the entire session. I have even had it a few times. This reflects very poorly on my game, and Roblox as a whole. Regardless of the complexity involved in solving this problem, Roblox still should should be doing something to get the asset if it fails rather than simply giving up and forcing the user to rejoin, or worse, assume the game is broken.
Even if it’s as simple as retrying only once in range of 10s to 60s later, this would probably diminish the problem for the majority of players and should not contribute too badly in the case of service strain. This is worth experimenting with.
Philosophically I don’t see the issue; this is an internal detail that the engine manages and that developers have no control over. It should not be able to fail leaving players in a half-loaded state and assuming the game is broken. Datastores are different in this respect because you are expected to handle data load / save failures and are fully equipped to do so.
With respect to versioning, I don’t think I understand? I don’t think in any situation with respect to meshes it would matter if the version at the time of the request is different from when it is retried. Meshes cannot even be updated, and this bug report concerns MeshContentProvider specifically. The behavior upon failure of other asset types is not important; there are no bug reports about random decals or sounds frequently failing to load for unknown reasons, only meshes.