Hmmm, although I’m not super sure why that would be happening, a possible solution could be to change how the Character is referenced in the LocalScript. It could be modified a bit to access it through the LocalPlayer rather than trying to reference the one sent through via the RemoteEvent.
This means that the server script would only be firing an empty RemoteEvent to the player for the sole purpose of indicating that the CharacterAppearanceLoaded event has fired, without sending through the Character model it returns. Once the client receives that, it’ll reference the Character on its own and continue.
In the Server Script, the only thing that would need to be changed is when it calls :FireClient():
-- Before
RemoteEvent:FireClient(player, Character)
-- After
RemoteEvent:FireClient(player)
In the LocalScript, how the Character is referenced in the function would be changed to access the Character through the Player object:
-- Revised LocalScript code for the StarterPlayerScripts
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local player = Players.LocalPlayer
local RemoteEvent = ReplicatedStorage.RemoteEvent
RemoteEvent.OnClientEvent:Connect(function()
local Character = player.Character or player.CharacterAdded:Wait()
for _, v in Character:GetDescendants() do
if v:IsA("Accessory") then
v:Destroy()
elseif v:IsA("BasePart") or v:IsA("Decal") then
v.Transparency = 1
end
end
end)
No worries! This has been a fun experience actually; I like the questions that you’ve been asking to learn more about the reasoning behind my suggestions. Helps to refine all of our understanding about the subject and also gives me some practice for explaining ideas that I might not have thoroughly explained before or explained that often.
Still not working. However, it partially works after you reset, only that it prints the body parts but doesn’t make them invisible. Curiously, it’s not picking up any accessories. I’ve disabled every script except for the server script and this one and nothing changed.
Honestly, I am super stumped now lol. With all of these different setups, whether it’s just a LocalScript, just a server Script, or a mixture of the two, I haven’t been able to replicate the broken behavior (it’s worked every time during my own testing).
What happens if you try testing it in a live game? Maybe it’s different in Roblox Studio for some reason but works as intended in the published version of the game.
I’ve exhausted what seems like all the options without adding an arbitrary delay back into the code, so hopefully it just happens to work properly in a live server?
The game is set to private so it isn’t letting me join.
If I join afterwards and my Character goes invisible and your Character model doesn’t, that will be even more unbelievably confusing haha.
I had just gone into Roblox Studio and added your Character model into the Workspace as both R6 and R15 RigTypes and tested a slightly modified version of the code to see if it could make your Character model fully invisible right away or if it encountered any issues and it made both invisible so I’m still super confused lol.
I am so confused right now; the same thing happened as in the screenshot you posted earlier. The same things are printing out in the Developer Console (excluding all Accessories), and my Character wasn’t turned invisible.
Not sure what’s working differently there when I wasn’t able to replicate that in any of my own places / experiences that I tested the code in.
I could, but I prefer to not download files. If you could post it as a separate uncopylocked place on Roblox, I could edit through there to check (sorry for the inconvenience)
In newly created places since late November of 2023, that property is automatically set to “Deferred”, but since your game was created before that, it remained on “Default” (which currently uses the behavior of the “Immediate” setting).
I don’t have the technical know-how to confidently explain how that works and why that enables it to work, but I assume it’s because of the order that the code runs in when in Deferred mode. The loop probably runs every so slightly later on, which seems like it was just enough time to allow it to override whatever the engine was internally doing at that moment for the Character model. However, that’s just my understanding of it, so take that with a grain of salt.
No problem! Super glad that I was able to help find a solution and explain a whole bunch of other useful stuff in the process.
Most likely, yes. Before responding to your comment, I went into Roblox Studio and tested the code out in an older place that still had it set to default (I know I could have just set it to Default in a new place but I wanted to simulate a more similar scenario), and the “broken” behavior occurred. I guess we are lucky that Deferred SignalBehavior solves that for this use case haha.
Super glad that I was able to help find a solution and explain a whole bunch of other useful stuff in the process.