you cant make local scripts in exploits
also this doesnt work no matter what aftet its deleted it stops working.
Yeah, I know but in ComputerCraft, I know that sleep() (equivalent to wait) basically yields the thread telling it to start a timer and keeps yielding until it receives a timer event saying the timer was complete.
If you used sleep withing a coroutine you started it wouldn’t work right and instead just yield
In Roblox, I wasn’t sure if the behaviour was the same, that’s why I’m asking.
sleep() is a custom function meant for lua, since it doesn’t have a built-in one and in roblox they have wait() which was replaced by task.wait() of which both yield any scripts. But it will not yield if on a different task. Just look at task.delay()
Well, not the main thread, but whatever thread was spawned, right?
task.spawn spawns a thread and adds it to the list of threads roblox loops through internally to resume (I hope I’m not spewing misinfo).
But coroutine.wrap()() just creates a co-routine and switches to it immediately, meaning the rest of the code in the script won’t run until the code within it finishes.
Of course, using task.wait might change things which is why I asked.
Also, the main point was that creating a new coroutine creates a new state, which .Disabled doesn’t pick up on causing it to continue, which was youe point (I read the source you linked)
P.P.S. BTW I’m not disagreeing with you, just asking a few questions because I’m not 100% sure how task.wait works and interacts with coroutines and .Disabled
P.S. yes I know task.wait is the newer wait.
No, That’s not true, it’s mainly used for loops of which you don’t want them to yield your entire script thus spawning them in a different of what roblox calls a state or task, you can look for the entire purpose of coroutine elsewhere, since it’s a pretty and COMMONLY used function in every single other languages.
Btw we should move somewhere else since were getting off-topic.
This thread might be benefitting for you. Deeper Look into Wait() - #25 by Scottifly
UPDATE: Ok, now I have tested task.wait properly and I think I see how it works. If you want to see what I wrote before, scroll down to “Old theory”.
It yields the current coroutine, regardless of what it is, and rhen schedules it to be resumed after a certain time.
If you are using it in an actual coroutine, it would yield with a value of nil and then automatically resume after n seconds. If another thread is running when it is supposed to resume, it will wait for that one to complete.
If you resume that coroutine after it used task.wait, it would resume it successfully, but it will still be scheduled to resume if it ever yields again.
What I mean can be demonstrated by this piece of code:
local co = coroutine.wrap(function()
print("Co:", "Start co")
coroutine.yield("Some value here")
print("Co:", "Back in co")
task.wait(5)
print("Co:", "We resumed early")
coroutine.yield()
print("Co:", "Restarted by task.wait")
prinr("Co:", "Died")
end)
print("out", co()) -- Some value here
print("out", co()) -- out, nil because task.wait yields nil
print("out",co()) -- We resume co during a wait even though we shouldn't
task.wait(15)
co() -- Error here because coroutine is already dead.
Towards the end, we resume the coroutine from task.wait even though we aren’t supposed to, and then we wait 15s. Since the old task.wair wasn’t cancelled, it will resume the coroutine from a regular coroutine.yield even though it shouldn’t. As there is no more yields after that, the coroutine finishes and dies. Finally, when the main thread attempts to resume the coroutine, it prints an error as the coroutine has already died.
Old theory
Oh yeah, I know how coroutines work, but I thought they didn't spawn new threads.Instead, they create a resumable thread which you can resume via coroutine.resume. After calling coroutine.resume, whatever thread was calling will “join” the coroutine, effectively waiting for it to either finish, or yield.
task.spawn from what I see, is simply just a wrapper for the same exact thing, until that is you use task.wait.
From what I gathered, if you wait inside a coroutine, wrapped or not, the calling thread will remain joined until the coroutine actually yields. Task.wait will still wait as is but there is still this difference. Please correct me if I’m wrong. If I’m wrong I’m curious as to what the return value to coroutime.resume would be as it would have to obviously return something to continue, right?
If you wait inside task.spawn, it will yield, but the calling thread to task.spawn won’t join, so it can totally continue executing before the coroutine/function inside task.spawn finishes.
To confirm with you, coroutine.wrap is just
function wrap(func)
local co = coroutine.create(func)
return function(...)
return coroutine.resume(co, ...)
end
end
EDIT: Thank you for the resource in wait(), I will read that next. If you want to continue discussing, we could talk in private messages if you like. But it’s also getting quite late for me so I might not respond as I would be asleep. Either way, have a nice day! This was quite informative.
2 Likes
Hey I’m coming back cause I’m wondering if the exploiter can insert a hopperbin into another client. Would the localscript from that client detect the hopperbin and kick that player?
No they cannot insert HopperBins or in fact anything into other clients.
Listen, I understand you are worried about this exploit but it’s important to focus on the true cause of it.
I believe (happy to be corrected) that HopperBins are a red herring and worrying about them will just waste time. Try to just check for anything related to the Terrain that allows players to delete it.
Very important: If you have EVER inserted a free model, it has a chance of containing exploitware, so thoroughly check every script in your game
HopperBins are deprecated though but hackers still use it, this is the script you’re looking for though
-- Put this in ServerScriptService to prevent it from being controlled by exploiters
local Players = game:GetService("Players")
Players.PlayerAdded:Connect(function(player)
local backpack = player.Backpack
backpack.ChildAdded:Connect(function(child)
if child:IsA("HopperBin") then
player:Kick()
end
end)
end)How is your game being exploited? This would be key to knowing what should be done.
1 Like
In another post they mention that exploiters are wiping their datastores. Not sure what that has to do with HopperBins
Edit: Originally I wrote Terrain, not sure why I remember that this has nothing to do with it.
Hopperbins are a complete separate matter from the datawiping thing. This new posts go in the direction of hopperbins and how to stop them. @VortexColor
I have originally wrote a script kind of like that, but I’ve improved upon it. For example making itself clone a whole bunch of times in random descendants of the character and localplayer. Also the clones’ names change every few seconds to a random “default” looking name any game would use for a local script.
Edit: yeah i just realized you just sent something for a serverscript
I’m a little confused on how an anti hopperbin in the server script works, since the exploiter’s executer can only insert it on the client which won’t let the hopperbin be visible on the server.
This doesn’t work because it’s inserted by client making it non-replictable.
you want a local script huh?
Hackers can:
- Modify the content especially if it’s deleted
- Delete the Script
In what world can they modify an already running script?
In what world does deleting the script stop it?
Have you tested what you said with exploits and not studio?
im just telling you the disadvantages of a local script okay?
Are you sure though you need to stop HopperBins.
It would be useful if you told what kinds of exploiting you are dealing with and whats the issue. What problems do the hopperbins cause?
1 Like
This is a bit out of context but,
Do you happen to have that one popular hoverboard free model in your game?
Theres a script out there that abuses the RemoteFunction that the hoverboard uses to delete itself.
i was formal my entire way until here lol
i dont really use free models in my games since all the prebuilt things on toolbox never fits the correct game style
TLDR one sentence: no