I was reading through devforum, researching about ContentProvider’s PreloadAsync method, but I was under the impression that every single image, sound and stuff like that had to be put into the PreloadAsync method. I came across a thread finding stuff like this:
What are the “assets immediately available to clients” ? And why is preloading my entire game a bad idea?
I tend to just preload some meshes from workspace.
There’s no point in Preloading if you’re going to Preload everything… The point of Preloading is to specify which assets should be prioritized. For example, a main menu’s buttons are going to be more important to load quickly than some spray paint on a wall. When you load the entire workspace, you do the same thing Roblox already does—load everything without prioritizing.
Here’s what my game does, to make sure that people have access to images on decals before this display.
---
-- @module PreloadAssetService
-- @author Quenty
local require = require(game:GetService("ReplicatedStorage"):WaitForChild("Nevermore"))
local AnimatedSpriteProvider = require("AnimatedSpriteProvider")
local ContentProviderUtils = require("ContentProviderUtils")
local GuiTemplates = require("GuiTemplates")
local InputImageLibrary = require("InputImageLibrary")
local PillBackingBuilder = require("PillBackingBuilder")
local RoundedBackingBuilder = require("RoundedBackingBuilder")
local SoundTemplatesClient = require("SoundTemplatesClient")
local WaypointIconTypes = require("WaypointIconTypes")
local PreloadAssetService = {}
function PreloadAssetService:Init()
self._assets = {}
self:_add(RoundedBackingBuilder.BACKING_ASSET_ID)
self:_add(RoundedBackingBuilder.SHADOW_ASSET_ID)
self:_add(PillBackingBuilder.CIRCLE_IMAGE_ID)
self:_add(PillBackingBuilder.SHADOW_IMAGE_ID)
self:_add(PillBackingBuilder.PILL_SHADOW_IMAGE_ID)
self:_addList(InputImageLibrary:GetPreloadAssetIds())
self:_addList(AnimatedSpriteProvider:GetPreloadAssetIds())
self:_addList(WaypointIconTypes)
self:_add(GuiTemplates:GetContainer())
self:_add(SoundTemplatesClient:GetContainer())
end
function PreloadAssetService:PromisePreload()
assert(self._assets)
if self._preloadPromise then
return self._preloadPromise
end
self._preloadPromise = ContentProviderUtils.promisePreload(self._assets)
return self._preloadPromise
end
function PreloadAssetService:_add(instOrAssetId)
assert(type(instOrAssetId) == "string" or typeof(instOrAssetId) == "Instance")
assert(not self._preloadPromise)
table.insert(self._assets, instOrAssetId)
end
function PreloadAssetService:_addList(list)
assert(type(list) == "table")
assert(not self._preloadPromise)
for _, instOrAssetId in pairs(list) do
assert(type(instOrAssetId) == "string" or typeof(instOrAssetId) == "Instance")
table.insert(self._assets, instOrAssetId)
end
end
return PreloadAssetService
It depends on the number of instances. I just do it to be sure it’s loaded since it doesn’t hurt.
I have 2 Places, but what should I load it into? I have a main menu that just teleports the player to the place. does doing it on the lobby/main menu actually do anything? for now i decided to go with the place that will be loading but currently have a problem with it, no idea if its because of roblox’s outages.
It’s considered best practice to use pcall() when calling any functions requesting outside data.
I don’t know why you think this. Async functions in Roblox purely mean that they can and likely always will cause a yield in your code, wrapping them in a pcall doesn’t make a difference afaik and afaik probably will (at least until recently) just slow down your code. Can you explain why wrapping Async functions in a pcall makes sense?
Examples of async functions in Roblox:
Instance:WaitForChild()
Event:Wait()
HttpService:RequestAsync()
ContentProvider:PreloadAsync()
Again, afaik these functions have no reason to be wrapped in a pcall over any other functions so I’m not sure where you’re getting that from. Functions with Async in their name are usually just async functions where a yield wouldn’t be implied. PreloadAsync doesn’t even error as far as I’m aware, so, again, I really really don’t see why pcalling it is a good idea.
Lastly, for @jonbyte, PreloadAsync accepts a list of instances (not asset ids) to load as well as a function to call when any asset is loaded. It’s more performant to leave it blank but its usually more performant for a loading GUI to use this than manually checking yourself. There are only a few instances where Preloading actually makes sense because things like Parts don’t actually have anything to preload.
Basically, you can use it to prioritize when assets load. MeshParts, UnionOperations, ImageLabels, ImageButtons, Decals, Textures, etc, etc are all applicable to PreloadAsync because they must load an asset. When colbert refers to “assets immediately available to clients” he is referring to things like GUIs which will exist at the start of the game. Preloading something that’s already loaded obviously makes no sense, so, this is what he’s referring to basically. Meshes which will be displayed behind GUIs can also be Preloaded for example. It’s a good idea to preload all of the meshes and unions in your game after preloading UI but I guess this only helps if you have UI to block them in the first place, such as a loading UI or a menu.
Thank you, after reading all the responses, especially your response I believe I have a better understanding of when I should use PreloadAsync. I do have a main menu with a couple images, so I am going to preload that and anything extra that is dubbed “immediately available.”
Sorry for reviving
But its only for functions that are error prone, not all async functions!
What if my loading gui is already prioritized and I just wanna display how much of the game’s loaded in terms of assets?
Would it still be a bad practice to do {workspace} ?