No.
Parts sent to nil are to be garbage collected, if roblox allowed a method to collect nil instances it would cause a lot of memory leaks with people who don’t know what they’re doing.
There is a lot especially on low end devices that don’t handle memory well
1 Like
Do >
local Backup = script:Clone()
local MyParent = script.Parent
game:WaitForChild("RunService").RenderStepped:Connect(function()
if script.Disabled then
script.Disabled = false
end
if script == nil then
Backup.Parent = MyParent
end
end)
These don’t even work inside Studio, so I doubt it’ll do anything in an actual game where an exploiter can just pause a localscript’s execution without setting .Disabled if they really wanted to.
1 Like
Wrong d_hq
It says right in the Lua Manual, that anything deleted, or Parent set to nil, can be resurrected by re-referencing it.
If you knew the original Parent of that Script you could bring it back.
Maybe even, if you gave it any Parent… I have no idea…
This deletes a bunch of models in Parts, in a table:
game.Players.LocalPlayer:WaitForChild(“ClearCache”).OnClientEvent:connect(function(Tab)
print ("-- Obj:Destroy()")
local obj = nil
for i = 1, #Tab do
table.insert(CamList,Tab[i].Name)
table.insert(CFrameList, Tab[i].CFrame)
table.insert(RotList,Tab[i].RotVelocity)
– Tab[i].Parent = nil
obj = Tab[i]
obj.Parent = nil
end
end)
This brings a table full of them back to life, and deletes some more:
game.Players.LocalPlayer:WaitForChild(“ClearTile”).OnClientEvent:connect(function(Obj, NegObj) – object is a list
for i = 1, #Obj do
local cloud = container[Obj[i].Name]
cloud.Decal.Transparency = 1
cloud.Transparency = 1
cloud.OldInfo:ClearAllChildren()
– cloud.OldInfo:Destroy()
–Obj[i].Parent = nil
if cloud:FindFirstChild("Mesh") then cloud.Transparency = 1
cloud.Mesh:Destroy() end
Obj[i].Parent = workspace.globe
end
wait(.5)
for i = 1, #NegObj do
–
NegObj[i]:clone().Parent = container[NegObj[i].Name].OldInfo
greyOut(container[NegObj[i].Name].OldInfo[NegObj[i].Name])
– Instance.new(“Model”, container[NegObj[i].Name].OldInfo)
– NegObj[i].Parent = container[NegObj[i].Name].OldInfo.Model
NegObj[i].Parent = nil
end
end)
It makes for a very elegant FOW but unfortunately it is exploitable, as the deletes, can simply be deleted…
I wish that it weren’t so, because I want what I want, so I’m gonna figure-out some sanity checks, I can do, without letting on that I know…
If you got any elegant ideas; lay 'em on me…
No, client sided anti cheats aren’t useless. You shouldn’t rely on them but they aren’t useless.
Currently, Roblox locks the parent property when calling Destroy, so you can’t exactly resurrect deleted instances in Luau, unless you pull them out of the garbage collector to prevent them from being completely deleted, which isn’t possible without exploits AFAIK.
Exploiters can do whatever they want on their computer, you got no control over it. You just need to make sure the packets sent to the server are not manupulated.
There’s no way of getting the location of the injected script. They’re all stored in the lua stack/memory, both of which you can’t access at all from a Lua script.
Although if you really want to detect injected scripts you can look at the output of some skidded scripts and detect them via LogService.
Well, is this, Lock, a recent development, because, I’m sure I read that statement years ago…
Then it stopped working…
Now it’s working again, but I may have actually changed the code to get it to work again…
And now that I look at the code: It seems like I am really just passing the values from the server to the client, and the original concept of reviving the old Tile, which I deleted, by Name only is gone…
So, ,actually, it is at least a little less hackable now, if I can just keep all the data Server side until needed on the client…
But that means I’m pushing lot of data around now, and I did want this to be somewhat of an RTS; so FAST…!
Obviously, I don’t really know what I am doing but that’s my life basically so I’m used to it…
And it WAS fun to read the Lua Reference Manual again…
so thanks Phoenixwhitefire
Don’t know if these are new, but I am loving that I found them… Def. not mentioned on Roblox…
-
&: bitwise AND -
|: bitwise OR -
~: bitwise exclusive OR -
>>: right shift -
<<: left shift -
~: unary bitwise NOT
AND, I’m scripting for this artist’s game, and he’s GREAT!
Then to rephrase, they’re pointless. If you can’t rely on an anti-cheat, why bother?
2 Likes
Thats not what I was saying.
I was saying any part that has its parent set to nil cannot be retreived unelss you have a referance in scope.
You can’t do nil:FindFirstChild() or game:GetOrphans() so theres no other method.
Also Instances don’t get resurrected, they’re never destroyed in the first place. They’re just sat in nil and if theres no referance or a referance gets removed the part gets removed from memory.
This also happens for Destroyed objects by using :Destroy() since you can’t reparent it, all its connections are destroyed and all referances of it get set to nil it gets removed by the GC.
1 Like
It’s the first line of defence, doesn’t mean its pointless
I guarantee all front page games have an anticheat of some kind on the client
I suppose client-sided checks can at some point become sort of like an anti-cheat, though, obviously not very secure or reliable, but it could end up delaying exploit developments if checks are littered around localscripts to see what the client is sending to the server, which can become problematic if exploiters try and send incorrect data. It’d mean more time spent bypassing the checks instead of harming your game. Though, of course, I wouldn’t say it’s a good idea to spend time specifically on these.
not true at all, they cant delete the anti-injector if they cant inject in the first place
Not so fun fact, most exploit auto-inject injects before anything loads. Synapse X auto-execute executes scripts before ReplicatedFirst. Meaning it’s entirely possible to delete any client sided detection within game.
Roblox could make a detection on the engine itself but I doubt they get pass the developers eyes.
This post should end here, there is no point continuing.