Case and point.
Instance:Destroy disconnects all connections.
6 Likes
The reason that you printing the connection still shows something is because of how Luaâs GC works. Destroy() does disconnect the connection but the actual connection object will not be collected until it has no references (which in the case you showed will happen AFTER the bound function finishes executing).
2 Likes
Im pretty sure its:
while true do
wait()
end
while wait() do
end
Im pretty sure that uses up a lot more memory instead of while true do.
When an instance is destroyed all connections on that instance are disconnected, and most of the instanceâs memory is freed.
@ThoseNamesAreGood
The second example does not use more (or necessarily less) memory than the first, and additionally, either is technically correct although I would prefer the first since its a bit more readable.
@dollychun
I also believe this article is kind of misleading in some places, a lot of this stuff is not ideal or necessarily accurate, and a lot of it can be interpreted wrong. For example, the CheckTeleport function checks if the player has moved more than 140 studs in a second. This doesnât really effectively detect teleportation, or speed, or no clip, or whatever.
âUse an anti exploitâŚâ doesnât really help the issue of explaining how to prevent noclipping. This is basically just like saying âfix the issue to fix the issueâ
The last section on remotes is definitely accurate, but, option #3 would be easily circumvented, and option #2 is not really a solution to the problem. Option #1 is better, but, you should also check if the money bag exists otherwise, you allow them to fire it when its being removed.
You should be doing checks on Heartbeat, not in a wait() loop since Heartbeat is synchronized with physics. Additionally, you shouldnât just stick in an arbitrary value if you want your code to accurately detect these sorts of exploits, you should do a little math to determine how far is realistic using, for example Velocity.Magnitude. I go over this in my topic (who @LexiDog5 linked, thanks 
).
2 Likes
Thatâs just not true and pretty much the only difference between while wait() do .... end and while true do .... wait() end is that the code in .... runs before the wait in the while true do loop.
while wait() do runs the wait immediately before code executes,
and while true do wait() [code] end does the same, and while true do [code] wait() end has the difference that the wait happens immediately after the code runs, so the only differences will be in the first and last iteration.
Generally, while wait() do I personally dislike because its a bit harder to understand/read (in some cases), and its a little misleading, but, I mean, its not terrible.
Both are perfectly viable options, I have no real complaints for either to be fair.
If you have a rate limiter on a client-sided script, even if the player spammed manually or with an autoclicker, it would limit that rate in which a player sends a remote event. If it was an exploiter, they would be accessing that remote via an exploit thatâs ran directly in Robloxâs VM which would not be affected by the rate limiter.
So, with this, the server side would know this unusual spam traffic is from an exploiterâs client and would never result in false positives due to rate limiting a regular player via a script in the client.