Say I want to delete a door in workspace called “DeleteDoor” so that a bunch of players can pass through. What if a player joins the game who happens to be named “DeleteDoor” I know it sounds really out of the unlikely but keep in mind a lot of Roblox people seem to make really weird names
So when workspace.DeleteDoor:Remove() runs, it would remove the character instead
Also, can’t certain exploits allow people to see the explorer? They can break games intentionally by making accounts named after parts or models that are probably referenced by scripts.
Do Roblox scripts automatic recognize Characters apart from other game objects?
Lemme know what you guys think about this!
Edit: I also realized that this can actually cause a script to break completely rather than just running the code on the character. Because what if the script is designed to actually change a property of an object that it accidentally references a character model for. Like workspace.Blocky.Transparency = 1 would lead to “Transparency is not a valid member of Blocky” if there was a character named Blocky in the game!
[Edited to answer more of your questions]
Yes, if a player joins with that certain name it can break your script, but you could always check for the main part in the model you’re referencing or check if the part doesn’t have a humanoid in it.
Yes, certain exploits can see the explorer, but if you have your script set up to check for a humanoid and/or base parts, then you can prevent them from breaking your script(most of the time).
They, in fact, do not, unless you manually check yourself.
You could make it a name that is more than 20 characters, or you could make it a name that is less than 3 characters. (i know there is alot of less than 3 character usernames there)
Yes, this can break a lot of games. It usually doesn’t though either because 1) most common names are taken by inactive users that haven’t logged in since 2008 and 2) the payoff for exploiting this is not worth it. As an exploiter, it would be hard to tell if the developer is referencing something by name, and even then it may not be that big of a deal. Sure, the door isn’t deleted, but it’s not like it gives players thousands of in-game currency.
While this usually is a non-issue, it can still happen. You can work around this by using CollectionService (e.g. tagging all items you want removed with DeleteDoor and then searching for items with the DeleteDoor tag – this is not something player name can impact), or keeping scripts within these objects when appropriate instead of having a global script that controls all of them.
There are a lot of ways to prevent that from breaking your game, plus it’s very unlikely for someone to do so.
One easy option is to put the door inside a folder in Workspace and :Destroy it from there.
ex: workspace:FindFirstChildOfClass(“Folder”).DeleteDoor:Destroy()
(don’t actually use the example in your own work)
That wouldn’t be advisable. It would just make things more complicated and clutter things up. It also wouldn’t help the point he proved where they can view parts name. Refer to my post for a possible solution
Just saw you edited it as I was typing, but the same thing still applies. Naming a part correctly is good practice to make scripting easier to do.
First of all, whenever you reference something in workspace, the script returns the object created earliest in that server, with that name. This means that since the door was already in workspace since the server’s creation, and a new player spawns in, the script will find the first object, the door, and delete it or just make it CanCollide false and Transparency 1.
Other than this, there are tons of ways to circumvent this problem:
create DeleteDoor and reference it in a variable the first chance you get, each time it is instantiated, so that the script can never get confused about this.
local DeleteDoor = workspace.DeleteDoor
--...door gets destroyed
local DeleteDoor = Instance.new("Part")
DeleteDoor.Properties = stuff
DeleteDoor.Parent = workspace
--or
local DeleteDoor = oldDeleteDoor:Clone()
DeleteDoor.Parent = workspace
This would be the recommended solution.
use door:IsA("BasePart") to make sure the door is a part and not a model, like a player’s character would be, and if it is, you could probably just name the character something different, index it again, and name that previous character what it was before as a hacky solution.
local DeleteDoor
do
local lastDeleteDoors, lastNames = {}, {}
repeat
local lastDeleteDoor = workspace.DeleteDoor
table.insert(lastDeleteDoors, lastDeleteDoor)
table.insert(lastNames, lastDeleteDoor.Name)
lastDeleteDoor.Name = "somethingelse"
until lastDeleteDoor:IsA("Part")
while #lastDeleteDoors > 0 do
table.remove(lastDeleteDoors).Name = table.remove(lastNames)
end
DeleteDoor = lastDeleteDoor
end
--continue
loop through workspace:GetChildren() and find out which part is a BasePart
local DeleteDoor
for _,part in pairs(workspace:GetChildren()) do
if part:IsA("Part") and part.Name = "DeleteDoor" then
DeleteDoor = part
break
end
end
--continue
Something which others have put down, put DeleteDoor somewhere else other than workspace, like a folder or model, or probably even another part, in workspace.
IsDensendatOf(game.Players) is very useful to use when making sure the part you are targeting is (or isn’t) involved with the player’s character. As for using type() will allow you to make sure that it’s a model if by some random chance you decide to change it around though it’s not exactly needed.
Edit: Don’t use type() I forgot that it only works for strings/numbers/tables, and as for IsDesendantOf(), the player’s character is a Descendant of game.Workspace so that wouldn’t work either. I just ran the test myself and didn’t get the results I expected. Thank you colbert2677 for verifying this.
Using type on an Instance would return “userdata”. Using typeof on an Instance would return “Instance”. None of these are appropriate workarounds and don’t work in the way you think they do. This also does not check any descendants possessing similar names. This code is pointless. You still have to find the appropriate descendant.
This problem would never arise if you keep your models organized, you can either put characters in their own folder or put doors in their own folder, there are millions of ways to go around this problem so much so that i wouldn’t consider it a problem at all
