My game does not load characters until before pressing play, this has created a very strange bug in which a players forcefield appears at the position of 0,0,0.
Example:
This could even probably go in the bug reporting catagory, since I doubt this in an intended feature.
Anybody know how to retroactively fix this? I have no idea why this is even happening considering the character is never even loaded.
I think you can use workspace.DescendantAdded and check if the descendant is a ForceField, then destroy it.
why not using the PlayersAdded or CharacterAdded event and check if he has a ff? if he got a forcefield, in that case delete
Could you provide reproduction steps for this? I’ve tried in Studio with a blank baseplate by turning off CharacterAutoLoads and a forcefield does not appear at the origin. Duration was set to 20 since blank baseplate’s SpawnLocation has a duration of 0. How are you controlling character spawning?
I do not recommend any of the above two proposals. DescendantAdded on the Workspace could be potentially very expensive if you’re expecting many instances to be added to the Workspace or have no control over when that does happen, so you should go to the problem directly. Checking a character for a forcefield wouldn’t mean anything if no character actually spawns, but we don’t know how you’re controlling character spawning.
This is why I was waiting for more responses; constantly hooking DescendantAdded/ChildAdded connections in my game that requires every ounce of performance due to the capacity of 125 players.
Essentially, CharacterAutoLoads is turned off with a RespawnTime of 7 seconds - I made a loading screen that loads all data in the game and awaits several other systems such as my cacheing system. Once all of this is completed, a play button is presented and it will fire a RemoteEvent to a server script with a LoadCharacter() function to the server. The players character is then loaded into the game as normal.
It almost seems as though the forcefields appear the second the player joins the game. It’s honestly one of the more mysterious bugs I’ve encountered.
game.Players.PlayerAdded:Connect(function(plr)
plr:FindFirstChild(“ForceField”):Destroy
I don’t think the ForceField is in the Players instance. Because it appears visually in Workspace.
Hello, Dylan.
Like this?
If it appears somewhere, then script something that finds it and deletes automatically, I think you can make it. Just find where it appears on Explorer.
ForceField appears on a position of 0,0,0 in all cases, if it wasn’t put into a Part
Former Oretary Mod
Closest solution:
It takes players “too long” just to load in game. ForceField was created inside of a Character(Model) and there is no parts inside of that model. That caused the creation of a forcefield at 0,0,0 position. You can avoid it only by automatically deleting it.
I’m not able to reliably reproduce this issue on a blank baseplate. I followed your setup steps but no forcefields show up. Either my testing is flawed or this is an issue specific to your experience.
I think you’ll want to do a deeper delve into this problem to tackle the root of the problem itself. If you are able to get this issue to occur in your experience again, run this in your console:
for _, v in ipairs(workspace:GetDescendants()) do
if v:IsA("ForceField") then
print(v:GetFullName())
end
end
This should help narrow down the problem by trying to find out where exactly the forcefields are ending up, assuming they only render while in the Workspace and are created by the server. You can then go through the forcefields and see which ones you do or don’t expect to be there.
ipairs shoud be used for a table of arrays, not for dictionaries
for _, v in pairs(workspace:GetDescendants()) do
if v:IsA("ForceField") then
print(v.Name) -- or full name
end
end
Not sure what you mean here? GetDescendants returns an array-like table, so I’m using ipairs as is idiomatic for iterating through array-like tables. Also, the reason why I’m using GetFullName is because it prints the full instance path and therefore can reveal where exactly the forcefield exists; printing just the name of the instance is not the intent of my code.
This isn’t a correction, rather it defeats the purpose of my code. Please try and sufficiently understand API as well as the intent of code before commenting on it, lest you make non-suggestions.
Look, the function :GetChildren() and :GetDescendants() return a table of instance values of the descendants, so it would be better to use pairs than ipairs in my opininon
ipairs is idiomatic for iterating through array-like tables. The values of the table should not be the influencing factor between whether you use ipairs or pairs; it should be the indices. Nonetheless, I’m not here to argue about semantics, non-solutions or dogmatic opinions. Please PM me if you want to continue further, I don’t want to hijack the thread to discuss my choice of iterator.
It would appear that the forcefield is not just appearing in workspace, but also the players character model - so I’d assume the model of the character exists but non of it’s children (such as body-parts)
Now this is starting to lead me to believe this could be something to do with player.CharacterAppearanceLoaded as I run a function to replace body-parts at run-time with ReplaceBodyPartR15(), though I didn’t anticipate it would have much of an effect on the forcefield - it could be this or it could be something else.
Thank you all for your help thus far.
Replacing body parts with ReplaceBodyPartR15 should not have any influence on the forcefield given that the forcefield is parented to the character beyond where its adorned. CharacterAppearanceLoaded also shouldn’t be firing if a character doesn’t exist because an appearance wouldn’t be able to be loaded. I wouldn’t rule them out but they’re highly unlikely causes.
I find it interesting though because if you have CharacterAutoLoads off then character models shouldn’t exist in the Workspace to begin with. If these prints are results from when the issue occurs (there’s a forcefield but no character), then the model might exist where you don’t expect it to.
So far I still haven’t been able to reliably reproduce this issue on my own, so it’s difficult to understand where exactly the problem lies. You may want to look closely at any other code that may force characters to spawn (e.g. CharacterAutoLoads is not actually off, or LoadCharacter is unpredictably called). Are you able to reproduce this in any other experience of yours?
It would be nice if I was able to reproduce the issue because then I could try looking into a more direct way to deal with it, but since I can’t and I don’t know the full extent of your circumstances I can only offer some pretty obtuse hypotheticals and areas to look out for.