You can freeze ROBLOX by holding the close button

I’m unsure if this is a bug or not but you’re able to freeze ROBLOX by attempting to close it but holding the close button and resume it when you let go (obviously don’t let go on the close button however)

I did this in a game earlier and it managed to ??? causing me to get x2 lots of points and break the game (I’ve played a lot of games today so I don’t remember what one) so this could cause an unfair advantage/break stuff.

14 Likes

Doesn’t happen on non-potato computers. My friend’s rich he owns a god-tier computer and when I ask him to do this, he doesn’t freeze up. XD

1 Like

Also works with the minimize button… In certain situations, you can get it to also freeze when the screenshot popup shows upon taking a screenshot.

1 Like

This has been here for a while. If you jump and do it, you’ll float. An easy way to win games like spleef.

1 Like

This is an unfortunate side effect of windows… in windows. Try any AAA game in a windowed mode and you will have the same problem. Only way to fix this right now is to force all ROBLOX games to run fullscreen or borderless windowed.

3 Likes

While in any game, holding down the close window button will cause the client to hang until released. Everything physics-based on the client (Character updates, NetworkOwned parts) will stop recieving updates and freeze in place until the button has been released.
The client will not close until the mouse is released on the button itself.

To my knowledge, there is no reasonable method of detecting this.

  • Delta times, if a player is on mobile/low end pc and we give them a lot to do, we can see frame loss that could trigger this
  • Poor code starting to run could have clients falsly identified as doing this too.
    .
Brief examples of this

While not a huge bug, it’s difficulty to detect and its ease to reproduce can cause issue across a number of games.

I’ve noticed this issue a few months ago, but didn’t think it actually did anything. I’m unsure as to how long it has existed for.

5 Likes

This is actually not fixable. This can be done by holding the right button on the Topbar too.

This is a Windows specific issue and it’s been bought up a lot of times. Maybe roblox could have something by rendering something separated from that, but I’m not sure. It woundt be efficient though.

1 Like

Read my newer response in this thread for a better solution if you are looking for one. The script I provided is very bad.

Sorry to revive a dead thread, but this can be possibly fixed by developers by using FireClient() and checking for a response (to “skip” yielding just run the fireclient in its own thead and wait a bit). When someone is holding x, im guessing they arent sending info to the server. So the return will be nil.
I added this fix to my game and it works fine and hasnt returned any false positives yet…

--assuming we have the player and character 
coroutine.wrap(function()
		local s = false
		s,m = pcall(function()
			if chr then 
				inattempt = game:GetService('ReplicatedStorage'):WaitForChild('GetLocalProp'):InvokeClient(plr)
			end
		end)
		warn(m)
        coroutine.yield()
end)()
wait(5) --or higher
local failsafe = 'InvokeClient: player '..plr.Name..' must be a child of game.Players'
local failsafe2 = 'Script that implemented this callback has been destroyed while calling async callback'
if inattempt == nil and m ~= failsafe and m~= failsafe2 then
	plr:Kick('failed exploit check')
end

However i think it might result in kicking laggier players… so more checks might be necessary (like checking if the player is on the ground, etc…).

3 Likes

I think the actual problem is that when they hold x the windowing library windows uses stops processing events / updating any frame buffers but i might be wrong. it just makes more logical sense to me

Yeah, but I’m just showing a way to prevent people from using the hold x glitch to float mid-air for the most part. Since fireclient would run on the server, x pausing the game wouldnt affect it.

You just have to re-click the window. It’s not really a bug they can fix.

2 Likes

yo can u show the clientsided script cause i dont understand this

The script I showed is pretty bad. Generally when making anti-cheats like this, you want to do things on the server. A simple anti-fly should work for smthn like this.

If you still want to prevent this kind of exploit on the client, the essence of the idea was that when x-holding, the client stops certain ‘processes’. A MUCH better way to do this would be to have a client-side only script that checks if the game is not rendering any frames for a certain duration of time.

--services
local RunService = game:GetService('RunService')
local players = game:GetService('Players')
--variables
local connection
local player = players.LocalPlayer
--constants
local MAX_INACTIVE_TIME = 3 --will kick player when x-holding for longer than 3 seconds.


function onStep(deltaTime)
	if deltaTime > MAX_INACTIVE_TIME then
		player:Kick('X-Holding for '..tostring(deltaTime)..' seconds.')
	end 
end

connection = RunService.RenderStepped:Connect(onStep)

RenderStepped gives deltaTime, which is the amount of seconds that have passed since the last frame.

Keep in mind, this will also affect players with low framerates. You might want to make a less violent punishment than kicking, or give the player more chances. An example of a less violent punishment is simply sending them to the ground, or respawning them.

X-Holding is just a simpler way to ‘fly’. So you can assume most people who attempt it are not exploiters and wouldn’t be able to bypass this script. If you want to totally prevent flying and x-holding, use a server script.

If there were an exploiter in your game that could remove scripts, they would use a fly exploit instead of x-holding. This would just be a simple defense for normal players that try to x-hold.

You’re right about that, which is why if time is relevant you should use a server script. Just have a constant ray shooting down from the player’s character, and check if that distance is consistent or strange. An x-holder would have a constant distance since they are hovering.

Just find an anti-fly somewhere on here. It probably has been done for you already.

The general idea with anti-exploits is that you want to prevent the benefit, not the method, whenever you can. The method would be x-holding. The benefit would be flying.

You can also hold right-click on the window bar.