Deactivated Roblox Settings Menu, consequences?

Help and Feedback Scripting Support
#12

Do what? Remove the TopBar UIs?

game.Players.LocalPlayer.PlayerGui.Name = "yes"

#13

I believe it should be fine, but I’m not completely sure on that.

1 Like
#14

U create a localscript inside ReplicatedFirst and enter this:

game.Players.LocalPlayer.PlayerGui.Name = ""

#16

I swear I’ve read somewhere a long time ago that this isn’t allowed, but I don’t remember where and therefore don’t have any proof of that. However, I wouldn’t recommend using methods that are hacky. Not because of any ToS, but rather because it may be patched at any point

However, it should be noted that the escape menu does have some key features that are important. Obviously it has game settings, help, and record, but it also has the report section. The report section is probably the most important part as to why you shouldn’t break the escape menu.

I would much rather if Roblox added actual API specifically for forking the escape menu. That way developers can finally use the esc button for a custom escape menu, while also not removing or breaking anything that the core escape menu needs.
(Although, along with the chat forking API, Roblox needs to make it secure and not so easily spoofed by a script. Don’t want another round of the chat spoofing incident, but with reports too.)

2 Likes
#17

No just the Roblox Menu for the other one u can use other script if u need it i can send it

#18

I’m surprised why they haven’t fixed this yet. Many people have sent exploit reports to @Exploit_Reports yet it still hasn’t been patched.

#19

Is this even an exploit let alone classed as one

#20

As far as I know this does exploit a bug in Roblox’s CoreScripts which does a WaitForChild(“PlayerGui”) I believe, and by changing the name, it causes the menu gui to never be enabled

1 Like
#21

Yes, it’s gamebreaking so yes it does classify as one. (Especially since you shouldn’t be able to tamper with the topbar like this)

1 Like
#22

oh, when you put it like that “exploitable bug”, makes sense

#23

Wait that means we can also deactivate it in CoreScripts?

#24

I don’t know why Roblox doesn’t create a function such as WaitForChildOfClass?

function WaitForChildOfClass(instance,class)
	local object = instance:FindFirstChildWhichIsA(class)
	if not object then
		local added
		added = instance.ChildAdded:Connect(function(obj)
			if obj:IsA(class) then
				added:Disconnect()
				return obj
			end
		end)
	end
	return object
end

local playerGui = WaitForChildOfClass(game:GetService('Players').LocalPlayer,'PlayerGui')
print(playerGui.Name)

Although obviously it would look more like this if it were actually implemented:

local playerGui = game:GetService('Players').LocalPlayer:WaitForChildOfClass('PlayerGui')
print(playerGui.Name)
#25

I agree, but unfortunately it doesn’t seem like it’ll be added:

Before 2013, WaitForChild used to be a function defined in a lot of scripts before it was added to the API

#26

I’m surprised I named that function correctly without seeing that post. But honestly, I think that argument is kind of ridiculous. I don’t see how adding an engine level API would be an issue or even difficult? Sure it’s nice to path to an object without having to use WaitForChild on everything, but this is an obvious case where that’s a problem.

This is why we (or should, for those that don’t) use GetService. Obviously it has the purpose of adding a service if it doesn’t already exist, but it also lets you get to a service if its original name has been altered. Lots of games have done this for the sake of anti-exploits (not that it matters as the exploit scripts could simply use GetService as well). It only makes sense, especially for the sake of consistency, that we have a similar method for classes.

Plus if nothing else, here is a point in time where it should be added to fix core scripts with this exact scenario. It would be much better for them to add API specifically for this. But whatever, I’m obviously not Roblox. They’d have to edit those core scripts regardless, in order to fix this. But again, this is a clear example of why it should be a built-in feature.

#28

This is actually an exploit which is being addressed by roblox and shouldn’t be shared publicly. I fear it is too late to delete it now though. This means that as an exploit it is not allowed nor supported by Roblox. However, since it is minor then there is no immediate risk but I would not recommend it

#29

The @Exploit_Reports team is already addressing it and as such there is no need to do so.

#30

Not really related but interesting, it appears the the actual issue is in the Chat and not the Menu or camera because if you rename the PlayerGui and add a Folder with the name PlayerGui, the Chat will go into the Folder but the Menu works and Freecam is in the proper PlayerGui not the folder

#31

Well that’s because it’s using WaitForChild and searching specifically for a child named PlayerGui. It only prevents the chat from showing up due to the folder not being a display folder. This is why Roblox should search for the PlayerGui class rather than just waiting for anything to have a matching name.

#32
#33