I won’t be able to explain the technical details behind it since I’m not as knowledgeable about the specific inner-workings, but I can offer a general overview:
-
Arbitrary wait time
-
No guarantee that it will wait for a long enough amount of time.
-
Not flexible to different situations. It might wait the perfect amount of time for one user, but not another.
-
The longer the wait, the more likely it is to guarantee it has waited for enough time. However, this comes at the expense of the user experience. As players wait longer before having visual feedback that something has worked / reached its intended state, the game may feel less polished from the perspective of the player.
And going back to something you mentioned in the original post:
Although I don’t know many details about the intended gameplay for your game, if that few seconds of the Character being visible upon respawning has the potential of providing a gameplay advantage for someone in the game, then waiting for an arbitrary amount of time will always leave the door open for the average player to take advantage of that.
-
Events (in this case,
CharacterAppearanceLoaded)
-
On the server-side, guaranteed to fire once the Character’s appearance has loaded.
-
Flexible to different situations / loading times. Whether a Character’s appearance loads almost instantly, or if it takes a few seconds, the event will fire at the right time.
-
Because the relevant code for updating the Character’s visibility would run as soon as the event fires, this would provide nearly instantaneous visual feedback for the player while simultaneously lessening the likelihood that players would be able to take advantage of the timeframe where the Character model would be visible.
Aside from the odd, inconsistent bug that prevents it from working specifically on the client-side for some users (which is a glitch which doesn’t happen with practically all other client-side-compatible events, and is something that should have been resolved by now) I can’t think of any common drawbacks for using the event over a wait.
The only situation I can think of where there could be an issue would be if Roblox’s Avatar services go offline while games are still playable (which very rarely happens) causing Character appearances to never load. However, for something like that, it would be best to have additional code to fall back to rather than having the entirety of the code revolve around a wait.
-
An example implementation of that could be to store a true or false value for each player that would indicate if their Character model is invisible. It would be set to true after the CharacterAppearanceLoaded event fires.
Before that event fires, though, a separate CharacterAdded event would fire, setting the value to false and then starting a timer with the RunService. If the value is set to true, the timer can be stopped because the event fired. However, if it’s not set to true after a given amount of time, that would indicate that CharacterAppearanceLoaded never fired. As a result, it can be instructed to run the same code that would loop through the Character model and make it invisible.
If you want it to be even more reliable, you could connect the DescendantAdded event to the Character model so that it will be able to detect the addition of any new Accessories, BaseParts, Decals, etc. in order to destroy it or update its Transparency right away (even if the CharacterAppearanceLoaded event had already fired).
All of this helps ensure that the Character model would become invisible, even in unexpected situations.
Since it appears to be reliable when used on the server-side, will immediately fire the event and run the code as soon as it’s ready, alongside the benefit of automatically replicating the visibility changes to every player in the game (because it’s being run on the server side), utilizing CharacterAppearanceLoaded for this use case provides much more reliable and timely visual feedback for the players in the game, in comparison to adding a wait before looping through the Character model.
Although adding a wait works in theory and it could work in the vast majority of situations, it is generally advised to make use of events where possible, as events are much more versatile and are designed in a way to make it faster and easier for the code to respond / react to what’s happening in the game.
Ultimately, for a gameplay feature as simple as this, it’s unlikely for there to be many long-term consequences that could negatively affect the game as a whole by using wait over an event. However, it does have an impact on future gameplay design decisions you might make and how one’s coding practices and relevant skills develop.
If relying on wait becomes a common solution in your scripting toolbox, it could inadvertently impact other parts of the game that are created in the future. What could start with a few seconds of waiting after the Character respawns could turn into cumulative minutes of unnecessary waiting for a variety of things to happen in the game if other features are also designed around waits where events could be used.
On a similar note, waits are often considered to be a “code smell” by other developers; that thread provides some insight into some alternatives of wait with adjacent examples.
There are still valid use cases for waits and waiting through the RunService, especially in circumstances where there’s code that needs to be run indefinitely, but for situations like these where there’s an event that is really suitable for the use case, events usually end up making it possible to create a more robust implementation of specific gameplay features.
I can’t force you to use one option over the other, but I hope I was able to provide some valuable insight about this subject matter.
TL;DR / Key Takeaways
