Great… load times for Ultimate Boxing seem to be much higher now for the skippable part of the loading screen.
I would prefer to mod my loading screen for the update tomorrow rather than hot fix it like that for tonight.
1 Like
This update is awesome and made more universal for many asset types.
But please tell us before you make these changes;
I’m getting complaints about music not working in my game as I’m scampering to fix it up 
3 Likes
Sorry for that. I’ve turned the flag which will cause errors off. PreloadAsync with instances will still work. You can take your time.
5 Likes
The base idea is that you will likely save objects with preload ids in ReplicatedStorage or somewhere, you can just preload these objects instead of getting ids from them. I’m not sure your use case. Do you use one Audio object and change its ids dynamicly?
1 Like
How long do we have before this becomes re-enabled?
When the player shoots their gun or reloads it makes a sound object that then plays. Making a bunch of sound objects for each gun sound is just tedious and is just easier with stored sound ids.
3 Likes
Having to hack around the sound object and spam-clone multiple instances is more a problem with sounds than it is preloading. Would maybe be nice to solve that issue with sounds instead so we don’t have this hacky workaround to begin with.
What I do currently is create the template sound in model and then clone it whenever it needs to be played, which should be a reasonable integration with preloading until sounds are improved.
7 Likes
Cheers, something that I’ve been waiting for a while for.
Excellent feature!
Given that this change isn’t backwards-compatible, I think the reasoning behind it deserves more of an explanation.
17 Likes
This is a problem. I have a configuration module in RS Minigames that stores all sound and image asset IDs used in the game. This module is read by the loading screen client to preload all sound and image assets, so there is no loading delay while playing the game. I have at least 60 assets that are preloaded. With this change, I now have to hackishly create a sound object, set its ID, and load that sound asset, then destroy the sound object. This is not only ‘hackish’, but it’s bound to cause lag, which can interfere with the loading screen UI animations.
To a degree, yes. I have two clients in the game - The lobby client and the Minigame client. They both use one sound object, dynamically changing its ID and ‘fading’ the volume for music changes.
Why are images able to be loaded as IDs still, but not sounds?
This update is nice, but it would be even better if we could keep the ability to load sound and image assets as IDs.
7 Likes
Why does it assume just images and not others anymore? I use PreloadAsync more so for yielding audio as to keep in sync with in-game events.
6 Likes
That’s not how preloading is meant to be used. You’re only supposed to preload a handful of important assets or to preempt the automatic streaming when you know a player is about to need an asset before they use it (e.g. a scope to a weapon they equipped) – not your whole game. Games that have loadscreens for “loading x/100 assets” just sour player experiences. The average playtime is around 20 minutes – you want your players playing your game and not sitting on their thumbs for a minute or two loading non-critical assets.
7 Likes
I agree with Reshiram110 that the workaround to preload audio is a hack. @programeow Is there a reason that only image ids get special treatment allowing them to be preloaded with PreloadAsync?
1 Like
Now we need to know the type of the asset in order to request them. When client get a id in the old way, it doesn’t know what type it is. So we just assume it is a texture. It could be audio but this doesn’t change the situation.
Just PreloadAsync
1 Like
Alright, thanks!
1 Like
This is so useful! No more on-join lag!
Very nice update, BYE BYE lag!